4 ms·
I've calculated ~20kB to store this number in particular. GPU __shared__ memory is 64kB. A 1024-wide workgroup would be able to store 4096 bytes per register,
by dragontamer 4y ago
I've calculated ~20kB to store this number in particular.
GPU __shared__ memory is 64kB. A 1024-wide workgroup would be able to store 4096 bytes per register, if the whole workgroup was just working on one number. So ~6 registers x 1024 shader workgroup to store the full 20kB number.
__shared__ memory would allow for very quick shader-to-shader communications.
I think... it can work. But its difficult for me to visualize the full program. Its going to be complex, but probably doable. Its also not really a design pattern that a lot of GPU code (ex: Thrust) works in very well, you'd have to use harder to use libraries like CUB instead.
- pclmulqdq 4y agoTo be clear, this problem (prime searching) works well on a single compute node. It doesn't work well if you have to scale to many nodes, because communication latency quickly bounds your speed. That's why GIMPS is the way it is: with volunteers offering computers that are separated and do a siloed calculation.
- dragontamer 4y agoI can believe that. But the fact that this was done on a Threadripper 3990x, a high-core count (but slow interconnect / core-to-core communication) kind of computer, makes me believe that there's a degree of parallelism in this problem. Otherwise, another computer (ie: higher GHz / less core count) could have been used instead. --------- I really don't know this specific algorithm: ECPP. It comes down to how that works... especially its parallelization.
- pclmulqdq 4y agoAFAIK it comes down to efficient FFTs for multiplying the large numbers, which are well-suited to GPUs, and this could likely have been done a lot faster on a GPU. I'm guessing there just isn't a good CUDA implementation out there.