17 ms·
If you are part of the HFT crowd who uses the JVM then you know who the author, Cliff Click, is. His Blogs (former and current) are goldmines for high performa
by chollida1 10y ago
If you are part of the HFT crowd who uses the JVM then you know who the author, Cliff Click, is.
His Blogs (former and current) are goldmines for high performance JVM information.
http://www.azulsystems.com/blog/author/cliff http://www.azulsystems.com/blog/author/cliff
http://www.cliffc.org/blog/ http://www.cliffc.org/blog/
I had one CTO of a public HFT firm tell me that short of FPGA's Azul's pause-less GC (https://www.azul.com/products/zing/pgc/ https://www.azul.com/products/zing/pgc/) was the biggest performance win they'd had in the past few years, note: this was a few years ago.
EDIT: someone emailed asking for how HFT firms write their java code. I haven't written java in 3 years so I'm probably not the best person to author a list but this is what I'd include:
In order of importance:
- Measure, measure, measure. Every HFT firm can tell you to the nanosecond, as much as that's possible, what their time is from receiving a packet to when it's replied to. Focus as much, if not more on the 95%, 99% times as the average time.
This time increasing is considered a bug in the same way that an app crashing due to user input is considered a bug, which is to say that you just don't ship with this kind of bug.
- no GC's, everything else starts to become less important if the GC is called every 30 seconds. Some guys will have only one GC call a day, which means you have a really large Eden GC space
- short call stacks, and no recursion
- one physical core per thread
- non locking data structures and use the one writer principle where possible
- don't use the kernel if possible, ie solar flare Ethernet cards that have userland drivers
- cache friendly data structures
Watch this video:
https://www.youtube.com/watch?v=iINk7x44MmM https://www.youtube.com/watch?v=iINk7x44MmM
- duaneb 10y agoAzul is still state of the art, certainly for the JVM.
- alexhutcheson 10y agoGreat interview with him from way back in 2007: https://web.archive.org/web/20071020182028/http://theserverside.com/tt/knowledgecenter/knowledgecenter.tss?l=MetalMeetsJVM https://web.archive.org/web/20071020182028/http://theservers...
- bitmapbrother 10y agoThere's also this video by Gil Tene on Low Latency Java in the Real World: LMAX Exchange: https://www.youtube.com/watch?v=6-oS2XHSGvk https://www.youtube.com/watch?v=6-oS2XHSGvk
- azeirah 10y agoIf performance is THAT critical in HFT, why do they pick java as the starting language? I understand that java is very fast, faster than most people believe, but does it beat hand-optimized assembly? Fortran? C? Why Java?
- PaulHoule 10y agoIt's close to impossible to get certain kinds of code correct in C, for instance, string parsing. Also until pretty recently, C and C++ did not have a sane memory model so what happened when threads was involved was dependent on what CPU you are on, the sign of the moon, etc. Java could very well be the first programming language designed by adults and it shows. (That is, they solve the hard problems, not just pretend they don't matter)
- revelation 10y agoEh it's HFT, I'm not sure there is much string parsing going on. Or variable length anything.
- kasey_junk 10y agoSome exchanges use text based variable length message formats. String parsing is very much going on even though its the bane of HFT devs. That's going away as exchanges upgrade their gateways.
- revelation 10y agoThat's just plain terrible. But a good reminder that all the talk about nanoseconds is just that.
- kasey_junk 10y agoThe thing is, everybody has to deal with the string parsing, so speeding up your string parsing does have value even if its slow in relation to non-string based exchanges.
- thefastlane 10y agothis is fascinating. anyone applying these approaches with clojure? i'm wondering what additional considerations (if any) come into scope in the case of other jvm languages
- niftich 10y agoClojure would be a bad fit because it favors immutable objects (which result in lots of GC) and functional programming, which discourages mutative, iterative programming.
- TickleSteve 10y agoDeterministic behaviour is everything.... ...and Clojure is the polar opposite to this due to its structure sharing.
- cheez 10y ago> I had one CTO of a public HFT firm tell me that short of FPGA's Azul's pause-less GC (https://www.azul.com/products/zing/pgc/ https://www.azul.com/products/zing/pgc/) was the biggest performance win they'd had in the past few years, note: this was a few years ago. Even better than using C++? Something sounds off.
- chollida1 10y agoI don't know where you got C++ from. In any case, I assume they stayed with Java as their entire code base was Java with the exception of what ever they program their FPGAs with.
- TickleSteve 10y agoFPGA's are typically used for the real-time front-end in systems like this.... ...Which means that the Java side wasn't doing anything particularly quick or real-time. The Java side was the 'easy&slow' side.... hence they could use Java.
- cheez 10y agoYeah, I concur with what the other guy says. There is no way they were using Java for the HFT side.
- duaneb 10y agoC++ doesn't improve on I/O (including cache misses).
- gpderetta 10y agoHFT systems aren't normally IO bound.
- mkobit 10y agoFor those looking for some open source HFT Java code, you may be interested in looking at some of the code in OpenHFT [1]. [1]: https://github.com/OpenHFT https://github.com/OpenHFT
- cliffc 10y agoThanks for the nod! Cliff
- sievebrain 10y agoIt'd be interesting to learn more about what you meant by "there are much better ways to represent Java than bytecodes". I know you don't do JVM stuff anymore but perhaps one day you could do a talk on how you'd design the JVM differently if you could go back and do it all again.
- cliffc 10y agoRight when Java was taking off, there were a bunch of research proposals for better over-the-wire executable formats (mostly funded by microsoft). Designs where you could convert the bytecodes to machine code as fast as L1 could take it with sane 1st-level-JIT code quality. And also have safety, and enough type info the use a 2nd-level JIT for really hot code.
- sievebrain 10y agoAh so you meant "java bytecodes", not bytecodes in general. Perhaps like pre-calculating register allocation and such? I'd like to read about these sorts of proposals, do you recall the names of the papers by any chance?
- TickleSteve 10y agoFPGA's are typically used for the real-time front-end in systems like this.... ...Which means that the Java side wasn't doing anything particularly quick or real-time. The Java side was the 'easy&slow' side.... hence they could use Java.