The GPU in Risk Management - Monte Carlo on Steroids
A Graphical Processing Unit – in short GPU – has a lot of processor cores and a lot more processing power than a typical CPU. Using it in risk management can bring great rewards – but is it feasible?
A GPU: a lot more processing power than the central processor
The Graphics Processing Unit – the core of modern graphics cards – has a lot more processing power than the CPU. It is not as well suited for generic operations, and its cores are significantly slower than the core of the central processor. Easily by a factor of 10. But it has a highly optimized mathematical unit and a lot of cores. 3000 cores are not unheard of in high end graphics cards, and – with special motherboards – one can run 4 of them without problems. Power consumption will be high – in excess of 1 KW load. But the processing power will be tremendous.
A GPU: very programmable and used in scientific simulations
The time of the fixed function pipeline for graphics processors is long over. Today they execute programs in their own assembler language and the parallel processing power is harnessed in languages like OpenCL, the AMD based “Open Computing Language”. NVidia is selling specially optimized cards with the GPU for simulations – CUDA is the keyword. And quite a lot of simulations do make good use of the GPU core. Not only in science - physics engines (a core part of modern games simulating things like explosions, water surfaces, the movement of clothes on characters) start moving more and more functionality to the graphics card.
At the end, a GPU today is a massively parallel processor. And it is very programmable. We have argues in this blog post about using a GPU for back testing that this is not a very efficient way. But any reader of this post will understand that the argument made is not about the GPU as slow, but about the fact that the GPU makes not a good platform for the trading (not the optimization) and maintaining a strategy twice has serious negative side effects. As strategies get redone during development – in fact we have 2 people with the only job of creating new strategies – this makes dual development and debugging quite expensive.
Risk Management – some approaches require a lot of processing
Risk management, though, is not backtesting. Risk management is fundamentally different. On one side, some risk management simulations do require significant amount of processing power. A Monte Carlo Simulation is recombining trades in possibly hundreds of thousands of combinations to see how stable, statistically, a backtest result is. On the other hand, though, there is no permanent development and no dual platforms. While someone may develop new risk management capabilities and approaches, an approach itself will not be under constant development (but instead be used over and over again). And it will not be used in real time trading on a separate code path. So, if a Monte Carlo Simulation core is developed for the graphics card – it will not have to be redeveloped (possibly with new bugs) to run on the CPU for real time trading.
The particular example of a Monte Carlo Simulations is quite interesting. It works on a non-trivial amount of static data that is recombined in many ways. Which means that it has no data up or download during runtime (compared to a trading strategy that has to get new ticks all the time) – and loading and unloading data from the graphics card is a bottleneck. It also does recombination of the same data set, so every recombination stream – based on a pseudo random number – can be done in parallel without interfering with other recombination streams.
Using the GPU for risk management can make a big difference
This fundamental difference makes the GPU quite suitable for risk management. The extreme parallel processing power of a mid-level processor combined with a number of high end graphics cards can outshine half a rack full of servers easily. The main problem here will be to come up with algorithms that can utilize this amount of processing power.
Obviously utilizing graphics cards in a server can be tricky – a custom build server based on a gaming optimized motherboard is pretty much the only solution, outside the use of Nvidia CUDA cards (which are effectively graphics cards without the output capabilities) – which can be very expensive. Finding hosting for such a custom build server will also not be trivial – the power densities (in watt/rack unit) are higher than what most data centers are comfortable with, at least in their normal bulk offerings.
Notable examples that I am aware of how a graphics card is utilized in trading include:
- Calculating the fair value of US Stock options every second – for the whole stock market
- Creating a graph of a stock with every possible support and resistance line shown
- Monte Carlo Simulations in near real time for a significant number of instruments
All these elements would be a lot harder to do without a GPU – and they all have in common that they are not trading algorithms, but relatively static parts.
And we - we ignore the GPU for the moment
A simple fact that development time is limited and we just do not have the bandwidth (in development hours available per day) to implement this. GPU integration into the Reflexo Trading Framework is planned for some point 2015, once our new trading server is finished and we had a chance to stabilize the complete stack.... and add some more features to our grid computing framework. Knowing myself - and that we need content for this blog and the website -I am quite sure a number of posts will be written when we start putting our risk management on a GPU basis.