4 ms·

Java is already at a significant disadvantage compared to native code for this vectorized string-parsing contest.

pjmlp 3y ago
Why should it be, it provides the tools, as proven by the results. The matter is one of these tools is being taken away.
- anonymoushn 3y ago
  The results are significantly behind other languages, in part because of instruction sequences that Java users cannot use. I agree that it's unfortunate to add an additional disadvantage, and this one seems particularly brutal, because people who write automated trading systems commonly use Unsafe to emulate arrays of structs, and MemorySegment is not a good substitute.
  - MrBuddyCasino 3y ago
    Given that automated trading systems are in fierce competition between each other, and thus have a never-ending thirst for tiny performance advantages, maybe the JVM with its emphasis on abstract high-level language constructs and runtime safety isn't the best platform and shouldn't bend itself into unnatural contortions to satisfy this niche? We've got Rust now, offering both low-level control and safety. No need to take the SUV on the racing track, it is not at home there.
    - jmaker 3y ago
      I’m unaware of HFT systems running entirely on a JVM. Do you know of such cases? Safe Rust isn’t fast enough for HFT in my opinion. What kind of HFT? Amusingly, though somewhat tangential, I observed a rather simple Go implementation (nothing fancy, ordinary channel bound message passing) outperform a fairly sophisticated Rust implementation for the same logic when we were toying with a prototype. But that was at an IO boundary. There are many other variables of course, but an amusing anecdote to share.
      - MrBuddyCasino 3y ago
        I will not pretend to have any inside information, I just picked up some of the related discussions on HN over the years. I'll easily believe that it can take significant work to outperform Golang (or Java) in Rust where application complexity is high (not just a simple cmd app), they do have an excellent baseline out of the box.
        jmaker 3y ago
        Definitely, microbenchmarks are what’s most striking especially because they seem immediately approachable, as opposed to a full fledged app with a variety of integrations. In that case the quality of the dependencies is much more important to me than any benchmark runs. Great point, totally agreed. I personally am often quite astonished by the amazing performance Go apps squeeze out of the box, with many efficiency tweaks and tricks we way too often take for granted, which you need to be aware of to come by in C++, Rust, or even Java. But I do also often get disappointed by the sudden inconsistency of that performance in Go after a while, the variance is a bit high, with C++, Rust, and Java runtime behavior being very consistent in general.
      - pjmlp 3y ago
        "Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94 https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-... LMAX Disruptor customers https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ Among many other examples.
        jmaker 3y ago
        Much appreciated indeed. Though I’m unconvinced by that particular piece on Medium. There’s no mention of their purported trading workloads, reads rather like a pile of SEO keywords spiced up by a couple charts and appears more like an attempted product placement for Azul Zing instead of HotSpot Zulu or other distributions. The author doesn’t seem to associate with finance either. I know Disruptor fairly well, it’s been underwhelming.

Why should it be, it provides the tools, as proven by the results. The matter is one of these tools is being taken away.

anonymoushn 3y ago
The results are significantly behind other languages, in part because of instruction sequences that Java users cannot use. I agree that it's unfortunate to add an additional disadvantage, and this one seems particularly brutal, because people who write automated trading systems commonly use Unsafe to emulate arrays of structs, and MemorySegment is not a good substitute.
- MrBuddyCasino 3y ago
  Given that automated trading systems are in fierce competition between each other, and thus have a never-ending thirst for tiny performance advantages, maybe the JVM with its emphasis on abstract high-level language constructs and runtime safety isn't the best platform and shouldn't bend itself into unnatural contortions to satisfy this niche? We've got Rust now, offering both low-level control and safety. No need to take the SUV on the racing track, it is not at home there.
  - jmaker 3y ago
    I’m unaware of HFT systems running entirely on a JVM. Do you know of such cases? Safe Rust isn’t fast enough for HFT in my opinion. What kind of HFT? Amusingly, though somewhat tangential, I observed a rather simple Go implementation (nothing fancy, ordinary channel bound message passing) outperform a fairly sophisticated Rust implementation for the same logic when we were toying with a prototype. But that was at an IO boundary. There are many other variables of course, but an amusing anecdote to share.
    - MrBuddyCasino 3y ago
      I will not pretend to have any inside information, I just picked up some of the related discussions on HN over the years. I'll easily believe that it can take significant work to outperform Golang (or Java) in Rust where application complexity is high (not just a simple cmd app), they do have an excellent baseline out of the box.
      - jmaker 3y ago
        Definitely, microbenchmarks are what’s most striking especially because they seem immediately approachable, as opposed to a full fledged app with a variety of integrations. In that case the quality of the dependencies is much more important to me than any benchmark runs. Great point, totally agreed. I personally am often quite astonished by the amazing performance Go apps squeeze out of the box, with many efficiency tweaks and tricks we way too often take for granted, which you need to be aware of to come by in C++, Rust, or even Java. But I do also often get disappointed by the sudden inconsistency of that performance in Go after a while, the variance is a bit high, with C++, Rust, and Java runtime behavior being very consistent in general.
    - pjmlp 3y ago
      "Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94 https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-... LMAX Disruptor customers https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ Among many other examples.
      - jmaker 3y ago
        Much appreciated indeed. Though I’m unconvinced by that particular piece on Medium. There’s no mention of their purported trading workloads, reads rather like a pile of SEO keywords spiced up by a couple charts and appears more like an attempted product placement for Azul Zing instead of HotSpot Zulu or other distributions. The author doesn’t seem to associate with finance either. I know Disruptor fairly well, it’s been underwhelming.