View Single Post
Old 2013-08-22, 07:02   #21
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

76328 Posts
Default

Time for some estimating-out-loud:
a 9G range takes 20 minutes on this 480GTX. That's 27G/hr, or 600G/day.

According to Lennart's sieve-data post, each 1P sieved removes about 12,000 candidates from 3-4M, or 36,000 from the entire sieve. 1P/600G = 1650 GPU-days to remove 36,000 candidates, or 22.5 candidates per GPU day.

Recall that the srsieve series of programs scales with the square-root of n-range, so removing 3-4M and continuing to sieve 4-6M 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 4-6M might produce something like 18 factors per day. I did lots of calculations back in 2009-10, and found that a factor-of-two n-range 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 Cuda-LLR tests per day at n=5M, the rough mean. The 480 Lennart cites might be 40-50% faster- let's say 4.5 tests/day as a guess. So, the sieve is currently 5x more efficient than CUDA-LLR 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 power-efficient 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 CUDA-LLR to GPU-sieve.

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 3-6M? 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 5-300, NPLB 300-1000, Peter 1000-1300. That's 13% right there. I don't know a thing about the proth side.
VBCurtis is offline   Reply With Quote