4 ms·

> any excess latency that Java introduces into your software is likely to be much smaller than existing latency sinks, such as network communication delays, in

> any excess latency that Java introduces into your software is likely to be much smaller than existing latency sinks, such as network communication delays, in (at least) In a co-located datacenter with high performance network equipment this isn't true at all. The time from my CPU to a kernel bypass NIC to a cut-through switch to the exchange's FPGA gateway is in the low single-digit microseconds.[1][2] [1]https://www.eurexchange.com/resource/blob/48918/ba7e2c5900f1069bc04f4785b15783eb/data/presentation_insights-into-trading-system-dynamics_en.pdf https://www.eurexchange.com/resource/blob/48918/ba7e2c5900f1... [2]https://www.arista.com/en/products/7150-series-network-switch-datasheet https://www.arista.com/en/products/7150-series-network-switc... [3]https://technologyevangelist.co/2015/11/04/1-44-microseconds-full-round-trip-latency-unlikely/ https://technologyevangelist.co/2015/11/04/1-44-microseconds...

bitcharmer 6y ago
> The time from my CPU to a kernel bypass NIC to a cut-through switch to the exchange's FPGA gateway is in the low single-digit microseconds Single digit microsecond latency is also what you should expect from a well written market data gateway or a fix engine. Java definitely competes with C++ in this space.
- dcolkitt 6y ago
  I'm not saying it's impossible for JVM to compete at the level. But you definitely don't get O(5 uSec) performance out of the box. The author is trying to argue that language considerations are irrelevant, because network latencies are orders of magnitude higher. That may be true for web networking, but it's definitely not true for HFT networks. If you hit a GC pause or have to do heap allocation or don't vectorize a calculation because you're not running native code, it all costs way more than the network stack. Again, I'm not saying that there aren't techniques to deal with that in Java. But what I am saying is that you can't just ignore those issues, like the author seems to suggest.
  - cashewchoo 6y ago
    FWIW, there's actually a large amount of industry experience in ultra-low-latency Java kicking around the ATS/exchange/HFT space. Island's ECN was Java, and that incubated a lot of this kind of talent. It's absolutely not your everyday java (I've heard the answer to "how do you handle gc's" is just "don't allocate memory") but it's a Thing.
    - gpderetta 6y ago
      The question is, one you are no longer writing anything close to idiomatic java, does the (sketchy) argument that Java is easier to write than C++ still holds?
      - bitcharmer 6y ago
        It still is as there's plenty of non-low-latency related stuff that you still need from the ecosystem such as portability, dependency management, common libraries and utilities, debuggers, profilers, etc.
        gpderetta 6y ago
        Thanks, this makes sense.
        phildawes 6y ago
        but if any of those common libraries allocate short lived objects, doesn't that ruin things?
    - bitcharmer 6y ago
      Yup, Java is common among low-latency-ish market makers like Goldman Sachs, UBS, HSBC, Morgan Stanley and others. Edit: since I'm being down-voted for this comment - I worked in all the above banks on low-latency Java projects. That you don't like the language/runtime doesn't change the facts.
  - bitcharmer 6y ago
kolbe 6y ago
Furthermore, if all your competitors have to incur the same fixed latency, then this is irrelevant. Just because one system is 200mics and another is 201mics doesn’t mean the 201mic one is good enough. HFTs are competing on what they can control, because if that trade comes with 199mics of network latency, it means the first firm will make a good trade every time, and the second will be shut out.
usefulcat 6y ago
This is true, but also misses a bigger point: in the particular case of low latency trading, once everyone has similarly fast network infrastructure, the only place left to improve is the time spent executing the algorithm on the CPU. Certainly not all strategies are so latency-sensitive, but for those that are, even a small speed difference there can have a significant economic impact.

bitcharmer 6y ago

> The time from my CPU to a kernel bypass NIC to a cut-through switch to the exchange's FPGA gateway is in the low single-digit microseconds Single digit microsecond latency is also what you should expect from a well written market data gateway or a fix engine. Java definitely competes with C++ in this space.

dcolkitt 6y ago
I'm not saying it's impossible for JVM to compete at the level. But you definitely don't get O(5 uSec) performance out of the box. The author is trying to argue that language considerations are irrelevant, because network latencies are orders of magnitude higher. That may be true for web networking, but it's definitely not true for HFT networks. If you hit a GC pause or have to do heap allocation or don't vectorize a calculation because you're not running native code, it all costs way more than the network stack. Again, I'm not saying that there aren't techniques to deal with that in Java. But what I am saying is that you can't just ignore those issues, like the author seems to suggest.
- cashewchoo 6y ago
  FWIW, there's actually a large amount of industry experience in ultra-low-latency Java kicking around the ATS/exchange/HFT space. Island's ECN was Java, and that incubated a lot of this kind of talent. It's absolutely not your everyday java (I've heard the answer to "how do you handle gc's" is just "don't allocate memory") but it's a Thing.
  - gpderetta 6y ago
    The question is, one you are no longer writing anything close to idiomatic java, does the (sketchy) argument that Java is easier to write than C++ still holds?
    - bitcharmer 6y ago
      It still is as there's plenty of non-low-latency related stuff that you still need from the ecosystem such as portability, dependency management, common libraries and utilities, debuggers, profilers, etc.
      - gpderetta 6y ago
        Thanks, this makes sense.
      - phildawes 6y ago
        but if any of those common libraries allocate short lived objects, doesn't that ruin things?
  - bitcharmer 6y ago
    Yup, Java is common among low-latency-ish market makers like Goldman Sachs, UBS, HSBC, Morgan Stanley and others. Edit: since I'm being down-voted for this comment - I worked in all the above banks on low-latency Java projects. That you don't like the language/runtime doesn't change the facts.
- bitcharmer 6y ago

kolbe 6y ago

Furthermore, if all your competitors have to incur the same fixed latency, then this is irrelevant. Just because one system is 200mics and another is 201mics doesn’t mean the 201mic one is good enough. HFTs are competing on what they can control, because if that trade comes with 199mics of network latency, it means the first firm will make a good trade every time, and the second will be shut out.

usefulcat 6y ago

This is true, but also misses a bigger point: in the particular case of low latency trading, once everyone has similarly fast network infrastructure, the only place left to improve is the time spent executing the algorithm on the CPU. Certainly not all strategies are so latency-sensitive, but for those that are, even a small speed difference there can have a significant economic impact.