4 ms·
>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
by 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 agoThat 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 agoI 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/