4 ms·

> The HPC community is already used to GPUs — getting people to switch from GPUs to FPGAs requires larger benefits. It's worth pointing out that some scientist

> The HPC community is already used to GPUs — getting people to switch from GPUs to FPGAs requires larger benefits. It's worth pointing out that some scientists haven't even made the leap to CPGPU computing yet and are still relying upon OpenMP / multithreading on general purpose CPUs, even when a GPU would be clearly superior. Anecdotally, I remember hearing that climate science simulations are particularly bad about taking advantage of new architectures for speedups, an assertion which possibly is supported by the fact that climateprediction.net simulations took several days using all 8 cores on my laptop to finish. Neuroimaging is also pretty bad, since other than Broccoli [0], most toolkits for preparing analyses don't leverage GPUs, even though I'd wager 80% of the steps involved image manipulations / linear algebra. [0] https://github.com/wanderine/BROCCOLI https://github.com/wanderine/BROCCOLI

cjhanks 8y ago
In my experience, it's true. And it's unlikely to change - the simulation code was largely written in FORTRAN and C over a period of 50 years. This is in fact what makes Intel Phi so appealing to some.
- amirhirsch 8y ago
  12 years ago I worked on High Level Synthesis at Xilinx converting atmospheric moisture simulations from FORTRAN...
- nl 8y ago
  For C/Fortran using LAPACK it should be as simple as relinking. https://www.olcf.ornl.gov/tutorials/gpu-accelerated-libraries/ https://www.olcf.ornl.gov/tutorials/gpu-accelerated-librarie...
fulafel 8y ago
I think these scientists are the real winners. Computers just work for them, they don't need to jump through hoops - eg, rewrite their software for immature proprietary software architectures. Chasing that last 10x of performance at great cost is for the desperate!
physicsguy 8y ago
Massively depends on what you're doing as to whether it's possible, straightforward or useful to be honest. For many people it's fine, but there are plenty of people where the time investment is not worth it for a variety of reasons. It's nowhere near as simple as just porting things quickly unless you have a very simple code. For example, I work on coupled finite-element/boundary-element calculations in magnetics. Porting our finite element calculations to GPU is possible but pointless because the memory requirements are too high - we just got some V100s on our University supercomputer but they're only the 16gb versions, and the compressed boundary element matrix of the simulation I was running just yesterday was 22gb alone, let alone all of the other data! It's nothing like people who do simulations in, for example, fluid dynamics, because the interactions they look at are generally local, whereas in our field we have a dominating non-local calculation. If you instead use finite differences to tackle the problems we look at, then it's much less of a problem, but if you try and get into multi-GPU things you quickly run into the same memory issues because one of the calculations requires repeated FFT accelerated 3-D convolution to run in a reasonable amount of time, and in-place FFTs on multi-GPU can only be done on arrays that are < (memory on each GPU)/(Number of GPUs) because there needs to be an all-to-all communication. If you have 4 x 16gb V100s (which is $36k in my country), then that means the array you need to transform must be at most 4gb, and in practice it's less than that because we need to store other data on the GPU. That hugely limits the problems you can look at.

cjhanks 8y ago

In my experience, it's true. And it's unlikely to change - the simulation code was largely written in FORTRAN and C over a period of 50 years. This is in fact what makes Intel Phi so appealing to some.

amirhirsch 8y ago
12 years ago I worked on High Level Synthesis at Xilinx converting atmospheric moisture simulations from FORTRAN...
nl 8y ago
For C/Fortran using LAPACK it should be as simple as relinking. https://www.olcf.ornl.gov/tutorials/gpu-accelerated-libraries/ https://www.olcf.ornl.gov/tutorials/gpu-accelerated-librarie...

fulafel 8y ago

I think these scientists are the real winners. Computers just work for them, they don't need to jump through hoops - eg, rewrite their software for immature proprietary software architectures. Chasing that last 10x of performance at great cost is for the desperate!

physicsguy 8y ago

Massively depends on what you're doing as to whether it's possible, straightforward or useful to be honest. For many people it's fine, but there are plenty of people where the time investment is not worth it for a variety of reasons. It's nowhere near as simple as just porting things quickly unless you have a very simple code. For example, I work on coupled finite-element/boundary-element calculations in magnetics. Porting our finite element calculations to GPU is possible but pointless because the memory requirements are too high - we just got some V100s on our University supercomputer but they're only the 16gb versions, and the compressed boundary element matrix of the simulation I was running just yesterday was 22gb alone, let alone all of the other data! It's nothing like people who do simulations in, for example, fluid dynamics, because the interactions they look at are generally local, whereas in our field we have a dominating non-local calculation. If you instead use finite differences to tackle the problems we look at, then it's much less of a problem, but if you try and get into multi-GPU things you quickly run into the same memory issues because one of the calculations requires repeated FFT accelerated 3-D convolution to run in a reasonable amount of time, and in-place FFTs on multi-GPU can only be done on arrays that are < (memory on each GPU)/(Number of GPUs) because there needs to be an all-to-all communication. If you have 4 x 16gb V100s (which is $36k in my country), then that means the array you need to transform must be at most 4gb, and in practice it's less than that because we need to store other data on the GPU. That hugely limits the problems you can look at.