原文：https://www.efinancialcareers.co.uk/news/2020/11/low-latency-java-trading-systems

Why Java is better than C++ for high speed trading systems

by Sarah Butcher 23 November 2020

The accepted wisdom has it that if you're building a high speed trading system you probably want to use C++ instead of Java: it's closer to the metal and is therefore faster (lower latency). However, some leading figures in the industry beg to disagree.

Peter Lawrey, CEO of Chronicle Software, knows a thing or two about low latency programming. A former trading performance engineer at Barclays and developer/researcher at hedge fund Millennium Management (among other things), Lawrey founded Chronicle to work on high speed trading systems in 2013. The company counts ten tier one investment banks and multiple large hedge funds among its clients.

Historically, Chronicle offered consulting services to clients looking to build low latency trading systems. More recently, however, it's pivoted to offering consultancy and what it describes as a "generic customizable [trading] infrastructure" package for clients to iterate upon. This package is coded in Java.

"If you have an unlimited amount of time and resources, the best solution for speed will be coded in FPGA," says Lawrey, referring to the language that directly codes field-programmable gate arrays. "If you still have a lot of time and resources and you want to create multiple exchange adaptors, you'll choose C++. - But if you want to engage with 20+ exchanges, to go to market quickly, and implement continuous performance tuning, you'll choose Java."

The problem with C++ is its fallibility, says Lawrey: "If you're not a really good C++ developer, you can shoot yourself in the foot and bring an entire project down." By way of example, Lawrey points to a system he encountered in an investment bank. It was coded in C++ and should have been fast, but Lawrey says the banks' team of developers instead spent most of their time looking at crash reports and trying to second guess where the C++ was going wrong. Because of this, he says the elements of the system that ran on Java were considerably faster. "They were adding metrics in Java to see what the C++ system was going to do," he says. "It was one of the most backward things I've seen in my career."

This doesn't mean, however, that all Java code is fast. Chronicle's system is built in what Lawrey describes as "C-like Java" and it's this that he encourages people to code low latency systems in.

"The way that we code is more like C++ than Java," says Lawrey. "Essentially, we use a contrived form of Java that avoids all the Java constructs that make things go slow. We only use the constructs that are fast and efficient, and we avoid all the garbage." By simplifying Java and switching to very low level code, Lawrey says it can be possible to speed things up substantially. Sometimes it's simply a question of better diagnostics: "Through simply changing the configuration of the code, we've been able to reduce latency at the 99.9th percentile by a factor of 25."

The only problem with low latency Java is that most experience Java programmers struggle with the new paradigm. "A lot of people who program in Java are used to working in an environment where latency isn't a criteria," says Lawrey. "They may have 15-20 years' experience, but they have no understanding of low level code and of thinking only in terms of the most essential things that need to be happening."

Chronicle coaches clients' own developers in this form of low level Java. It also employs ten specialist Java developers of its own and will be looking to expand further as it rolls out its platform globally. Lawrey says this emphasis on C-like Java can make it difficult to recruit. "We began by hiring people from trading floors, but have more recently hired Masters and PhD students," he says.

Even so, many of the candidates who approach Chronicle aren't suited to the work. "Most Java developers are web developers and are used to modelling things they can see," says Lawrey. "But in a trading system, you care about latencies you can't see, and they're not even your typical latencies - even one millisecond can be significant. The work is very theoretical and abstract and it's difficult to have a visual intuition of what's going on."