Now I don’t mean to go picking on Dr. Johnson because he posted some Black Scholes code on the internet. The same could be said about Numerical Recipes code, any other collection of elementary numerical codes, even code from E.L. Wisty. It’s all perfectly fine code. But benchmarking this code, offered to the public, does highlight some of the difficulties of getting and maintaining competitive performing code, code that runs fast.
First, you have to get the right algorithms and numerical approximations or you will remain hopelessly behind. Next, you probably need to have a competitive commodity machine on which to run your code or again you will remain firmly behind, performance wise. This second point is interesting because the competitive off-the-shelf machine can and does change from year to year, unlike the algorithms which tend to be more stable. If you want your code to remain competitive and track Moore’s Law you pretty much have to rewrite it every 18 to 24 months, even if it’s just going to run on a MacPro. If you get your code architecture basically compatible with the underlying microprocessor the rewriting effort is limited and incremental, still nasty business that, right? Third, your competitive code has to deal with instruction level parallelism and the memory cache hierarchy in a profound way and at an architectural level. So even if you get the first two steps perfectly correct, missing the third step can give it all away. Finally, perhaps the most challenging part in many organizations, this whole three step process, FinQuant-Engineering-Programming, it’s very iterative, sorry. There is no one simple path to competitive performance, it simply requires competence and flexibility in negotiating the various tradeoffs made along the way. The choices you make in selecting the computer and how you structure your code memory cache references feeds back constraints on the algorithms and numerical approximations best suited for the application. The quants kind of need to know and react to many of the details of the implementation, if the code performance is going to remain competitive. This is a subtle point that folks occasionally miss when designing competitive codes; I have seen it happen more often than you would think. The quant research folks, the grid/infrastructure engineering folks, and the trader/programmer all have to be on the same page and invested in the entire process or, when the inevitable production process glitch arises, there is a problem.
So who puts up with all of these requirements? It seems like an awful lot of work. Well, not many folks deal with competitive performance or even know about floating point in a bunch of different places. For the most part folks don’t need competitive floating point code; they just need something that runs in production and lets them think about other important things. Compiled -O2, Dr. Johnson’s code works for them and their Firm just fine, this competitive floating point performance thing is not what gets them paid. You might need to know about competitive code if your Firm has lots of securities that need to be evaluated in lots of potential future scenarios and you need an answer today. You might need to know about competitive code if you have code that takes live market feeds, runs for 200 milliseconds, and then tries to buy or sell something when other competitors have code that takes similar or possibly less time. There are not many folks in either of these positions – but if you run into to one of them – tell them how this stuff works because it will be useful to them.