Time for some estimatingoutloud:
a 9G range takes 20 minutes on this 480GTX. That's 27G/hr, or 600G/day.
According to Lennart's sievedata post, each 1P sieved removes about 12,000 candidates from 34M, or 36,000 from the entire sieve. 1P/600G = 1650 GPUdays to remove 36,000 candidates, or 22.5 candidates per GPU day.
Recall that the srsieve series of programs scales with the squareroot of nrange, so removing 34M and continuing to sieve 46M would not result in the sieve running 50% faster it would be more like 25% faster while finding 66% of the factors, a net decrease in efficiency. If this GPU sieve scales the same way, sieving 46M might produce something like 18 factors per day. I did lots of calculations back in 200910, and found that a factoroftwo nrange was small enough that breaking off the lower end of the sieve would not produce a gain in efficiency one should just run the entire sieve until the average LLR time per test matched the sieve. I don't know if this sieve code scales like srsieve...
My GPU (460M) can complete 3.5 CudaLLR tests per day at n=5M, the rough mean. The 480 Lennart cites might be 4050% faster let's say 4.5 tests/day as a guess. So, the sieve is currently 5x more efficient than CUDALLR on the typical candidate.
However, a large number of the k's in this sieve will never be tested. If less than 20% of the k's will be tested ever, then only 20% of the factors found via sieving "matter". 20% of 22.5 is 4.5 factors per day, exactly the rate LLR runs at. Carlos has observed that CPUs are more powerefficient at LLR than GPUs, but I am making an assumption that those who run BOINC for this project woudl run their GPUs on something anyway, so I may as well compare CUDALLR to GPUsieve.
So, one's opinion of optimal sieve depth revolves around one's opinion of how much of this sieve will ever be tested. I believe 20% is optimistic for the fraction of k's that will be tested, so I think primegrid has reached the optimal level at this time.... but I missed something: this sieve finds factors for riesel and proth numbers at the same time! So it's finding twice as many factors as assumed above, and thus only 10% of the k's need ever be tested to justify its current 300P level.
So, how many k's do you think will ever be tested from 36M? Do we have any idea how many proth k's will be tested? My arbitrary guess is 15% sounds about right, making 450P the optimal depth for this sieve. RPS will use 5300, NPLB 3001000, Peter 10001300. That's 13% right there. I don't know a thing about the proth side.
