4 ms·

As someone in the industry I always find the claim that Java is ubiquitous in low latency trading fairly strange. The only firm that widely uses Java over C or

As someone in the industry I always find the claim that Java is ubiquitous in low latency trading fairly strange. The only firm that widely uses Java over C or C++ on the hft fast path is Virtu, and the sense I get from some of my friends there is that they regret the decision (and now it’s mostly used to guide fpgas). There is a TON of Java usage in software that would have been considered HFT maybe 10 years ago, especially at big banks, but the fastest I’ve ever seen somebody make a Java trading program that actually handled the whole tick-to-trade path is 7us, which would be at best ok by C or C++ trading platform standards. I’m sure you could write some dumb trigger program operating on off-heap bytes that had similar performance characteristics to a C hft program, but unless you accomplish this via code generation then you’re just writing C in Java with a runtime actively battling your goals. Edit: Jane street uses ocaml + fpgas but they aren’t really in the HFT business in the same way that say Virtu or Tower is.

pjmlp 6y ago
People say this as if it was somehow depreciative, but I rather appreciate writing safe C in Java, which is something WG14 will never take the effort to improve.
- vgatherps 6y ago
  The C I saw written in Java was filled with object pooling bugs and horribly unsafe code dealing with object layouts in off-heap memory. The amount of bugs springing from just these far outnumbered memory bugs in the C++ and C codebases.
manuelabeledo 6y ago
I didn't say Java is used over C or C++. In fact, I stated that, given some requirements, you are better off with dedicated hardware. Granted, I have not worked in finance for over 10 years, but I also try to keep up with the times, thanks to some friends, mainly operating in the EU/UK market. But I would not say it is odd to think that Java is ubiquitous, given how technologies often permeate across teams. This is a bit like what happened to Python and FORTRAN, being the latter still widely used in the scientific world, especially physics, but Python adoption is definitely growing, despite its obvious shortcomings. Now, I understand that the hard requirements around HFT are wildly different, but from the perspective of an employer, having a larger pool of professionals and tools, would offer significant savings. Why wouldn't they take it?
- jakewins 6y ago
  > Why wouldn't they take it? Because the pool of Java devs is only marginally wider than the pool of C++ devs? 5.4M C++ devs vs 7.1M Java devs is not a massive difference in pools: https://www.daxx.com/blog/development-trends/number-software-developers-world https://www.daxx.com/blog/development-trends/number-software... And while I don't have numbers for it, my experience has been that the vast majority of Java devs have very little experience with the kind of specialized use of the JVM that low latency programming requires. On the contrary, I've found it difficult to hire for high-performance Java codebases, because the way they are written is completely different from how "normal" Java is written, so you need to retrain devs used to writing "normal" Java.
  - manuelabeledo 6y ago
    > 5.4M C++ devs vs 7.1M Java devs is not a massive difference in pools That depends on the geographic distribution, though. Also, we are talking of a 25% larger pool. > And while I don't have numbers for it, my experience has been that the vast majority of Java devs have very little experience with the kind of specialized use of the JVM that low latency programming requires. You could say the same about C++ developers. Most of the C/C++ jobs are in embedded devices, which differ vastly from HFT environments.
- vgatherps 6y ago
  I believe I misread your first sentence, I thought you said every prop shop IS using Java. I have seen this specific claim so many times that I must have filled in the word. The reason not to use java for low latency latency is that good low latency Java is pretty much only Java in a syntactic and to some degree object sense. Avoiding allocation permeates everything, and is just not worthy the battle. You basically try to write C++ in Java, except without the language features of C++ to help with memory management and layout, and wit the added burden of having to worry about pools and primitive boxing and the runtime at every corner. You would also be surprised though at how little hardware has replaced C++ on Linux with good user space networking. Not that many trades are pure latency arb, so getting that last microsecond or two just isn’t worth the effort. It’s much more common to see hardware in fixed-function locations than it is to see hardware running the meat of a strategy.

pjmlp 6y ago

People say this as if it was somehow depreciative, but I rather appreciate writing safe C in Java, which is something WG14 will never take the effort to improve.

vgatherps 6y ago
The C I saw written in Java was filled with object pooling bugs and horribly unsafe code dealing with object layouts in off-heap memory. The amount of bugs springing from just these far outnumbered memory bugs in the C++ and C codebases.

manuelabeledo 6y ago

I didn't say Java is used over C or C++. In fact, I stated that, given some requirements, you are better off with dedicated hardware. Granted, I have not worked in finance for over 10 years, but I also try to keep up with the times, thanks to some friends, mainly operating in the EU/UK market. But I would not say it is odd to think that Java is ubiquitous, given how technologies often permeate across teams. This is a bit like what happened to Python and FORTRAN, being the latter still widely used in the scientific world, especially physics, but Python adoption is definitely growing, despite its obvious shortcomings. Now, I understand that the hard requirements around HFT are wildly different, but from the perspective of an employer, having a larger pool of professionals and tools, would offer significant savings. Why wouldn't they take it?

jakewins 6y ago
> Why wouldn't they take it? Because the pool of Java devs is only marginally wider than the pool of C++ devs? 5.4M C++ devs vs 7.1M Java devs is not a massive difference in pools: https://www.daxx.com/blog/development-trends/number-software-developers-world https://www.daxx.com/blog/development-trends/number-software... And while I don't have numbers for it, my experience has been that the vast majority of Java devs have very little experience with the kind of specialized use of the JVM that low latency programming requires. On the contrary, I've found it difficult to hire for high-performance Java codebases, because the way they are written is completely different from how "normal" Java is written, so you need to retrain devs used to writing "normal" Java.
- manuelabeledo 6y ago
  > 5.4M C++ devs vs 7.1M Java devs is not a massive difference in pools That depends on the geographic distribution, though. Also, we are talking of a 25% larger pool. > And while I don't have numbers for it, my experience has been that the vast majority of Java devs have very little experience with the kind of specialized use of the JVM that low latency programming requires. You could say the same about C++ developers. Most of the C/C++ jobs are in embedded devices, which differ vastly from HFT environments.
vgatherps 6y ago
I believe I misread your first sentence, I thought you said every prop shop IS using Java. I have seen this specific claim so many times that I must have filled in the word. The reason not to use java for low latency latency is that good low latency Java is pretty much only Java in a syntactic and to some degree object sense. Avoiding allocation permeates everything, and is just not worthy the battle. You basically try to write C++ in Java, except without the language features of C++ to help with memory management and layout, and wit the added burden of having to worry about pools and primitive boxing and the runtime at every corner. You would also be surprised though at how little hardware has replaced C++ on Linux with good user space networking. Not that many trades are pure latency arb, so getting that last microsecond or two just isn’t worth the effort. It’s much more common to see hardware in fixed-function locations than it is to see hardware running the meat of a strategy.