Sieve Benchmark Thread

[Historian]

Let's get the ball rolling on this one.

Processor: Pentium 4 3.4 GHz

tpsieve for the variable n-range: 5M p/sec
tpsieve for a single n: 71.5M p/sec
NewPGen for a single n: 86M p/sec
NewPGen for "Operation Megabit Twin": estimated to be 80 hours for 1T

[gribozavr]

CPU: Intel i5-750 (all 4 cores loaded).
tpsieve on x86_64 Linux for n=480000-485000: 108M p/sec.

[mdettweiler]

Originally Posted by Historian

NewPGen for "Operation Megabit Twin": estimated to be 80 hours for 1T

FYI, this converts to 3472222 p/sec, i.e. 3M p/sec since this very rough estimate is only good to one significant figure. (Just to put this in perspective with the other p/sec estimates.)

[Historian]

Originally Posted by mdettweiler

FYI, this converts to 3472222 p/sec, i.e. 3M p/sec since this very rough estimate is only good to one significant figure. (Just to put this in perspective with the other p/sec estimates.)

From what I've seen, the Megabit Twin project goes through a range of k, not a range of p. So that's ~3.5M k/sec, not 3.5M p/sec.

[mdettweiler]

Originally Posted by Historian

From what I've seen, the Megabit Twin project goes through a range of k, not a range of p. So that's ~3.5M k/sec, not 3.5M p/sec.

Ah, right, I see now...most of the prime search efforts I've worked with deal with relatively small ranges of k, and thus I am used to always having an unqualified reference to the suffix "T" refer to p, not k. Since in this project both values are of magnitudes that can be reasonably referred to in T, I would suggest that in the future qualifiers be used: for example "k=1T" instead of just 1T, leaving the latter (or even better, p=1T) strictly for p references.

[amphoria]

You can also calculate a rate in p/sec. We are currently sieving to p=100e9 and therefore 80 hours translates to 347k p/sec. Not very fast, but NewPGen has to break a 1T k range into almost 250 pieces until it gets to p=1e9.

[henryzz]

Originally Posted by amphoria

You can also calculate a rate in p/sec. We are currently sieving to p=100e9 and therefore 80 hours translates to 347k p/sec. Not very fast, but NewPGen has to break a 1T k range into almost 250 pieces until it gets to p=1e9.

It is possible to change the level of the recombine. Just set a limit on the sieve to shortly after you estimate 1/250(I would recommend 1/300 or less in case of mistakes) are remaining. That could in theory mean its possible to combine really early like 1e6 or something like that.
I will do a test now to see vaguely when.
edit: ~p=4e4 would do the trick nicely

[Flatlander]

Originally Posted by henryzz

It is possible to change the level of the recombine. Just set a limit on the sieve to shortly after you estimate 1/250(I would recommend 1/300 or less in case of mistakes) are remaining. That could in theory mean its possible to combine really early like 1e6 or something like that.
I will do a test now to see vaguely when.
edit: ~p=4e4 would do the trick nicely

You saved me a job.
I was about to do some tests. So, you are suggesting sieving to just 40,000 then again to 100G and it will fit into 485Mb? Just making sure I've got it right.

[Oddball]

Originally Posted by Flatlander

You saved me a job.
I was about to do some tests. So, you are suggesting sieving to just 40,000 then again to 100G and it will fit into 485Mb? Just making sure I've got it right.

The default option for NewPGen is to sieve to 1G, then to 100G. I don't know whether it's possible to change it to what you were suggesting.

[Flatlander]

I meant run it once to 40,000 then manually load it again to 100G.

[henryzz]

Originally Posted by Flatlander

You saved me a job.
I was about to do some tests. So, you are suggesting sieving to just 40,000 then again to 100G and it will fit into 485Mb? Just making sure I've got it right.

That should work. Once each bit is sieved upto the limit set(in Options|Sieve Until in windows) they will be comibined into one file which should be in theory small enougth to fit into 485Mb. I haven't tested this although I have done something like this to combine early(not really early like this) before so I know that bit works. It's the 485Mb bit that I am not so certain over. It depends whether the memory usage is just number of candidates or if it is also effected by distance between candidates etc.