7 ms·

This is clearly still great for a few places. For example in the trading industry, you would have a few seconds of being very slow when starting up for the week

This is clearly still great for a few places. For example in the trading industry, you would have a few seconds of being very slow when starting up for the week - or anytime you crashed and needed to reboot midweek. Also risk of "hot pathing" the wrong paths if the server comes up during say a market closed time...

OldSchoolJohnny 10y ago
I'm surprised to hear anyone running Java in the trading industry. Isn't speed a huge factor in that industry?
- lygaret 10y ago
  The JVM is super speedy, if you can mitigate startup time and the time required to warm up the JIT.
  - lomnakkus 10y ago
    ... and Distruptor/Aeron. (etc.)
- maaaats 10y ago
  Thus the Java.
- eternalban 10y ago
  > Isn't speed a huge factor in that industry? Exactly. There are a lot of high performance system written in Java. For long running systems, the startup cost is irrelevant. And for networked systems (such as fintech) you are going to be IO bound. The main issue as far as Java and high performance is the GC related pauses and that is a concern shared with any GC'd runtime.
  - PeCaN 10y ago
    And for Java it's actually much less of an issue thanks to the crazy manhours put into developing fast GC for Java. I suspect Azul Systems's pauseless GC is probably quite popular in HFT.
    - brianwawok 10y ago
      They are trying to sell it for sure. They attend a lot of events. I am not aware of any trading company using it. May be some.. but the high perf people I know go other ways.
- chrisseaton 10y ago
  For example: https://github.com/OpenHFT https://github.com/OpenHFT
- taneq 10y ago
  I seem to recall a prior discussion where a dev working on HFT stuff said that speed is a huge factor, but so is the ability to rapidly change functionality. They settled on Java because it was fast enough (HFT would have to be IO bound, right?) while still being flexible enough to allow them to adapt to daily changes in requirements.
- pjmlp 10y ago
  Besides what the others already replied, the use in the trade industry is one of the reasons of Java having to adopt AOT, value types, JNI replacement and better integration with GPGPUs.
- kitd 10y ago
  You're assuming Java is slow. Evidence suggests otherwise. Eg. LMAX Exchange uses a lock-free ringbuffer they call Disruptor [1] which enables 6M tps on a single thread [2] [1] https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ [2] http://martinfowler.com/articles/lmax.html http://martinfowler.com/articles/lmax.html
  - brianwawok 10y ago
    And disruptor is a few years old now, there is a whole new wave of queues with even better performance.
- nurettin 10y ago
  Java shot itself in the foot with the whole GC thing. Then it built a gigantic robot exoskeleton called Hotspot to help itself walk fast again.
  - lucian1900 10y ago
    Java's GC isn't why it can be slower than C/C++ and the JIT (HotSpot) has nothing to do with the GC.
    - nurettin 10y ago
      Well you just told that to someone who lived with GC pauses and profilers for years. And I did not say hotspot is about GC.
deleted 10y ago
[deleted]
WatchDog 10y ago
A lot of firms will run some training data through their application after startup, so that the hot paths get optimised.
- kasey_junk 10y ago
  I have done this so can confirm, but every time I did I wished I didn't need to. I had a running nightmare where yesterday's trading data made us trade today.
  - greglindahl 10y ago
    Or today's trading is different enough from yesterday's that your app hits perf issues. Black swan, anyone?
    - brianwawok 10y ago
      Might not even be that. At some point you need to cut out the output from going to the real exchange. If you had an IF somewhere random in your code.. you will then JIT code that is wrongly optimized. If you try to put some kind of network device to capture the traffic and respond with fake responses to make the code happy.. you are one bitflip away from sending bad stuff to prod.
      - kasey_junk 10y ago
        > you are one bitflip away from sending bad stuff to prod. Including some ascii art of Trogdor the Burnanator!
        brianwawok 10y ago
        Ya that is tricky with binary formats. What exchanges still support ASCII? I want to send messages that are both ASCII art and a valid trade...
- brianwawok 10y ago

OldSchoolJohnny 10y ago

I'm surprised to hear anyone running Java in the trading industry. Isn't speed a huge factor in that industry?

lygaret 10y ago
The JVM is super speedy, if you can mitigate startup time and the time required to warm up the JIT.
- lomnakkus 10y ago
  ... and Distruptor/Aeron. (etc.)
maaaats 10y ago
Thus the Java.
eternalban 10y ago
> Isn't speed a huge factor in that industry? Exactly. There are a lot of high performance system written in Java. For long running systems, the startup cost is irrelevant. And for networked systems (such as fintech) you are going to be IO bound. The main issue as far as Java and high performance is the GC related pauses and that is a concern shared with any GC'd runtime.
- PeCaN 10y ago
  And for Java it's actually much less of an issue thanks to the crazy manhours put into developing fast GC for Java. I suspect Azul Systems's pauseless GC is probably quite popular in HFT.
  - brianwawok 10y ago
    They are trying to sell it for sure. They attend a lot of events. I am not aware of any trading company using it. May be some.. but the high perf people I know go other ways.
chrisseaton 10y ago
For example: https://github.com/OpenHFT https://github.com/OpenHFT
taneq 10y ago
I seem to recall a prior discussion where a dev working on HFT stuff said that speed is a huge factor, but so is the ability to rapidly change functionality. They settled on Java because it was fast enough (HFT would have to be IO bound, right?) while still being flexible enough to allow them to adapt to daily changes in requirements.
pjmlp 10y ago
Besides what the others already replied, the use in the trade industry is one of the reasons of Java having to adopt AOT, value types, JNI replacement and better integration with GPGPUs.
kitd 10y ago
You're assuming Java is slow. Evidence suggests otherwise. Eg. LMAX Exchange uses a lock-free ringbuffer they call Disruptor [1] which enables 6M tps on a single thread [2] [1] https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ [2] http://martinfowler.com/articles/lmax.html http://martinfowler.com/articles/lmax.html
- brianwawok 10y ago
  And disruptor is a few years old now, there is a whole new wave of queues with even better performance.
nurettin 10y ago
Java shot itself in the foot with the whole GC thing. Then it built a gigantic robot exoskeleton called Hotspot to help itself walk fast again.
- lucian1900 10y ago
  Java's GC isn't why it can be slower than C/C++ and the JIT (HotSpot) has nothing to do with the GC.
  - nurettin 10y ago
    Well you just told that to someone who lived with GC pauses and profilers for years. And I did not say hotspot is about GC.

deleted 10y ago

[deleted]

WatchDog 10y ago

A lot of firms will run some training data through their application after startup, so that the hot paths get optimised.

kasey_junk 10y ago
I have done this so can confirm, but every time I did I wished I didn't need to. I had a running nightmare where yesterday's trading data made us trade today.
- greglindahl 10y ago
  Or today's trading is different enough from yesterday's that your app hits perf issues. Black swan, anyone?
  - brianwawok 10y ago
    Might not even be that. At some point you need to cut out the output from going to the real exchange. If you had an IF somewhere random in your code.. you will then JIT code that is wrongly optimized. If you try to put some kind of network device to capture the traffic and respond with fake responses to make the code happy.. you are one bitflip away from sending bad stuff to prod.
    - kasey_junk 10y ago
      > you are one bitflip away from sending bad stuff to prod. Including some ascii art of Trogdor the Burnanator!
      - brianwawok 10y ago
        Ya that is tricky with binary formats. What exchanges still support ASCII? I want to send messages that are both ASCII art and a valid trade...
brianwawok 10y ago