| Author |
Message |
|---|
 Michael Goetz Volunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13804
ID: 53948
Credit: 345,369,032
RAC: 3,564
                              
|
|
We've reached the software b limit for GFN-16 on a CPU. These tasks are no longer available.
GPU tasks are still available.
This only affects GFN-16.
If you currently have CPU tasks selected for GFN-16, you won't be getting any more of them, so you'll have to select something else to run on your CPU.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
It would probably be possible to configure GFN-16 to use LLR when running on a CPU. LLR can handle extremely high b values. But I guess it is too slow to be worth the effort. /JeppeSN |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13804
ID: 53948
Credit: 345,369,032
RAC: 3,564
|
It would probably be possible to configure GFN-16 to use LLR when running on a CPU. LLR can handle extremely high b values. But I guess it is too slow to be worth the effort. /JeppeSN
They do not produce compatible residues:
C:\bench>genefer_windows64 -q "1234^4096+1"
genefer 3.3.4 (Windows/CPU/64-bit)
Testing 1234^4096+1...
Using FMA3 transform
1234^4096+1 is composite. (RES=244d1535d39789b7) (12663 digits) (err = 0.0000) (time = 0:00:02) 10:22:44
C:\bench>llr64 -d -q"1234^4096+1"
Base factorized as : 2*617
Base prime factor(s) taken : 617
Starting N-1 prime test of 1234^4096+1
Using all-complex FMA3 FFT length 2K, a = 3
1234^4096+1 is not prime. RES64: 378B6BA67180D76A. OLD64: A6A242F354828639 Time : 2.515 sec.
While running genefer with "-p" produces the same residue as LLR, I'm not sure if there's a way to get LLR to produce a residue that matches Genefer's PRP test.
____________
My lucky number is 75898524288+1 |
|
|
Yves GallotVolunteer developer
Project scientist
Send message
Joined: 19 Aug 12
Posts: 712
ID: 164101
Credit: 305,166,630
RAC: 0
|
It would probably be possible to configure GFN-16 to use LLR when running on a CPU. LLR can handle extremely high b values. But I guess it is too slow to be worth the effort. /JeppeSN
While running genefer with "-p" produces the same residue as LLR, I'm not sure if there's a way to get LLR to produce a residue that matches Genefer's PRP test.
genefer can generate LLR residues:
geneferocl_windows.exe -llr -q "1234^4096+1"
1234^4096+1 is composite. (RES=244d1535d39789b7 RES64=022A9B06450EF6F8) (12663 digits) (err = 0.0000)
cllr64.exe -d -q"1234^4096+1" -oFBase=2
1234^4096+1 is not prime. RES64: 022A9B06450EF6F8.
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13804
ID: 53948
Credit: 345,369,032
RAC: 3,564
|
It would probably be possible to configure GFN-16 to use LLR when running on a CPU. LLR can handle extremely high b values. But I guess it is too slow to be worth the effort. /JeppeSN
While running genefer with "-p" produces the same residue as LLR, I'm not sure if there's a way to get LLR to produce a residue that matches Genefer's PRP test.
genefer can generate LLR residues:
geneferocl_windows.exe -llr -q "1234^4096+1"
1234^4096+1 is composite. (RES=244d1535d39789b7 RES64=022A9B06450EF6F8) (12663 digits) (err = 0.0000)
cllr64.exe -d -q"1234^4096+1" -oFBase=2
1234^4096+1 is not prime. RES64: 022A9B06450EF6F8.
Ok, it's theoretically possible. The same could be said of GFN-15, and GFN-17-MEGA.
I don't see it happening, however. Somebody would need to have a really good explanation for why bringing a NerfTM ball to a gunfight is so important. :)
____________
My lucky number is 75898524288+1 |
|
|
|
|
Ok, it's theoretically possible. The same could be said of GFN-15, and GFN-17-MEGA.
I don't see it happening, however. Somebody would need to have a really good explanation for why bringing a NerfTM ball to a gunfight is so important. :)
Nerf--TM...🤣🤣🤣🤣🤣
Just a side question, but then why are GFN22/20/19 CPU versions here? Virtully no one would be crunching them unless they're running 24/7. But most people crunching 24/7 know better to crunch a SoB using that much time since the GPUs(machine guns) are so much quicker than CPUs(NerfTM ball).
Therefore, IMHO PG should just altogether cancel CPU-GFN for all GFN except GFN21&22, which could potentially support MTing. I don't know all the info behind the scenes so point out any errors I have in my thinking!
____________
My lucky number is 6219*2^3374198+1
 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13804
ID: 53948
Credit: 345,369,032
RAC: 3,564
|
Just a side question, but then why are GFN22/20/19 CPU versions here?
Not everyone has a GPU, so we permit it where possible. It doesn't mean it's a good idea to run it.
The exception is DYFL -- that's simply too slow, so we don't allow it even though it would run.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
My computers have only one GPU (or none) but many CPU cores. As I am trying to increase WUProp application hours I find it convenient to run the long running WUs on the GPU and the short running WUs on a few CPU cores. The funny thing is even when running GFN tasks on my CPU I still occasionally turn mine in before the final wingman.
I have also noticed that while GFN-17 Mega run at near 100% on my 1660 Ti, the GFN-16s can't get above 75% GPU utilization.
____________
Werinbert is not prime... or PRPnet keeps telling me so.
Badge score: 12x3 + 1x4 + 2x6 + 2x7 + 1x8 + 1x9 + 1x10 = 93 |
|
|
