You are partially correct. I’ve been consulting for 2 such companies in the past. They get some really beefy servers, I must tell you (of the 96-core & 1TB ECC RAM kind). There even the not-so-amazing Java GC acts quite well.
It’s all about fine-tuning. They had a 25-line script to start their Java VMs and all memory allocation and GC parameters were fine-tuned to hell and back for minimum latency.
I am not an expert in the BEAM but if a mediocre GC tech like Java’s can be used in high-freq trading in this manner then I see no reason why you can’t use Erlang/Elixir or Go. Last time I checked the BEAM VM has plenty of startup parameters that can significantly change its GC and memory allocation behaviour.
Again, not first hand knowledge, but my friend said that the approach to low latency Java was to disable the GC entirely, use object pools and to use a machine with enough RAM for N hours of continuous use before rebooting the VM.
It sounds like we’re talking about different problem spaces. Perhaps I’ve got the name wrong and it’s not “high frequency trading” but some other kind of trading
What makes you call it “mediocre”? I’ve always heard of the GC algorithms used in Java VMs as being some of the best in the world, Azul C4 in particular.
The fact that it starts to severely under-perform under pressure like everybody else (including the BEAM of course).
Most GCs are of the “stop the world” kind, Java and Go included. However, BEAM’s is per-process.
So if you are willing to spend $5000 a month on a dedicated server, Erlang/Elixir is a much better investment. The spikes of lag during GC are much smoother there compared to a heavily loaded Java server.
But again, as said above – fine-tuning is the winning game in this area. I’ve seen several programming languages used for real-time work and they were mostly just fine because a team spent countless sleepless nights to hyper-optimize their system.
I’ve used such a Java system first hand, for order routing. Essentially all memory was allocated at startup. The team who worked on it felt that in retrospect it may not have been worth all the trouble, though. It wasn’t particularly low-latency given all the work that went into it.
HFT systems have really strict requirements, 1ms is huge in that world. I worked on one where the authors spent time benchmarking and implementing their own spinlock because the standard ones had too much latency. In general you’d avoid passing data between too many threads because transferring data from a CPU core to another also adds latency.
I don’t think Erlang has a place in that world, but it would be a fantastic fit for higher latency systems. In fact I was working on one when I discovered Erlang, and that’s what lead me to learn it Our architecture in C++ used the reactor pattern and basically looked like a bunch of little processes exchanging messages already.
Why use Java at all in this case?
