Chris Donnan : Programming – Brooklyn Style
software, trading, family, fun
Posted C++, algorithmic trading, coding, functional programming on Sunday, July 12th, 2009.
I have been thinking quite a lot about a few programming topics:
- Correctness – how do we make it easy to write correct software
- Size – how do we curb growth in size of our software (characters – not just lines – it all counts!)
- Understandability – how do we keep our software simple looking
- Parallelism – how do we really scale out across CPUs, machines from a language perspective
- Performance – how do we keep all of these other things AND have performance
All in all – I am after a functional/ functional hybrid language in order to achieve improved correctness, reduce size, increase understandability and promote parallelism. I have been working on a ‘pet project’ – mini-exchange for matching orders – a limit order book system. This has got me thinking about extreme performance.
Recently a former colleague went to work for the LSE, while another went to go work for a low latency trading group @ one of the banks. In light of recent events (the LSE is going to abandon windows) and when considering the experiences of reality – I think windows is simply not the tool for exchanges/ low latency trading – at least not now. This is much debated and I do not want to debate it – just to state my opinion.
Windows is not the solution for high frequency trading ’nuff said
Now – I have classically spent most of my professional development career working on windows machines developing software to be used by traders. I have done Java programming, some C++ programming, ruby and a zillion other languages for play.
Here is a good pointer to s set of writing on windows vs *nix performance.
What functional languages offer what performance?
Functional languages will win in the end for all the goals I have - especially the languages that allow some OO-isms. I am really a fan of several functional languages. I have been doing small to mid size experimental projects with Clojure, OCaml, F#, Clean, Haskell and a few others. I have done some work on my mac, some on windows, some on Ubuntu. At the end of the day, this is all well and good – and with my 1st caveat (not just windows), the next question is what language on what *nix?
Here are a few links to the great language/ performance shootout
- Ubuntu 64 Bit Quad Core
- Gentoo P4
- Ubuntu 64 Bit Quad Core OCaml vs C++ Intel
- Ubuntu 64 Bit Quad Core OCaml vs Clean
You can see a few basic things here. Currently - C++ GNU g++ is the best perf across the board- not surprising at all.
Essentially we see that OCaml is fast – from 1-3x slower than C++ – max, similar for memory – certain tests OCaml wins, but mostly 1-3 multiplier for memory size. OCaml – unsurprisingly wins – code typically 1/2 the size of the C/C++ code. Clean is also fast in many cases. In certain cases it outperfs OCaml, but mostly OCaml wins.
In many – less trivial cases I bet that OCaml/ functional solutions will compare with C/C++ because it will be easier to make them small, understandable, less redundant etc. For ‘benchmarks’ where you can optimize the code in a small area – you can be as obtuse/ obscure as you need to in order to optimize for the benchmark. It becomes increasingly difficult to scale your software and maintain its performance if it is in some obscure form. Program size and understandability become very important – even to performance as the software scales up.
We need a higher performance functional language in order to use it to compete in the arms race vs uber low-latency trading systems. If we can write low latency trading systems that are competitive with C based systems on *nix machines. 3x slower worst case is still way to slow. It is not 30x slower like F#/ mono – but it is still too slow at that level of competition. Haskell is doing better these days – raking 6th after c/ c++ and java servers. OCaml and clean are a bit behind – but doing OK relative to the bunch.
Abstraction costs performance
Ultimately c/c++ abstract the computer for the most part – they abstract the computers memory and cpu resources. Functional languages are more abstract – they try to hide away the hardware-ness of the computer. This has a cost. The cost is still performance. The value for cost is size, understandability etc. Hopefully we can get the perf more in line and then we will be onto something…
OCaml Trading
Old news, but an excellent watch – Jane Street does trading using OCaml, here is a video…
http://video.google.com/videoplay?docid=-2336889538700185341ATS
Interestingly ATS is a programming language I never heard of. According to Wikipedia:
The performance of ATS has been demonstrated to be comparable to that of the C and C++ programming languages.
and
ATS is derived mostly from the ML and Objective Caml programming languages.
Now this is interesting…. According to the most relevant current shootout mentioned above, ATS is at worst 1.83x worse than C/C++. This is not a bad start. I bet that we could improve that number and we would have a functional – OCaml like programming language that is nearer to competitive with C/C++….
Responses are currently closed, but you can trackback from your own site.







