On a Athlon 64 X2 3800+ from 64.5kp/s to 69.7kp/s!

Now get that quintic check in too! :wink:

sr5sieve 1.3.1
 

[QUOTE=michaf;89554]Now get that quintic check in too! [/QUOTE]
:-) Version 1.3.1 also checks for quintic residues, should be about 5% faster than 1.3.0.

lol :) thanks! :smile:
erm... how about hexic / septic checks? (Or whatever you would need to call them...)

Can they be generalised to b-tic checks?

(BTW, went from +- 70kp/s to 74.5 kp/s!)

[QUOTE=michaf;89748]Can they be generalised to b-tic checks?
[/QUOTE]
They generalise to prime power residues, next is 7, 8, 9, 11... There might be a slight gain by adding a check for 8-th or 9-th power residues, but others will need large changes to the code for diminishing returns.

There are probably gains to be had from improving the powmod function(). Previous versions hardly used powmod(), but now it has become a bottleneck.

i just have one small improvement to request:

when closing/restarting, the total factor found is reset at 0.
is it possible to write the total factor found in the checkpoint file and read it at startup so that we have the actual factors of the range and not #factors of the sieve session.

i think it's only 2 or 3 lines of code, but priority of this is "very low" :wink:

laurent

[QUOTE=tnerual;89755]when closing/restarting, the total factor found is reset at 0.
is it possible to write the total factor found in the checkpoint file and read it at startup so that we have the actual factors of the range and not #factors of the sieve session.
[/QUOTE]
I have added this in version 1.3.2. Thanks for the suggestion.

hm.. doesnt work after updating :D

found > 1300 factors with 1.3.1
resumed this ranged with 1.3.2, and it said, 0 factors.
after I found 4 factors with this new version, I restarted it, and it said "4 factors found".
I think, this "bug" will be no problem, after starting a new range.

thanks for the #factors improvement.

two more question: Did 1.3.2 write this info in the log file or at the end of the factors file or nowhere except on screen ? is it possible to split #factors by sierpinski/riesel ?

[QUOTE=Xentar;90135]hm.. doesnt work after updating :D

found > 1300 factors with 1.3.1
resumed this ranged with 1.3.2, and it said, 0 factors.
after I found 4 factors with this new version, I restarted it, and it said "4 factors found".
I think, this "bug" will be no problem, after starting a new range.[/QUOTE]

i suppose it read the number of factor from the checkpoint file and version 1.3.1 didn't write the info so it started at 0. will be ok for next range.

i go to sleep ... wake up in 5 hours ...:cry:

[QUOTE=tnerual;90137]two more question: Did 1.3.2 write this info in the log file or at the end of the factors file or nowhere except on screen ? is it possible to split #factors by sierpinski/riesel ?
[/QUOTE]
The number of factors is not currently recorded anywhere, just displayed on the status line. I will also write it to the log file once the range is finished in the next version.

It is no problem to keep track of the number of -1/+1 factors found, but there may not be enough room left on the status line to display the results. I'll consider this.

[QUOTE]
i suppose it read the number of factor from the checkpoint file and version 1.3.1 didn't write the info so it started at 0. will be ok for next range.
[/QUOTE]
That's right, the total will not be correct if the range was started with an earlier version.

[QUOTE=tnerual;90137]i suppose it read the number of factor from the checkpoint file and version 1.3.1 didn't write the info so it started at 0. will be ok for next range.[/QUOTE]

Ah, okay. I thought, he would just count the number of lines in the factorsNNNN.txt file.

Just found version 1.3.3 on the server.
Could you please tell us, what´s new in this version?