Forums  > Software  > Becoming a Low Latency Java Developer  
     
Page 1 of 1
Display using:  

Jurassic


Total Posts: 152
Joined: Mar 2018
 
Posted: 2018-05-09 19:43
How do you go from a being a Java developer to being able to do low latency Java development (professionally).

What are the major differences in what you need to know?

What books/texts should you read to get to that level of knowledge (assuming non CS major)?

EspressoLover


Total Posts: 333
Joined: Jan 2015
 
Posted: 2018-05-10 16:28
With the caveat that many smarter and more successful people would disagree with me... why the fuck would you pick Java for low-latency in the first place? Yes, it can be tuned to be nearly competitive with C/C++. But the whole raison d'être for Java over C++ is the streamlined transparency. Garbage collection, memory safety, the JVM, WORA, simplified builds, everything's an object, autoboxing, etc.

That stuff is great, because it lets you disregard a lot of mental overhead, and just have the language/runtime take care of it. E.g. no need to worry about X gets freed because the GC handles it automatically. But when you're trying to squeeze out microseconds, those abstracted convenienced become major pitfalls. Not that you can't develop around them to achieve low-latency, but you have to spend a lot of effort doing so. E.g. how do I avoid triggering the GC in the middle of the hotpath or how do I make sure my JVM isn't interpreting bytecode during critical sections.

Rather than reducing the developer's cognitive burden, these feature are now increasing the design's complexity. You have all the challenge of low-latency programming in a bare-metal language, plus the headache of wrangling Java's bullshit into a context it was never meant for.

Yes, C/C++ is inherently unsafe. But if you really need Java-like safety and memory integrity, I'd say go with Rust. The abstractions in Rust are much more simpatico with the needs of the typical low-latency application.

As to your question about what to study, if you don't have a CS background, I'd suggest starting with the lecture notes or textbook of intro courses in algorithms, OS, compilers, and architecture. Yes, there are specific tricks and hacks to achieving ultra low-latency that won't be covered by these general classes. But 90% of latency is just good design principles, and awareness of how computers actually work. Without this foundation, you're not going to understand the logic behind the hacks anyway.

Good questions outrank easy answers. -Paul Samuelson

HankScorpio


Total Posts: 477
Joined: Mar 2007
 
Posted: 2018-05-11 04:16
Re the JVM GC, etc issues, this could be a solution:

https://www.azul.com/products/zing/

As used by LMAX: https://www.azul.com/successstories/lmax-exchange-2/


EspressoLover


Total Posts: 333
Joined: Jan 2015
 
Posted: 2018-05-11 09:42
I am not a Java expert, but my understanding is that C4 is far from a silver bullet. Pauseless GC is only achieved through encapsulating all objects in read barriers. (The original Azul product had to use custom hardware because of this.) This leads to all kinds of funky performance issues. Code that should intuitively be very fast can run slow for very unintuitive reasons, often during unpredictable corner cases. Allocations also become a lot more expensive with read barriers. Finally keep in mind that while C4 GC is pauseless, the Zing JVM as a whole still has pauses.

I'll stand by my original thesis. If you're already stuck in a JVM codebase, then use Zing. For low latency, it's almost certainly low-hanging fruit. But if you're not, or you have the resources to redevelop, then just use Rust or C++17. The point of a GC is so you don't have to think about it. Even with Zing, we still have to think about GC (and its downstream effects) *a lot*. In contrast, modern-day smart pointers and RAII have pretty much made non-GC memory management painless.

Good questions outrank easy answers. -Paul Samuelson

Jurassic


Total Posts: 152
Joined: Mar 2018
 
Posted: 2018-05-11 13:42
I think there is at least one major bank and one hft firm that use java for low latency stuff

Maggette


Total Posts: 1054
Joined: Jun 2007
 
Posted: 2018-05-11 14:09
Low Lattency and HFT are vague terms...what actualy qualifies as HFT is not clear (at least to me and to some HFT guys I talked to) I know Valo is a prop shop that uses Scala(JVM)...but they are not ultra Low Lattency
https://youtu.be/5znAJPtfu6s

Ich kam hierher und sah dich und deine Leute lächeln, und sagte mir: Maggette, scheiss auf den small talk, lass lieber deine Fäuste sprechen...

mrdivorce


Total Posts: 8
Joined: Jan 2017
 
Posted: 2018-05-25 13:00
@EL and others, anyone have much experience using Rust in a trading environment? It recently popped up on my radar and sounds awesome, especially the demanding compiler (I come from from the world of FP so crave compiler prophylactic). I'd like to try rewrite a couple of things using Rust so am keen to hear tales of how folks have found its use in production or of any particular areas where it shines

jslade


Total Posts: 1136
Joined: Feb 2007
 
Posted: 2018-05-25 21:32
I have a friend who started developing his trading platform in Rust a few years back. There were huge problems with it. The performance is nowhere near what is claimed, and floating point ... fuhgeddaboudit.

Maybe it's improved, but golang seemed to deliver on most of its promises, and makes more sense than Java.

"Learning, n. The kind of ignorance distinguishing the studious."

EspressoLover


Total Posts: 333
Joined: Jan 2015
 
Posted: 2018-05-29 18:32
IMHO...

Leaving language design aside and just talking about performance. If your 99%-latency constraints are in low milliseconds, then Golang works great. But if you're aiming for tens of microseconds, I don't see any viable alternatives outside Rust.

Go's GC is fast but pauses are still on the order of 1000 uSec. (Plus you give up heap compaction for this speed.) Go's allocations are also opaque and bassed on esoteric escape analysis. In fact allocation isn't even defined in the language standard, and is compiler dependent. In Rust everything gets allocated on the stack, so reasoning about Rust code performance is pretty much as straightforward as C++. (Not saying this is a free lunch, with Rust you pay for the borrow checker with horrendous compile times.) Then there's the callstack shenanigans that come along with Goroutines. (Which is great for lightweight threading, but sucks for deterministic latency on deep callstacks.)

But the biggest issue is that cgo involves too much overhead to be called in the hot path. That means you've got to throw away your entire C library or any third-party C library you may be using. Any low-latency code path has to be pure Go. In contrast with Rust it's super easy and fast to go back and forth between C/C++. Since Rust has no runtime, it can be seamlessly embedded in C programs and vice versa. Outside of very weird hacks, if you want Golang anywhere, you're required to launch from a Golang main().

Agree about floating point math. Math heavy subroutines should always be in C/C++/Fortran, to take advantage of ffast-math, CPU targeting, and SIMD.

That being said, I don't really know if Rust is worth it. C++17 pretty much gives you all the features being used to sell Rust. As long as you mandate stdlib smart pointers, you get the same memory safety. The only thing really missing is modules. cargo and "go get" are indeed way way way better than whatever two-bit nonstandard options exist in C space.

But the real strength of Rust is the ability to replace C/C++ piecemeal. The best approach is to play around with trying one or two new components or subroutines in Rust, and seeing how it works out. That's going to give you a very intuitive feel for where it shines and where it doesn't. And it's something you can't practically do with Golang, JVM, .Net, etc.

Good questions outrank easy answers. -Paul Samuelson

Jurassic


Total Posts: 152
Joined: Mar 2018
 
Posted: 2018-05-29 20:20
The problem with languages like Rust though is that there arent many jobs in them compared to mainstream languages
Previous Thread :: Next Thread 
Page 1 of 1