3 ms·

I took a GPU programming course in college and even did a year long thesis implementing a RK4 integrator to solve a particular differential equation. In my the

I took a GPU programming course in college and even did a year long thesis implementing a RK4 integrator to solve a particular differential equation. In my thesis work, the main issue I encountered was that RK4 was a vector operation, but GPUs are matrix processors. The bottleneck in the application was the memory bandwidth, not the GPU itself. We ended up with a speedup of 16 w.r.t a single-core CPU implementation of the same problem. The article claims a speedup of 35-60, but I see they also compared the GPU to a single-core CPU implementation. This is not a fair comparison. If they want to be fair, they need to utilize the full capabilities of a CPU (think performance per socket, not performance per core). I think Intel makes 18-core CPUs now; with a properly implemented multi-threaded RK4 (not very difficult) I'd expect the speedup to be closer to 2-12 instead of 35-60.

redcalx 11y ago
> I think Intel makes 18-core CPUs now Xeon Phi is an x86 CPU with many more cores that plugs into a PCI express slot; a sort of halfway between the prevailing GPU and CPU models. They also have 512bit wide SIMD instructions, which should help a lot towards the speed of your vector based computations (AVX2 is 256 bits wide).
deleted 11y ago
[deleted]
pflats 11y ago
>In my thesis work, the main issue I encountered was that RK4 was a vector operation, but GPUs are matrix processors. The bottleneck in the application was the memory bandwidth, not the GPU itself. We ended up with a speedup of 16 w.r.t a single-core CPU implementation of the same problem. I know more than one large property/casualty company that still uses APL[1] internally, which is a matrix language. I don't have any close friends on the health/life of things, though. Would be interesting to see how that runs on a GPU. That said, I imagine most places would rather throw more metal at a problem than have to move their actuaries to a new language. Processors are a lot cheaper than actuaries. [1] https://en.wikipedia.org/wiki/APL_(programming_language) https://en.wikipedia.org/wiki/APL_(programming_language)
- dybber 11y ago
  That is the topic of my Ph.D. APL for GPUs. We've done type inference for a good subset of APL, and compiled it into a small (mostly) functional language. We can generate fused C-code that performs very well and I'm working hard at an OpenCL backend. [1]: http://www.elsman.com/pdf/array14_final.pdf http://www.elsman.com/pdf/array14_final.pdf
  - eggy 11y ago
    I still use J because I think array, or matrix-based languages are a nice fit for the multi-core CPUs and GPUs available for such computations. Wes McKinney of Pandas was/is studying q and J for his current work. There's a reason these languages have been used actuaries and quants to analyze time series, and columnar data. And they're concise which some criticize for readability, but like Math symbols once you know them, they are very powerful. [1] http://conceptualorigami.blogspot.co.id/2010/12/vector-processing-languages-future-of.html?m=1 [2] https://scottlocklin.wordpress.com/category/tools/j/

redcalx 11y ago

> I think Intel makes 18-core CPUs now Xeon Phi is an x86 CPU with many more cores that plugs into a PCI express slot; a sort of halfway between the prevailing GPU and CPU models. They also have 512bit wide SIMD instructions, which should help a lot towards the speed of your vector based computations (AVX2 is 256 bits wide).

deleted 11y ago

[deleted]

pflats 11y ago

>In my thesis work, the main issue I encountered was that RK4 was a vector operation, but GPUs are matrix processors. The bottleneck in the application was the memory bandwidth, not the GPU itself. We ended up with a speedup of 16 w.r.t a single-core CPU implementation of the same problem. I know more than one large property/casualty company that still uses APL[1] internally, which is a matrix language. I don't have any close friends on the health/life of things, though. Would be interesting to see how that runs on a GPU. That said, I imagine most places would rather throw more metal at a problem than have to move their actuaries to a new language. Processors are a lot cheaper than actuaries. [1] https://en.wikipedia.org/wiki/APL_(programming_language) https://en.wikipedia.org/wiki/APL_(programming_language)

dybber 11y ago
That is the topic of my Ph.D. APL for GPUs. We've done type inference for a good subset of APL, and compiled it into a small (mostly) functional language. We can generate fused C-code that performs very well and I'm working hard at an OpenCL backend. [1]: http://www.elsman.com/pdf/array14_final.pdf http://www.elsman.com/pdf/array14_final.pdf
- eggy 11y ago
  I still use J because I think array, or matrix-based languages are a nice fit for the multi-core CPUs and GPUs available for such computations. Wes McKinney of Pandas was/is studying q and J for his current work. There's a reason these languages have been used actuaries and quants to analyze time series, and columnar data. And they're concise which some criticize for readability, but like Math symbols once you know them, they are very powerful. [1] http://conceptualorigami.blogspot.co.id/2010/12/vector-processing-languages-future-of.html?m=1 [2] https://scottlocklin.wordpress.com/category/tools/j/