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.
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).
>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.
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.
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.
Aon Benfield Securities has a Python + GPU approach to actuarial modeling. If you want to compare the approaches they take, there's a video and talk up on the DSLs for Finance homepage: dslfin.org
For those generally interested in financial domain-specific languages, the website also has a comprehensive listing of financials DSLs.
It seems like a nice and modern stack to work with. Anything on adoption in the industry?
It's a niche market with firms very-very reluctant to switch software and very-very long development cycles. Some googling led me to Edlund, which from their '14 annual report seems a mainly Danish firm [1].
I'm busy building a new insurance company called Cuvva.
Initially, we had planned to work with the existing software platforms, as we had assumed it would be too difficult to build the stack ourselves.
But their terms were completely financially untenable for our model. Additionally, they have never supported a truly mobile insurance platform before, so we were concerned that it wouldn't deliver the experience we wanted.
So we ended up building everything from scratch. It took less time than we were quoted by the various software houses, at about a fifth of the cost. We couldn't be happier with how it has turned out.
Life or SLT business? Then I'm truly impressed. Any links?
P&C on the backend is imho a few orders of magnitude simpler (although I enjoy the statistics there more). 30 to 50 year complex contracts and then try to manage your market risks.
Edit: sorry, you mentioned the name. Nice idea! I guess you are so far away from traditional products you actually stand a chance. (For readers from other sectors: Market is cut throat and multiline insurera have lower capital requirements so new monoline in Europe is practically impossible.) You'll have contracts running for hours, not decades ;)
At least in Western Europe, the big insurance companies are using mostly (Willis) Towers Watson's Moses (or are changing to Risk Agility FM) or Sungard's Prophet. License fees are very high and everyone is basically locked in, because the models get developed over many years.
From my experience, the models aren't efficient. On one hand, the developers are very often actuaries without much understanding of efficient programming. On the other hand, the underlying software is old and doesn't take modern possibilities into account.
So, instead of taking a big risk and developing a new software themselves, almost everybody is buying more physical machines for their hpc clusters.
About splitting: It is at least in Moses/Rafm a big problem to have many people working on the same model. It seems like TW has never heard something about version control systems, and their newest team edition is a big joke...
15 comments
[ 2.8 ms ] story [ 47.0 ms ] threadIn 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.
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).
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)
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
For those generally interested in financial domain-specific languages, the website also has a comprehensive listing of financials DSLs.
It's a niche market with firms very-very reluctant to switch software and very-very long development cycles. Some googling led me to Edlund, which from their '14 annual report seems a mainly Danish firm [1].
[1] https://www.edlund.dk/sites/default/files/Downloads/annual-r...
Initially, we had planned to work with the existing software platforms, as we had assumed it would be too difficult to build the stack ourselves.
But their terms were completely financially untenable for our model. Additionally, they have never supported a truly mobile insurance platform before, so we were concerned that it wouldn't deliver the experience we wanted.
So we ended up building everything from scratch. It took less time than we were quoted by the various software houses, at about a fifth of the cost. We couldn't be happier with how it has turned out.
P&C on the backend is imho a few orders of magnitude simpler (although I enjoy the statistics there more). 30 to 50 year complex contracts and then try to manage your market risks.
Edit: sorry, you mentioned the name. Nice idea! I guess you are so far away from traditional products you actually stand a chance. (For readers from other sectors: Market is cut throat and multiline insurera have lower capital requirements so new monoline in Europe is practically impossible.) You'll have contracts running for hours, not decades ;)
Helps enable people in the UK to borrow their friends' cars (which is often illegal here).
There are a few more complexities in motor insurance which don't exist in other verticals also.
Edlund primarily has customers in the danish labour market pension sector, and was recently acquired by KMD (a largeish danish it company).
From my experience, the models aren't efficient. On one hand, the developers are very often actuaries without much understanding of efficient programming. On the other hand, the underlying software is old and doesn't take modern possibilities into account.
So, instead of taking a big risk and developing a new software themselves, almost everybody is buying more physical machines for their hpc clusters.
But you know whats harder? Splitsing development between actuaries and programmers
About splitting: It is at least in Moses/Rafm a big problem to have many people working on the same model. It seems like TW has never heard something about version control systems, and their newest team edition is a big joke...