The code is written in a series of c++ classes carefully constructed to allow optimized code generation on quad-word aligned vectors. It is not obvious technically why you have to write this code in c++. There are c++ compilers that can generate competitive executable code, for example icc or xlc. There are also competitive performing vector intrinsics libraries available to your c++ code. I am not aware of good vector intrinsic libraries for gcc.
There are managers on the Street who will shut the conversation down if they think they could be working with an obsolete system. On the other hand, when you talk to the Cray guys they sort of give you side eye when you ask lots of questions about getting the c compiler to generate optimal code. There is not a general understanding on the Street of how to appraise the value of the code issued by the compiler (or even if it is worthwhile to have a compiler generate code). And that is not easily taught, in my experience, at either the developer of the manager level. Wallach once told me the story of supercomputer customers trying to get vendor support to get their shell scripts running so they could launch their APL code on the supercomputer. They got it running and the customer was thrilled to be running on a supercomputer, so they bought it. Lesson learned, we will put an Erlang front-end on the Reference Server if it helps, we ain’t fancy.
The class Nimo contains all the system’s parameters and it will contain the server Request /Response queue, parameters and status. Specifically, the Nim0 class determines the maximum number of securities for the class AccrualSecurityMaster and the maximum number of accounts for the class Balance Sheet. The maximum number of simulation horizon months is always 64 to make sure all our vector references stay quad word aligned. The reason you want to make sure this happens is that eventually you want to generate AVX2.0 SIMD vector code from the compiler. Compilers are generally cranky about generating fast and efficient code unless the vectors are all quad word aligned. Both AccrualSecurityMaster and BalanceSheet allocate and free memory off the heap as directed by Nimo parameters. The request and response mechanism we expect to implement in the Nimo class will take one request, allocate memory, run the simulation, return a response, update stuff tables, and free the previously allocated memory.
The class AccrualSecurityMaster contains all the balance and rate models. Currently there are only three product models deposit_model_1() , cards_model_1(), and fed_funds_model_1(). Each of these models computes a regression forecast for balance and rates. This class will have product model testing code as well as summary display functions to facilitate the review of all the product models. I suspect most of the work in the static simulation of the balance sheet will be in maintaining the correctness of the models. We will have a request to dump the state of all the product models to the user. There are no plans currently to take input from the user directly into Accrual Security Master. We do not envision dynamically loading user product model code into the Reference Server. If the user needs their own product model they should pull down the Reference Server code locally and compile in their product models into the simulator. If the user wants to submit product models to the Reference Server we will work with them to get them tested and compiled in subsequent production release.
The classes CurrentMarket, BalanceSheet, and AccrualPortfolio take the user’s input to set up the static simulation. Broadly, CurrentMarket has all the inputs to the product models; BalanceSheet has all the accounts and any exogenous initial conditions or amendments required for the balance sheet simulation; AccrualPortfolio has all the security positions tagged by balance sheet account. The AccrualPortfolio maintains a mapping to both the product models in AccrualSecurityMaster and the accounts in BalanceSheet. The outputs from the simulation returned to the user are typically either the full balance sheet from the class BalanceSheet or the complete simulated product list from the class AccrualSecurityMaster.
The class CurrentMarket is a work in progress but should contain all the market and econometric variables needed to forecast the balance and rates forward to each period in the simulation horizon. if the quantity doesn’t directly drive the product model or depend on one of the factors driving the stochastic program it probably should not be stored in CurrentMarket. I have seen regressions require historical quotes, presumably to model seasonality of some other periodicity; so we will accept user input historical and projected values to be used in the model valuations. the CurrentMarket variables are tagged to match variables in the models hosted in AccrualSecurityModel.
The class BalanceSheet contains the dynamically allocated balance and rate arrays that make up the balance sheet. The full balance sheet simulator code also is called from the BalanceSheet class.
The class AccrualPortfolio contains the dynamically allocated security position structures, the security simulator code, and the product models.
The classes NimoModelMaster and CapitalPlan are for the Stochastic Programming and NLP optimization code. NimoModel Master will contain he details of various stochastic market models available for simulation. CapitalPlan will contain the targeted new investment strategy to be optimized with the NLP simulation. Both classes take user inputs to set up simulations, but are not used in static balance sheet simulations.