- **Riesel Prime Search**
(*https://www.mersenneforum.org/forumdisplay.php?f=59*)

- - **RSP Sieve Files for k*2^n-1 from PrimeGrid**
(*https://www.mersenneforum.org/showthread.php?t=18255*)

It is irrelevant for you that you are wasting energy that it is not yours and you didn't understand my point. Take out 4M files from your big sieve file and keep sieving. Anyway, that's my energy efficient analyst opinion but for me you can keep sieving whatever ranges you want.
I only care about my computers efficiency and electricity bills. Carlos |

[QUOTE=pinhodecarlos;350322]It is irrelevant for you that you are wasting energy that it is not yours and you didn't understand my point. Take out 4M files from your big sieve file and keep sieving. Anyway, that's my energy efficient analyst opinion but for me you can keep sieving whatever ranges you want.
I only care about my computers efficiency and electricity bills. Carlos[/QUOTE] If the sieve time for a range was linear with the amount of candidates, yes we would have done smaller ranges. But that is not the case so we will continue to sieve as it is. The file 3M-6M takes x sec. that does not mean that 5M-6M takes x/3 sec. Do some tests and you will see for your self. Lennart |

I don't want to discuss something that you don't understand. Let's stop the discussion, ok?
Carlos |

:smile:[QUOTE=pinhodecarlos;350326]I don't want to discuss something that you don't understand. Let's stop the discussion, ok?
Carlos[/QUOTE] |

[QUOTE=pinhodecarlos;350216]Just been playing around with these latest sieved files up to ~303P and thereĀ“s no difference from 2013-07-08 files until you reach 3950k. I think for the ones already going beyond 4M you can have less candidates to test.
For example for k=5 from 3980-3990 I got less 10 candidates to test but for 3950-3960 only one less candidate. From 3910-3950 number of candidates were equal. These shows me that for sieved file up to 4M it is already oversieved. They need a month to sieve 10P and 10 candidates can be done in less than 24 hours. PrimeGrid should now be concentrated on sieving the 5M and 6M files up to 400P.[/QUOTE] Carlos- If I read this correctly, you're saying the file has no difference all the way from 3000 to 3950? That sounds like a pretty big error in the sieve process. Or do you mean that just 3910 to 3950 for just k=5 has no change? That would be part of the random nature of sieving. If you mean the latter, I have no idea how you compute that the file is oversieved. Please explain your calculation? |

[B][U]RSP4M[/U][/B]
[B]rsp4M_20130819.abcd[/B] - (141,781,643 terms) p~303P rsp4M_20130708.abcd - (141,922,841 terms) p~291P rsp4M_20130531.abcd - (142,068,066 terms) p~280P [B][U]RSP5M[/U][/B] [B]rsp5M_20130819.abcd[/B] - (141,803,092 terms) p~303P rsp5M_20130708.abcd - (141,944,107 terms) p~291P rsp5M_20130531.abcd - (142,088,967 terms) p~280P [B][U]RSP6M[/U][/B] [B]rsp6M_20130819.abcd[/B] - (141,768,546 terms) p~303P rsp6M_20130708.abcd - (141,909,836 terms) p~291P rsp6M_20130531.abcd - (142,054,353 terms) p~280P Here are the last files. I have not compared any specific K Lennart |

Lennart-
Those numbers look pretty consistent for candidates removed per 1P sieved, mostly ruling out an error- though, as happened previously, it's possible there are errors in k=5. Since I like computing sieve efficiencies myself, can you give me an idea of the sieve rate in T/day (or whatever units you find convenient) and what card you sieve with? I don't mind doing the calcs myself instead of asking Carlos to explain it to me. |

I updated test files for k=5, 15, and 17 based on the latest file of Aug. 19 to respective threads.
I agree that the 3-4M range is excessively oversieved! The candidates can be removed faster by primality tests. And finally, regarding the difference of k=5 test files between the previous sieving file (released in July) and this one, there are now 48 candidates less, and they appear to be almost uniformly distributed between 3027110 and 3980308. |

[QUOTE=Kosmaj;350421]I updated test files for k=5, 15, and 17 based on the latest file of Aug. 19 to respective threads.
I agree that the 3-4M range is excessively oversieved! The candidates can be removed faster by primality tests. And finally, regarding the difference of k=5 test files between the previous sieving file (released in July) and this one, there are now 48 candidates less, and they appear to be almost uniformly distributed between 3027110 and 3980308.[/QUOTE] What hardware do you use when comparing sec/f ? most sieving is done with GPU's. If you compare with CPU sieve time I can agree, but most sieving are done with GPU's. I will ask Jim if he can give more info about the removal rate. Here is some timings for a range on a GTX480 Sieve started: 303675222000000000 <= p < 303675231000000000 Thread 0 starting Detected GPU 0: GeForce GTX 480 Detected compute capability: 2.0 Detected 15 multiprocessors. Thread 0 completed Sieve complete: 303675222000000000 <= p < 303675231000000000 count=223575636,sum=0xd1617f2096f164d2 Elapsed time: 1067.52 sec. (1.09 init + 1066.42 sieve) at 8439596 p/sec. Processor time: 198.03 sec. (1.09 init + 196.94 sieve) at 45699162 p/sec. Average processor utilization: 1.00 (init), 0.18 (sieve) called boinc_finish The fastest card will do this range on 600 sec Normal speed on those ranges is 10min to 30 min depending on the card. Lennart |

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. |

Lennart-
Do you know what the limits of the software are? Max p-value? If a 3M range is much more efficient than 2M, would a 4M or 5M range be yet more efficient? Since 6-9M has barely started, it may be wiser to do 6-10M or even 6-12M for greater efficiency. Is there a reason not to run a bigger n-range? One more idea: It may make sense to stop this sieve now, run 6-9M until 300P, and then add 5-6M to the 6-9M sieve and continue with 5-9M up to 800P or more. I thought this should have been done with 2-3M added in to 3-6M from 100P to 150P. -Curtis |

All times are UTC. The time now is 12:56. |

Powered by vBulletin® Version 3.8.11

Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.