20230918, 19:42  #1 
Dec 2010
54_{8} Posts 
Experimental n=1.7M sieving
Not sure if this deserves its own thread, but there's a new experimental quad sieving program at https://github.com/galloty/qsieve that may or may not be faster than NewPGen and TwinGenX. The idea is that you'd sieve a range of n and k, make it small enough to fit in a GPU (16 GB of RAM?) and move on to another range until a twin and SG are found. For bitmap size optimization purposes, each range of n is 64 wide (n_max = n_min+63)
We could first start out with testing n=17000011700064 for k<70G, which should be good for most GPUs. Although the GPU version hasn't been finalized yet, a speedup of ~100x over the CPU version is expected based on what we've seen for similar k*2^n1 sieves. I'm on my phone and currently don't have access to a computer, but could someone run some benchmarks with it on a CPU and confirm that the results match NewPGen/TwinGenX? If the speed is fast enough, it may be a good idea to move from n=1700000 to n=170000117xxxxx once the current p=1047T sieve limit is exceeded. 
20230918, 20:28  #2 
Jun 2010
2^{4}×17 Posts 
If the program does turn out to be fast and reliable, should we just rethink the whole n=1.7M project and just do something like n=1.3M  2.0M for k<2G?

20230918, 20:54  #3 
"Mark"
Apr 2003
Between here and the
2^{4}·467 Posts 
Why choose that value for n?

20230918, 20:55  #4 
Dec 2010
2C_{16} Posts 
The drawback is that doing work just over a FFT threshold is not efficient. n=1708500 and n=1709000 take almost the same amount of time to test, but n=1709500 takes significantly longer than either of them.

20230918, 20:59  #5 
Dec 2010
2^{2}·11 Posts 
I think n=1.7M was chosen because it was just below the n=1.709M threshold, was a nice round number (both the 1,700,000 value and the >500,000 decimal digits length), and was a reasonable increase from the n=1.29M tests.
Are there better alternatives that you'd suggest? 
20230919, 01:31  #6 
Jun 2010
100010000_{2} Posts 
The question wasn't directed at me, but what about testing exponents that use a powerof2 FFT length? Those are more efficient:
https://www.mersenneforum.org/showpo...37&postcount=8 n=1700000 uses an FFT length of 168K. Perhaps testing one or more exponents with an FFT length of 128K or 256K would be better? 
20230919, 05:46  #7  
"Michael Kwok"
Mar 2006
1213_{10} Posts 
Quote:
Code:
Exponent FFT Length Testing Time 1290000 128K 0.374 ms/iteration 1311000 128K 0.374 ms/iteration 1312000 140K 0.439 ms/iteration 1430000 140K 0.439 ms/iteration 1431000 144K 0.464 ms/iteration 1470000 144K 0.465 ms/iteration 1471000 160K 0.474 ms/iteration 1631000 160K 0.475 ms/iteration 1632000 168K 0.559 ms/iteration 1700000 168K 0.557 ms/iteration 1709000 168K 0.555 ms/iteration 1710000 192K 0.572 ms/iteration 1951000 192K 0.572 ms/iteration 1952000 200K 0.654 ms/iteration 2029000 200K 0.654 ms/iteration 2030000 224K 0.688 ms/iteration 2270000 224K 0.688 ms/iteration 2271000 240K 0.737 ms/iteration 2425000 240K 0.734 ms/iteration 2426000 256K 0.777 ms/iteration 2586000 256K 0.775 ms/iteration 2587000 288K 0.912 ms/iteration 2898000 288K 0.914 ms/iteration Quote:


20230919, 15:18  #8  
Jun 2010
2^{4}·17 Posts 
Quote:


20230919, 16:23  #9 
Random Account
Aug 2009
Oceanus Procellarum
2^{3}·13·29 Posts 

20230919, 17:27  #10  
"Alexander"
Nov 2008
The Alamo City
3^{2}×113 Posts 
Quote:


20230919, 20:10  #11 
"Curtis"
Feb 2005
Riverside, CA
53·113 Posts 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
New GPU computing system (experimental)  SELROC  GPU Computing  26  20190727 05:40 
Unofficial experimental beta build  wombatman  YAFU  22  20160219 18:59 
Experimental lasieve4_64, compiled with MinGWw64!  Dan Ee  Factoring  40  20160208 20:32 
new experimental banners for GIMPS  ixfd64  Lounge  14  20071217 01:22 
Experimental confirmation of General Relativity  davieddy  Science & Technology  17  20070814 21:29 