5 ms·

Here are my impressions from having worked as a programer on an HFT system during 2009-2011. When an HFT system makes money, some other person or system is loo

Here are my impressions from having worked as a programer on an HFT system during 2009-2011. When an HFT system makes money, some other person or system is loosing money i.e. it is a zero-sum game. And that person isn't going to sit idle; they are going to analyze their mistake and up their game. The industry parlance for this is, I think, that the "strategy dissipates into the market". This causes HFT systems to be always in active development. Spotting a strategy and putting together a system to take advantage of it, and spotting where your system is losing money and fixing it - both these need to be done with quick turn around time. Most strategies can be thought of as picking up nickels from in front of a on-coming train. Your best case "win" is a tiny amount of money; but your worst case "loss" is much much more money. The trick in HFT - the HF part - is to make these tiny wins over and over. But much actual money is involved, with very bad consequences should the program run into inopportune bugs. All of these - constant development, time to market pressure, high reliability - give the impression that Java is a better language to code this HFT systems in than C or Fortran.

TickleSteve 10y ago
You seem to be saying that C & Fortran aren't a) Fast b) suitable for developing strategies. ...Now I've never used Fortran myself.... but none of those arguments seem to stack up.
- peterashford 10y ago
  I think he's saying that reasonably fast code can be written reasonably fast in java. Writing fast C code is perhaps a more specialised task?
  - vanderZwan 10y ago
    But I thought HFT required unreasonably fast code?
    - taneq 10y ago
      But it requires it in an unreasonably short amount of time. Hence the tradeoff.
    - lucozade 10y ago
      As with most big systems there are degrees. Most of the code isn't in the fast paths so can be written in whatever language makes sense for the developers. For all the love it receives on HN, Java has plenty of practical success as a development language. The majority of the fast paths have performance characteristics that Java is suitable for as long as it's actually executing your program. hence the focus on GC, networking and concurrency primitives. And mostly Java is chosen where the bulk of the rest of the codebase is Java. Where you need ridiculously fast, then you have to drop down to what suits. Be that C, ASM or FPGAs. But these have costs wrt dev time and/or ease of establishing correctness. So they tend to be used judiciously.

TickleSteve 10y ago

You seem to be saying that C & Fortran aren't a) Fast b) suitable for developing strategies. ...Now I've never used Fortran myself.... but none of those arguments seem to stack up.

peterashford 10y ago
I think he's saying that reasonably fast code can be written reasonably fast in java. Writing fast C code is perhaps a more specialised task?
- vanderZwan 10y ago
  But I thought HFT required unreasonably fast code?
  - taneq 10y ago
    But it requires it in an unreasonably short amount of time. Hence the tradeoff.
  - lucozade 10y ago
    As with most big systems there are degrees. Most of the code isn't in the fast paths so can be written in whatever language makes sense for the developers. For all the love it receives on HN, Java has plenty of practical success as a development language. The majority of the fast paths have performance characteristics that Java is suitable for as long as it's actually executing your program. hence the focus on GC, networking and concurrency primitives. And mostly Java is chosen where the bulk of the rest of the codebase is Java. Where you need ridiculously fast, then you have to drop down to what suits. Be that C, ASM or FPGAs. But these have costs wrt dev time and/or ease of establishing correctness. So they tend to be used judiciously.