Banks run on either or a mix of mostly JVM and/or CLR, and it's not for no reason.
Java is better than C++ for high speed trading systems
121–130 of 483 posts
Re: Java is better than C++ for high speed trading systems
#122The programmer is often more important than the PL.
Though most programmers will not modify the PL to fit their needs, hence the PL limitations become the programmers limitations.
It's easier for a programmer to learn a new PL (at the start of the project) than for a 500kLOC code base on GC-enabled JVM to migrate to Rust.
Re: Java is better than C++ for high speed trading systems
#123"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. " Does anyone have any guidelines for this type of code?
Basically it sounds like they adhere to MISRA C principles (but for Java) which is used in industries where performance and safety is more critical. Think embedded systems in automotive, space, etc.
Re: Java is better than C++ for high speed trading systems
#124I’ve seen this sentiment before and worked on both a “low latency Java” team and low latency C++ teams. I have some sympathy for the idea that the JVM is better since it means you won’t spend all your time chasing crash reports. The thing is, like another comment hinted at, is that this issue is generally more reflective of the environment you build in than the technology choice. Here’s a good talk on the reasons for…
Am I understanding correctly that those firms really really care about latency & have unlimited money & chose C++/JAVA with a standard off-the-shelve compiler + an OS and/or JVM?? If you'd really really care about latency and have the resources, wouldn't it be more effective to just go bare metal? Bare metal as in: no OS (talk to the hardware registers directly from code), possibly a custom compiler, use all the rele…
I don't know about java, but when using c++ you can use the OS to start the program, set up the hardware mappings and then move it to an isolated core where you talk to the hardware directly without ever issuing a system call.
Compilers already offer flags to optimize for specific processor generations (and use the newly available instructions); you aren't going to be able to do better than that with a custom compiler.
Re: Java is better than C++ for high speed trading systems
#125Well, now there's Rust. So Java isn't best technical (performance, safety, correctness) choice for most applications.
Re: Java is better than C++ for high speed trading systems
#126Earlier quoted context omitted.
In what regard do you think it's not mature enough yet?
The thing about Rust is that so many features are considered unstable and require switching to the nightly toolchain. That's just not suitable for real-world production use - yes, stuff does get stabilized eventually, but it takes time to really nail down the best possible design. Still, it's way better than the huge mess that is C++.
> The thing about Rust is that so many features are considered unstable and require switching to the nightly toolchain.
The core features are stable for a long time. The days that you needed nightly for pretty much ever web framework are behind us.
Re: Java is better than C++ for high speed trading systems
#127C++ is a fantastic language but it somehow attracts people with big ego. The smartest people I know would always try to simplify things, but many C++ developers (especially in financial industry) have this preference for complexity I can't explain. And C++ is the worst language to get clever with.
I switched to C++ after years of doing web development in python, javascript and typescript, go and other high level languages associated with web dev.
You're not wrong, the ego among C++ devs is astronomical. There's a huge amount of serious hate for python and this idea that being a C++ dev is superior.
Get this we use Nix and C++ and the nix part of the code base is just as complex as the C++ code base. The nix stuff is just infrastructure! It's insane.
Re: Java is better than C++ for high speed trading systems
#128Earlier quoted context omitted.
As others said, no full GC events. Young generation GC is cheap, no need to avoid that. Productivity is the point. Even while paying attention to GC, it's much faster to write good code in Java than to worry about every malloc() in C. I love C, but if I need to churn out high performance code quickly, Java is the choice.
But here we're talking about C++: you don't write malloc, you use containers that encapsulate memory management - likely std::containers with pool allocators. And you put things on the stack. Code is as readable if not more than java - there isn't any "new," anywhere in sight
Modern C++ is probably about as good, with sufficient team discipline. I don't have enough recent experience with C++ to have a strong opinion.
IMO (possibly biased by how much I hated C++ in the 90s) it is easier to maintain clean code discipline in a large team with Java than it is with C++.
Re: Java is better than C++ for high speed trading systems
#129C++ is a fantastic language but it somehow attracts people with big ego. The smartest people I know would always try to simplify things, but many C++ developers (especially in financial industry) have this preference for complexity I can't explain. And C++ is the worst language to get clever with.
C++ lets you "get things done" when the other tooling you need is your brain. Unfortunately, that might mean template metaprogramming that makes a compile take >50 minutes, and where any syntax error typo generates a 4000-line error message -- but for some people, being to use C++ to get things done is an intellectual reward onto itself.
If you wanted to get the same performance from C, you'd sometimes need to write your own preprocessor/code-generator, and/or abuse the built in preprocessor, so you can specaialize. To get the same performance in Python you need to go down to C. To get the same performance in Java, you need to do stuff like what's mentioned in this thread (allocate 1TB of memory and disable GC, for example).
The only place where this is considered acceptable and commonplace, is the C++ community, I guess a chicken-and-egg problem.
In most places, you only need that performance in a small part of your pipeline - which in HFT teams will sometimes be done in FPGA or ASICs or NIC firmware. For those places, C++ is also often required, and network effects (and "impedance mismatch") often mean that it will get used for a whole lot more than where it's actually essential.
C++ is not the only such community for algo trading, by the way - the K programming language enables fast yet incredibly short implementations, and thus tends to attract competitions in "how short can you get the fastest code" (aka code golfing) to manifest all over implementations. And personally, I'd much rather have a oneliner K brainteaser that does alot than a huge 100-line C++ template monster that does the same thing 10% more quickly.
Re: Java is better than C++ for high speed trading systems
#130Earlier quoted context omitted.
.NET 5 was released Nov 10th: https://devblogs.microsoft.com/dotnet/announcing-net-5-0/
Released doesn't mean it's production ready :-)
> It’s already in active use by teams at Microsoft and other companies, in production and for performance testing.
Apparently it's production ready-ish.