Join PrimeGrid
Returning Participants
Community
Leader Boards
Results
Other
drummers-lowrise
|
1)
Message boards :
Fermat Divisor Search :
Duplicate work?
(Message 138724)
Posted 1301 days ago by  serge
Didn't PrimeGrid in the past do exactly the same to other people's reservations at prothsearch.net ?
First this was promised:
"https://web.archive.org/web/20110608154530/http://www.prothsearch.net/index.html" wrote: Here is how it will work. PrimeGrid will reserve large ranges of k and n. It will perform both a first test and a double-check of all candidates. When it is within weeks of completing this reservation, it will place another reservation for a smaller range of k and n. Of note, some of these ranges will overlap ranges currently reserved to other searchers. PrimeGrid will NOT SEARCH those ranges.
That agreement was then spat upon by PrimeGrid. The ranges were poached by PrimeGrid, the hits were reported by mere days earlier than owners would find them.
So, it is interesting after a number of years to see how the atmosphere that was sowed by PrimeGrid is now being reaped.
|
2)
Message boards :
Number crunching :
Mega Prime finders by quantity found.
(Message 135221)
Posted 1400 days ago by serge
I've had a go at listing mega prime finders , by quantity found.
If I've made any mistakes please let me know and I'll fix them.
Is it ok if I humbly mention here that I happened to have found 43 mega primes, over some years?
I don't see you mentioning in your original post that only PrimeGrid primes exist in the world. Do they, really?
|
3)
Message boards :
General discussion :
Favourite Prime Number.
(Message 118541)
Posted 1938 days ago by serge
My favorite number is the 26th Eisenstein-Mersenne Norm prime: 3^2237561+3^1118781+1
My second favorite is the prime partitions number of a number which is square: partitions(14881^2)
|
4)
Message boards :
General discussion :
A new Mersenne prime was found (50th known)
(Message 112732)
Posted 2102 days ago by serge
See http://mersenneforum.org/showthread.php?t=22837
A day after Christmas a computer has reported a new Mersenne prime.
...finished (first) double-check:
Mxxxxxxxx is prime!
Congratulations to all GIMPS participants on their 20+ years of continuing team effort!
|
5)
Message boards :
News :
GFN-1048576 Mega Prime!
(Message 109845)
Posted 2219 days ago by serge
Extends https://oeis.org/A056993 (posted).
Congratulations!
|
6)
Message boards :
Generalized Cullen/Woodall prime search :
GCW-LLR is now open!
(Message 108874)
Posted 2275 days ago by serge
With GCW now above 2 million digits, when will the next prime be found?
At this size and assuming ~45-50-bit pre-factoring, 1 in ~150,000 tests may find a prime.
(Of course, once 150,000 tests will be done, the size will increase, and the goal posts will move further...)
How many units are processed per week on average? Divide one by the other and you will have the answer (+-90% CI).
|
7)
Message boards :
Generalized Cullen/Woodall prime search :
How to speed up (some) GCW units by 10%+
(Message 107909)
Posted 2330 days ago by serge
Maybe LLR's philosophy is "the client is always right!"
I.e.: If the input file calls for a test of a specific FFT or a "specific arrangement of bits", then that's what it will run (even if slower, because "this is the test that was ordered").
But it indeed doesn't follow this rule for powers of 2.
-bash-4.2$ llr -d -q"27*1024^10007+1"
Starting Proth prime test of 27*2^100070+1
Using all-complex FMA3 FFT length 10K, Pass1=128, Pass2=80, a = 11
27*2^100070+1 is not prime. Proth RES64: C14E6737D2E78E5E Time : 5.261 sec.
-bash-4.2$ llr -d -q"28*729^10007+1"
Base prime factor(s) taken : 3
Starting N-1 prime test of 28*729^10007+1
Using all-complex FMA3 FFT length 10K, Pass1=128, Pass2=80, a = 3
28*729^10007+1 is not prime. RES64: E83080E955E9B281. OLD64: B89182BC01BD1780 Time : 4.888 sec.
-bash-4.2$ llr -d -q"28*10000^10007+1"
Base factorized as : 2^4*5^4
Base prime factor(s) taken : 5
Starting N-1 prime test of 28*10000^10007+1
Using all-complex FMA3 FFT length 18K, Pass1=384, Pass2=48, a = 3
28*10000^10007+1 is not prime. RES64: 59CCA66A39ED54C4. OLD64: 0D65F33EADC7FE48 Time : 13.645 sec.
(and of course it is fully equipped to normalize the base, as a side effect of factoring the base for the purposes of the N-1 mechanics.)
PFGW does what it is ordered by the input file, too.
|
8)
Message boards :
Generalized Cullen/Woodall prime search :
How to speed up (some) GCW units by 10%+
(Message 107890)
Posted 2331 days ago by serge
It seems that in your client-server set up the ideal place to put the reformatter would be the primegrid_llr_wrapper. It would keep the initial task parameters, reformat for (c)llr, get the result back from (c)llr, report back to server as initially requested. Then the database, the server and the accounting code would be unchanged.
primegrid_llr_wrapper for now can do only:
▪ square simplification,
▪ k simplification
Later, it can be extended to recognize b being any power. See here -
Curiously, these numbers may be hard to recognize when written in standard form (emphasis mine).
For example, they may be like
18740*3^168662-1
which could be written
168660*3^168660-1.
More difficult to spot are those like the following:
9750*7^29250-1 = 9750*7^(3*9750)-1 = 9750*343^9750-1
8511*2^374486-1 = (8511*2^2)*2^(11*8511)*4-1 = 34044*2048^34044-1.
This is in fact how the GCWs for 25, 49, 121 will end up showing in UTM lists. (And this is how GW for b=4 looks, indeed.)
|
9)
Message boards :
Generalized Cullen/Woodall prime search :
How to speed up (some) GCW units by 10%+
(Message 107876)
Posted 2331 days ago by serge
For LLR it is not the number that matters, but the (k,b,n,c) form, and b is taken by it verbatim, as given.
I am not ready to go into a very deep explanation, but I will try to make an approximation to an explanation (not meant to be taken for that this is exact). With b=11, it is possible to form an array of length 640K where each element is a quasi-digit ("limb") in an unusual representation: some digit's weights are perhaps 11^6 and some digit's weights are 11^7, or something like that. (Off the top of my head, what I remember is that each limb on average is limited to keeping ~30 bits of information, or something like that.) Only powers of b can be used as limb weights.
In contrast if the number is entered with b=121, the program can only work with limbs of, say, 121^3 and 121^2. (It has less opportunities to pack, the larger the b.) For that reason it ponders the array of length 640K and thinks, "nah, some elements will be too large; gotta go for next FFT size", and so it does.
Long story short, using the simplest possible (k,b,n,c) (with b as low as possible) will lend more possibilities for more dense FFT arrays. If not only b=121, but also k is divisible by 11, the FFT size may be even smaller if (k,121,n,c) is transformed into (k/11,11,2*n+1,c).
As an aside, yes, it would be nice if LLR did it all itself, but as the timing test (shown earlier) demonstrates - it doesn't. But here's where we can help LLR and do transformation externally, server-side. The transformation logic is quite straightforward.[/i]
|
10)
Message boards :
Generalized Cullen/Woodall prime search :
How to speed up (some) GCW units by 10%+
(Message 107873)
Posted 2331 days ago by serge
Nothing of what I am about to write is new. Or difficult.
And it has already been discussed multiple times.
Observe that some the chosen bases for this particular sub-project happen to be squares.
25 = 5^2, 49 = 7^2, 121 = 11^2. Some people even know that this was a deliberate choice. I've been waiting for a workunit to arrive for one of these bases for a while, and now I have one.
The candidate is 754806*121^754806+1 which can also be easily regrouped as 754806*11^1509612+1.
Let's compare:
/home/serge/NumTheory/GCW> llr -d d.npg
Base prime factor(s) taken : 11
Starting N-1 prime test of 754806*121^754806+1
Using zero-padded AVX FFT length 720K, Pass1=320, Pass2=2304, a = 3
754806*121^754806+1, bit: 70000 / 5222413 [1.34%]. Time per bit: 5.654 ms.
/home/serge/NumTheory/GCW/2> llr -d d2.npg
Base prime factor(s) taken : 11
Starting N-1 prime test of 754806*11^1509612+1
Using zero-padded AVX FFT length 640K, Pass1=640, Pass2=1K, a = 3
754806*11^1509612+1, bit: 40000 / 5222416 [0.76%]. Time per bit: 4.698 ms.
That's 20% faster. (Results are similar for AVX2.)
Why is the server sending this workunit task as 754806*121^754806+1 ?
Isn't it trivial, server-side, to fetch the candidate from the database and if/when b=x^2, send it to the client not as
100000000000000:P:1:b:1
n n
but as
100000000000000:P:1:x:1
n 2n
In this particular case:
100000000000000:P:1:11:1
754806 1509612
Too hard to implement?
|
Next 10 posts
|
