61–70 of 483 posts
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.
In my experience, most java developers even in this field (or "embedded" that has similar requirements) tend to resist when someone proposes to use "c-like java", too used to their fancy libraries and APIs.
This is where modern C++ (augmented with, e.g. the C++ Core Guidelines) and Rust are more convenient and even "better" than Java. Fancy libraries and tools, with zero additional overhead compared to the optimal low-level code.
This is not "why Java is better for fast things". It is not. This is "why Java is better", and the answer is "it usually is better because your programmers often suck".
I wonder if this will change in the future when rust may become a more mature language. It would offer the speed and the safety needed for this kind of task.
I used to work on a high-speed messaging system built in Java, and garbage collection was a killer. No matter how much we tweaked the code and the GC parameters, and this eventually got escalated pretty high up in Sun itself, we'd get these occasional multi- minute pauses where the whole thing would just freeze up, buffers would fill and stuff would start dropping on the floor. This was over 10 years ago, so things m…
Source: I worked on several extremely high performance Java systems at Sun and also worked optimizing various Java servers at subsequent jobs based on my Sun experience.
At one company (after Sun) I took on a backend service which was doing GC pauses every 3-5 minutes, the code was a dumpster fire mess. After cleaning things up we didn't hit a single full GC in two months of production use (they redeployed every two months so that's as long as the process lasted).
I’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…
I thought the actual approach taken these days is to disable GC for any JVM based trading systems and use arena based architectures or similar for application where you need super low latency, like a LOB mirror or execution engine, no?
Hearing them describe this "C-like Java", I'm surprised C# wasn't a better fit given that it has value-type "structs" that don't have to sit behind a reference on the heap. As far as I know, Java still doesn't have an equivalent feature. Maybe the JVM's GC is just so much faster that it's worth it?
As an HFT programmer I like this article because it means less competition for me. I mean, you can write a very fast system in Java but by the time you accomplish that goal you’ll have spent as much or more time than if you had just used C++.
But I get why people might feel it's worth a try, cpp probably looks more daunting than any other language to a novice. There's a lot of concepts to be mastered before you can write decent cpp, where in a lot of languages you can get started and discover things later. With cpp the abstraction gets very detailed. You might not even care what the difference between stack and heap, value or reference passing is in other languages.
Eg you can write python pretty intuitively and get a hash table as part of the language. If you're writing cpp you need to know how types work, how templates work, and how the STL containers work (allocators, traits, constness etc) just to save a simple hash table.
What would josh.com say..?