mtsieve

[rogue]

Originally Posted by rebirther

base S652 was running on all cores with -W16 but S913 did not (Ryzen 3950X) -->latest 2.0.3

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?

[rebirther]

Originally Posted by rogue

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?

yes, both files attached

[KEP]

Originally Posted by rebirther

yes, both files attached

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.

[rogue]

Originally Posted by rebirther

base S652 was running on all cores with -W16 but S913 did not (Ryzen 3950X) -->latest 2.0.3

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.

[henryzz]

Originally Posted by rogue

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.

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

[rogue]

Originally Posted by henryzz

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

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

[henryzz]

Originally Posted by rogue

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

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

[matzetoni]

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)

[rogue]

Originally Posted by matzetoni

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)

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

[matzetoni]

Originally Posted by rogue

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

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 :)

[Citrix]

Originally Posted by rogue

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

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.