6 ms·

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

by OldSchoolJohnny 10y ago

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.

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.