# OpenGamma's Strata - Computational Overhead

I've been looking at the open-source library Strata (maintained by OpenGamma), which is written in Java.

Now, upon inspection of the FX Forward Pricer and Payment Pricer I noticed two things:

1. All its low-level calculations & results (present value, PV01, etc.) are done using classes like CurrencyAmount or MultiCurrencyAmount. What is the computational cost of this in comparison to using double numbers first and enhancing the results with Currency Meta Data after the calculations are completed? E.g. every time a new CurrencyAmount is created one passes the internal Currency property, which itself contains a 3-letter symbol represented as string. So it seems strings are repeatedly copied.
2. The present value function call receives the trade itself and a market data provider. The trade's currency is then used to obtain the appropriate discount factor curve from the market data provider, from which the final discount factor is then queried. Again, I am wondering what the cost of this constant "curve look-up" is on a larger scale. Why not embed a direct reference in the trade (or pricer, depending on the implementation) to the appropriate discount curve? So repeated function calls (be it present value or pv01) don't have to constantly look up the curve in the market data map. Maybe similarly to having a shared_ptr to the curve in C++.

QuantLib in comparison embeds the necessary market-data object pointers in the pricing engines when the engine is setup, and it only operates on double numbers, which appears more efficient on first glance. Obviously, one cannot easily parallelise the QuantLib approach, whereas this is possible using Strata.

## 1 Answer

On point 1, Strata takes the view that it is important to have the currency associated with the value. After all, the value is meaningless without the currency. There is a cost to creating a CurrencyAmount (although if it is used and discarded quickly, this has minimal cost in the garbage collector (the "young generation") and potentially HotSpot may kick in and remove the object creation cost entirely.

Although Currency contains a String, the string is not copied each time. Java strings are immutable (they cannot be changed), and Currency is also immutable. As such, when the CurrencyAmount is created, a pointer to the existing Currency is included, and that contains a pointer to the existing String, thus no string or Currency is created.

On point 2, Strata follows a functional design, where the pricers are functions that are passed data. This immutable and functional nature is a key part of the design of Strata, particularly as it allows easy parallelism.

In this case, the pricer is passed the trade and the market data. The pricer examines the trade to see what market data is needed. This provides flexibility to allow the pricer to obtain whatever market data it needs without having to change the API of the function. Were the market data to be embedded in the object, it would require a new object to be created for every calculation, which would be undesirable, particularly when calculating scenarios (repeated calculation on slightly varying market data).

If the performance of the market data lookup proved to be a problem, a special implementation of RatesProvider (an interface) could be written that only contains market data for one currency pair. The implementation would return the curves without lookup in a hashmap. The caller would then be responsible for passing the correct implementation to the pricer. This would be the most similar approach to that used in QuantLib.

Disclaimer: I'm one of the primary authors of Strata.

• Functional design - fantastic. To what extent do you think that parts of Strata could be offloaded to GPU? I mean starting with 64-core CPU parts I'm sure a properly executed functional design will allow strata performance to leave Quantlib in the dust, thereby allowing much bigger search spaces. But perhaps this can go even further with GPU? I'd like to know your view on whether or not this is something that is worth playing with because I'd be happy to explore the idea. – Thomas Browne May 11 '19 at 8:56
• I'm not an expert in performance via GPU. My understanding is that the main issue is getting the data in the right format for bulk processing, and that can have an overhead. To discuss more, I suggest talking on the Strata forum forums.opengamma.com/c/strata – JodaStephen May 13 '19 at 18:50