[QUOTE=rebirther;548812]base S652 was running on all cores with -W16 but S913 did not (Ryzen 3950X) -->latest 2.0.3[/QUOTE]

Did you do both of these on the same machine?

For S913, it needs to reach a certain sieving depth before switching to multiple cores. I wonder if didn't get to that sieving depth or if it thought it needed to sieve deeper for S913 than S652 before switching. Can you post the pl_remain.txt files for both bases?

[QUOTE=rogue;548814]Did you do both of these on the same machine?

For S913, it needs to reach a certain sieving depth before switching to multiple cores. I wonder if didn't get to that sieving depth or if it thought it needed to sieve deeper for S913 than S652 before switching. Can you post the pl_remain.txt files for both bases?[/QUOTE]


yes, both files attached

[QUOTE=rebirther;548939]yes, both files attached[/QUOTE]

If my memory serves me right, when playing around with srsieve2, for curiosity only, I had to make a value of -w 10000000 (1e7), before srsieve2 used all 4 cores when sieving SR3 (for thousands of k's and very low p value). It also appeared, testing with sr383 sieve file, that for utilisation of ALL cores, one has to use a higher -w value than what is set as default - at least if one want's to use full ressources of ones machine.

[QUOTE=rebirther;548812]base S652 was running on all cores with -W16 but S913 did not (Ryzen 3950X) -->latest 2.0.3[/QUOTE]

I found the cause. I'll try to get it fixed later today. The main issue is that it will slow down sieving for p > base. To work-around stop when sieving reaches p > base, then restart from the file of remaining terms.

[QUOTE=rogue;549001]I found the cause. I'll try to get it fixed later today. The main issue is that it will slow down sieving for p > base. To work-around stop when sieving reaches p > base, then restart from the file of remaining terms.[/QUOTE]

Surely if it affects speed then mtsieve should detect when p becomes > base.

[QUOTE=henryzz;549016]Surely if it affects speed then mtsieve should detect when p becomes > base.[/QUOTE]

Correct, but the code to detect that condition (when starting a new base) had a bug.

[QUOTE=rogue;549019]Correct, but the code to detect that condition (when starting a new base) had a bug.[/QUOTE]

Sorry, I read it as you were only fixing it for newly resumed sieves but you had to restart manually in the fixed version.

k1b2sieve generalization
 

hey, i've just seen the k1b2sieve! is it possible to generalize this to an arbitrary base b, i.e. giving b as input instead of having b=2 fixed and sieving all b^n+c with n and c in a specified range? (i'd be interested in running such a sieve with base 10)

[QUOTE=matzetoni;549619]hey, i've just seen the k1b2sieve! is it possible to generalize this to an arbitrary base b, i.e. giving b as input instead of having b=2 fixed and sieving all b^n+c with n and c in a specified range? (i'd be interested in running such a sieve with base 10)[/QUOTE]

Yes, but it will be slower and not much faster than using fkbnsieve for each distinct n.

[QUOTE=rogue;549625]Yes, but it will be slower and not much faster than using fkbnsieve for each distinct n.[/QUOTE]


I see. Still, I'd like to run it over thousands of n, so it would eliminate the hassle of handling thousands of sieve files :)

[QUOTE=rogue;549625]Yes, but it will be slower and not much faster than using fkbnsieve for each distinct n.[/QUOTE]

Since 8+2=10

You can do it by 2 bitshift operations, 1 addition, 3-4 compare operations, 1 subtraction. Still faster than fkbnsieve for each individual n.