But that makes me think, what prevents people from running these calculations on the GPU? Even the memory is shared - the few 100 gflops they get out of the M1 ultra is pocket change in GPU terms.
NVIDIA GPUs have much more ubiquitous programming models, from CUDA C++ to OpenMP (both C++ and Fortran), allowing them to be much more useful.
AMD ROCm (a CUDA clone, but not managed too well...) isn't in a great state today, but it definitely provides an OpenMP compiler, for C++ only though, Fortran is not covered.
Intel GPUs have a much better SW story on all fronts for GPGPU than AMD's, and OpenMP is supported for both C++ and Fortran there.
tldr: if you want to run this code on GPUs, the two vendors to look for are NVIDIA and Intel. The others just don't have the software stack to do so. (without more heavyweight porting)
Of course, optimising for GPUs also adds work. That said, an OpenMP version is a very good starting point.
The M1 architecture only allows the CPU to access a fraction of the memory bus, it is around 25% of the total bandwidth or so iirc. The rest has to go to the GPU or NPU or one of the other units, so even if your FP64 code was super shitty emulated with no hardware support, on paper you should be able to quadruple performance by utilizing it.
If you can "pre-digest" it at all, and then push it back from the GPU to the CPU, that might be another viable approach.
Of course none of this will exist out of the box in some 90s FORTRAN code!
That's what's done by Intel for their newer consumer GPUs AFAIK, zero FP64 units present on die, but an emulation mode can be enabled to expose that support. (which is then done by software on the GPU)
> it is around 25%
50%, ~ 200GB/sec on an M1 Max out of ~ 400GB/sec
For CFD it is a different problem. In each time-step you essentially solving a linear system Ax=b, so even if you are looking at element x(100,100,timeperiod2) you need to also know the value of the element x(1,1,timeperiod1).
There are some algorithms that decouple the problem by introducing residuals for each element and then trying to iteratively reduce them, but as you can see, it is not a linear increase in speed as someone would had expected by looking at the GPU specs.
TLDR: Yes you can do CFD with GPUs, but dont expect miracles.
Nobody uses GPUs for "linear speedups by looking at GPU specs". That's not how accelerators are measured.
It is not standard in OpenFoam (only though rapidCFD) or Ansys (only this year they made an announcement for full acceleration).
"GPUs are fantastic for solving linear systems."
*Some* linear systems. They are horrible for sparse algebra.
So this entire thread is kind of pointless with regard to many real-world use cases.
> “If a CPU doesn't run the OS and software I need to run, it might as well be a GPU or …”
> So this entire thread is kind of pointless with regard to many real-world use cases.
Does this kind of reasoning apply to everything that doesn’t suit your unique personal needs?
Personally I think this is an interesting thread, but I don’t use the qualifier of “is it useful to me” to determine whether something is interesting.
Philosophical purity rarely provides top performance. And that's OK, slow and steady works for me, because I'm not doing max performance computing.