
F# and GPUs for Life Insurance Modeling - jmartinpetersen
https://devblogs.nvidia.com/parallelforall/gpus-dsls-life-insurance-modeling
======
castratikron
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.

~~~
pflats
>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
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
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/

------
wjnc
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].

[1]
[https://www.edlund.dk/sites/default/files/Downloads/annual-r...](https://www.edlund.dk/sites/default/files/Downloads/annual-
report_2014.pdf)

~~~
BillinghamJ
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.

~~~
wjnc
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 ;)

~~~
BillinghamJ
Hourly/on-demand motor :)

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.

------
tschiller
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.

