Designing fast system seems initially an easy task. You hire developers that are in touch with the physical nature of computers and networks. And you ask them to write fast code.
Nevertheless, there are difficulties. The first is that allocating and freeing dynamic memory slows you down, so ideally you want to do without dynamic memory. Yet developers usually have a hard time with this requirement. One reason that developers are insecure in doing this is that they have been brought up with languages that only work with dynamic memory. The other reason is exactly the language issue: modern languages do not make it easy to program without dynamic memory allocation. Therefore it is best to present this requirement differently, in a form that is much easier to swallow, which could be as follows:
Make sure to preallocate your dynamic memory before activating your algos, and minimize any later reallocation.Now this first request seems a bit heavy because it tends to use a lot of memory and brings the code back thirty years. Yet, as you expect your very fast system to make lots of money, you need to start by assuming you have no limits to you infrastructure costs, and are willing to pay for terabytes of memory if needed. In addition, languages like C++, with a wise use of templates, or functional languages with mutability (like Ocaml or F#), can actually do a good job with this requirement. More importantly, this requirement leads me to the next requirement, but first I need to repeat my “motto” in trading, which is:
"It is easier to make money than to keep it".Which leads me to remind you that there are two very distinct activities in trading: making a profit and trying to prevent a loss. This may sound pretty trivial, but it is a key concept, and not all developers understand it. (I have reviewed enough trading code to know that). What it means to an algo system is that as much effort and thinking must be put in the code that actively tries to make money as in the code that actively tries to prevent losing money. As a requirement, I would state it as:
Given that trading algos can be in three different states: profit making, idle, and preventing loss; Put as much effort and optimization in the transitions from each of these states to another as you put in staying within each state.Said emotionally:
I want no delay when I slam my foot on the brake or on the gas pedal!If you have written a few complex real time systems, you may realize that this is not a trivial requirement. And in fact, it is even harder to implement than the first requirement. But I can tell you that it is easier to achieve if you also worry about the first "no dynamic allocation" requirement.
All original content copyright James Litsios, 2013.