First, congrats! Awesome work and appreciate you sharing more. Second: I'm confused by something in your readme. It says: > For Mersenne primes search, the PRP test is by far preferred over LL, such that LL is not used anymore for search. But later notes that PRP is computationally nearly identical to LL. Was that sentence supposed to say TF and P-1 instead of PRP or am I misunderstanding something about the actual c…
Tell HN: GpuOwl/PRPLL, GPU software used to find the largest prime number
11–20 of 44 posts
Re: Tell HN: GpuOwl/PRPLL, GPU software used to find the largest prime number
#12First, congrats! Awesome work and appreciate you sharing more. Second: I'm confused by something in your readme. It says: > For Mersenne primes search, the PRP test is by far preferred over LL, such that LL is not used anymore for search. But later notes that PRP is computationally nearly identical to LL. Was that sentence supposed to say TF and P-1 instead of PRP or am I misunderstanding something about the actual c…
The PRP test has the same computational cost as an LL test. The reason why GIMPS now prefers to do PRP tests instead of LL tests is because an efficiently verifiable proof-of-work certificate was developed for PRP tests [1]. [1] https://doi.org/10.4230/LIPIcs.ITCS.2019.60
Re: Tell HN: GpuOwl/PRPLL, GPU software used to find the largest prime number
#13Re: Tell HN: GpuOwl/PRPLL, GPU software used to find the largest prime number
#14Some topic ideas: - Why use OpenCL when implementing GPU software - Does it run on AMD or on Nvidia GPUs? - How does the primality test implemented in GpuOwl work? - How fast is it to test a Mersenne candidate? - Why use FFTs? how large are the FFTs? - What do you use for sin/cos?
https://x.com/HotAisle/status/1848780396609106359
If someone can come up with a way to perf test this against an H100, hit me up! It seems like something that could make a fun competition given the use of OpenCL. =)
Re: Tell HN: GpuOwl/PRPLL, GPU software used to find the largest prime number
#15Re: Tell HN: GpuOwl/PRPLL, GPU software used to find the largest prime number
#16Re: Tell HN: GpuOwl/PRPLL, GPU software used to find the largest prime number
#17I'd also like to draw attention that a lot of this work was sponsored by IMC the market maker, Mihai's employer.
Re: Tell HN: GpuOwl/PRPLL, GPU software used to find the largest prime number
#18Why do you use OpenCL instead of CUDA?
OTOH CUDA only works on Nvidia, and that's a major limitation.
GpuOwl uses heavily FP64 ("double" floating point), and FP64 is more readily available at consumer prices on AMD GPUs. We (the GIMPS project) use a lot of Radeon VII and Radeon Pro VII GPUs, which have great FP64 at a cheap price (I am personally running 8x Radeon Pro VII that I bought new for about $300 a piece).
So you see, for us AMD GPUs are the first citizen. Of course I want to support Nvidia GPUs as well, and OpenCL allows that. Luke Durant did run GpuOwl on a lot of Nvidia GPUs in the cloud, and I'm happy GpuOwl did work well for him on Nvidia.
Re: Tell HN: GpuOwl/PRPLL, GPU software used to find the largest prime number
#19Hi, I've got few questions: 1). What profiling tools do you use for GPU code? 2). Where one would start, in terms of learning resources, about coding using inline GPU assembler? 3). Do you verify GPU assembler generated by a compiler from C/C++ code, in terms of effectiveness? If so, which tools do you use for that? 4). Is SIMD on GPUs a thing? 5). What are the primary factors being taken into account by you (cache s…
1. My profiling is rudimentary but effective. I measure per-kernel execution time with OpenCL events (which register with high accuracy start/end times w. practically no overhead), and also I continously measure per-iteration time by dividing wall-time for blocks of 20'000 iterations by that nb. These measuremens are consistent and sensitive. 2. I'm not aware of good learning resources. Explore existing such code, e.…
Re: Tell HN: GpuOwl/PRPLL, GPU software used to find the largest prime number
#20First, congrats! Awesome work and appreciate you sharing more. Second: I'm confused by something in your readme. It says: > For Mersenne primes search, the PRP test is by far preferred over LL, such that LL is not used anymore for search. But later notes that PRP is computationally nearly identical to LL. Was that sentence supposed to say TF and P-1 instead of PRP or am I misunderstanding something about the actual c…
The PRP test has the same computational cost as an LL test. The reason why GIMPS now prefers to do PRP tests instead of LL tests is because an efficiently verifiable proof-of-work certificate was developed for PRP tests [1]. [1] https://doi.org/10.4230/LIPIcs.ITCS.2019.60
We used to use the LL test because the LL result is a bit stronger than the PRP result, LL stating that the number is prime, while PRP saying only that it is likely prime. This is the reason LL is still used as an after-test following any successful PRP discovery, as it happened for the most recent M52 as well.
The first transition from LL to PRP happened because a very strong and cheap error-checking algorithm, that we call "the Gerbicz error check", was discovered by Robert Gerbicz. This error-check in its most efficient form only works for PRP not for LL. This error-check allows to verify the correctitude of the computation, as it progresses on the GPU, with high confidence and low overhead. It does protect against a lot of HW errors originating from e.g. the GPU VRAM overheating, the GPU having been under-volted too aggressively, bad VRAM; but also from SW bugs and from FFT precision issues.
As the test of a single exponent takes a long time (let's say 24h on a fast GPU), having confidence that this long computation is proceeding along correctly instead of wasting cycles is a great benefit from the error-check.
The second step of the transition from LL to PRP happened when the PRP proof was introduced, following on the ideas from the VDF (Verifiable Delay Function) article, which allowed to verify cheaply that a PRP test was indeed executed correcty. This eliminated the need for the Double Check (DC) which was standard procedure with the LL test; practically speeding the process up with 100%.