Sieve:- Pick A Range

[Joe O]

And now to answer:

has the optimal depth been calculated for this sieve?

Yes, it has, many more times than the question has been asked. Actually a better term is "optimal zone" since we have many different CPU types out there supporting us. What is different this time, is the impact of the last prime found, and this new development. Also different, is the answer:

We will soon be entering the optimal zone!

Just before the last prime was found we had calculated 90P-95P as the optimal range to stop depending on CPU type. This was lower than our previous announcement of 100P-110P. We have been closely monitoring this since the last prime was found and had just about concluded that 85P-90P would be the optimal range to stop. Then came the announcement of a new GWNUM library. We will have to wait for a new LLR to include the new GWNUM 26.2 library, announced three days ago, to really calculate the new optimal range to stop sieving, but the following two points from the announcement:
1) Faster FFTs for most SSE2-capable CPU architectures.
2) More FFT lengths supported.
indicate that the new LLR, when available, will be faster. How much faster? From 5% to 10% depending on the CPU has been reported for benchmarks. Even ~20% for I5's.
So we need to consider when to stop sieving, and sooner rather than later.

Let the discussion begin!

[Sloth]

What about the GPU sieve efforts? I have not looked at the time from the GPU vs the CPU. If GPU has a nice speed boost it might be worth while to keep going on GPU and drop doing CPU sieve.

Is there even a GPU sieve possible for this project? I have looked at the PG sieve threads but have not payed close attention to what projects are currently working and what projects they hope to add.


S.

[mdettweiler]

Originally Posted by Sloth

What about the GPU sieve efforts? I have not looked at the time from the GPU vs the CPU. If GPU has a nice speed boost it might be worth while to keep going on GPU and drop doing CPU sieve.

Is there even a GPU sieve possible for this project? I have looked at the PG sieve threads but have not payed close attention to what projects are currently working and what projects they hope to add.


S.

The application PrimeGrid uses for sieving their Proth Prime Search on CUDA is ppsieve. ppsieve, unlike sr2sieve, is optimized for k-heavy sieves (like NPLB and PrimeGrid's); for sieves with only a handful of k's like PSP/SoB's, it will likely be slower than sr2sieve when comparing CPU versions of both. (The crossover point, according to ppsieve's developer, is around 1/3000 k/n ratio.)

However, due to the sheer speed of the GPU, ppsieve-CUDA may still be faster than sr2sieve-CPU even on PSP's sieve. It's definitely worth a try at any rate.

I have access to a GTX 460 GPU recently purchased by my fellow NPLB admin Gary (gd_barnes); I haven't yet set up ppsieve on it but the closely related tpsieve works perfectly. I'm hoping to set up ppsieve within the next day or two and will make a point to get some speed figures for PSP's sieve when I run some tests on it.

[Joe O]

It is important to note that the manual sieve for PSP and SoB will continue.

For manual (half automated) reservations, please refer to the Combined Automated Reservation System, sign up, if you don't have an account yet, and grab your range. The software you need can be found here (read the readme); you will need the data file as well. When you find some factors, you can report them at the Sieveimport page.
Note: you might need to drop in a short note here in the forum so that your user name can be integrated in the Sieve Import page.
Here is a graph about the progress.

Some additional stats: http://www.psp-project.de/sievestats.php

[runesk]

Much of the math involved in this are well beyond my grasp and understanding.

I got a message requesting my input, but I feel that I have no input of value.

.R

[opyrt]

Originally Posted by mdettweiler

Just curious, has the optimal depth been calculated for this sieve?

That's a very hard question to answer as there are so many things to take into consideration. One of them is that PSP and SoB are at different n-values.

But we could try to gather some information on the subject and see where we are at. The current PSP LLR tests take 4-5 days to run at the moment (on a decent XEON), depending on k (as the higher k's require a higher FFT for LLR). And I suspect optimal sieve zone is reached for PSP. However, this is a combined sieve, so:

Does anyone know how long a typical SoB LLR test is these days?
John over at PG knows the hit rates of current sieving.

I would say that if the average find time of a factor is more frequent than the length of a SoB test times two, sieving is still worth while. And the average find time for a factor should be calculated for 64bit computers only, as sieving with 32bit computers is a huge waste.

[Joe O]

Originally Posted by Joe O

It is important to note that the manual sieve for PSP and SoB will continue.

For manual (half automated) reservations, please refer to the Combined Automated Reservation System, sign up, if you don't have an account yet, and grab your range. The software you need can be found here (read the readme); you will need the data file as well. When you find some factors, you can report them at the Sieveimport page.
Note: you might need to drop in a short note here in the forum so that your user name can be integrated in the Sieve Import page.
Here is a graph about the progress.

Some additional stats: http://www.psp-project.de/sievestats.php

OK, we are going to take a break for a while. Manual reservations are now closed. When a more efficient sieve program becomes available, we will re-evaluate this decision.

[VJS]

probably be a good idea to do one last dat update once all factors are in and post it somewhere.