Chris Donnan : Programming – Brooklyn Style
software, trading, family, fun
Posted .net, c#, erlang, functional programming, haskell on Tuesday, July 28th, 2009.
So – I am deep into Erlang (still learning for > 1.5 years), Getting into Clojure (new) and getting into Haskell (a few months now). I have decided to spurn the OCaml/ F# branch of the world at least for a little while…
Anyhow – Erlang is the functional language I have the most experience with, yet next to Haskell – the LANGUAGE feels weak. Erlang the language + OTP + the Erlang VM runtime is amazing but the Language itself is not as lovely as Haskell. When I am typing C# code, I am finding myself more and more functionally minded. For a few years now I have felt the move to functional programming on me. C# has had great improvements – but it still feels way too brittle and verbose next to Haskell.
I recently read these articles:
Haskell for C# Programmers Part 2: Understanding IO.
Haskell for C# Programmers Part 3: Visualizing Monads
I found them helpful understanding monads as someone with a large C# experience. I also found this one:
Monads as containers very helpful. I will admit to having read dozens of articles on monads and just now really getting to a point where I think I can actually perceive the need for writing one of my own.
Functional programming style has made great differences in my personal style in several languages. I like programming languages and I am literate in many. Seek the monad, but 1st seek to understand the primitive bits of functional programming and it will aide your programming in any language.
Responses are currently closed, but you can trackback from your own site.
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.
Posted .net, F#, functional programming, programming on Monday, July 6th, 2009.
LAgent : an agent framework in F# – Part I – Workers and ParallelWorkers
LAgent : an agent framework in F# – Part II – Agents and control messages
LAgent: an agent framework in F# – Part III – Default error management
LAgent: an agent framework in F# – Part IV – Custom error management
LAgent: an agent framework in F# – Part V – Timeout management
LAgent: an agent framework in F# – Part VI – Hot swapping of code (and something silly)
Responses are currently closed, but you can trackback from your own site.
Posted programming on Sunday, July 5th, 2009.
Been reading lots…
Finance, microstructure:
- A Dynamic Model of the Limit Order Book
- liquidity supply in a pure limit order book market
- Optimal liquidation against a Markovian limit order book
- Fluctuations and response in financial markets
Languages:
- Expert F# Hardback (Expert’s Voice in .Net)
- Programming Clojure (Pragmatic Programmers)
- Why Functional Programming Matters
Distributed computation:
Just good readin’
Responses are currently closed, but you can trackback from your own site.
