3 ms·

> You just need to write it like C++, with memory management in mind at each stage of development. Having worked on a 'low latency' trading system written in J

> You just need to write it like C++, with memory management in mind at each stage of development. Having worked on a 'low latency' trading system written in Java, this is true. Ultimately you end up using a flyweight pattern over shared memory, and you have to be aware of alignment and cache sizes. Then there are other tricks like zero GC, or pushing the collection back to once a day. You also spend a fair amount of time analyzing performance to the nanosecond looking for, and eliminating, jitter. I've also written the same in C++, and it's a similar exercise, along with dashes of [[unlikely]], template specialization, and far too much time inside godbolt.org looking at assembler to see if gcc/clang has "optimized" something in the latest release.

gpderetta 6y ago
In your experience, which one was more pleasant to write? Did java allow for iterating quicker?
- DrBazza 6y ago
  > which one was more pleasant to write? Did java allow for iterating quicker? Java. And I'm a career C++ programmer. The whole system was built to be event driven (messaging) from the ground up too. It had a lot of benefits like performance testing code without instrumentation, the whole junit/mockito ecosystem, code completion in Intellij that actually worked. You only had to worry about code errors, not linker errors. We had over 100,000 unit tests. We leveraged the whole JVM and ecosystem too. Outside of the hot path code, we could just go and use json libraries, webservers, and so on. In C++ we'd be struggling (not so much these days), to throw together a JSON/REST/ws webserver in the same code base. Though Java always feels like to trying to unwrap a present whilst wearing mittens. It's excessively verbose. We didn't pick Kotlin as at the time as that was known to emit various extra byte code for seemingly trivial calls, and was only on v1.0 at the time.
  - gpderetta 6y ago
    Thank you (and the sibling as well) for the comment. As a non-Java programmer, I'm probably underestimating the value of the java ecosystem.
- bitcharmer 6y ago
  Not the OP but we seem to have very similar experience developing low latency HFT systems in both languages. Java is much more comfortable to work with when you need to rapidly deliver some latency-sensitive functionality, doesn't blow up with segfaults if you do something stupid and has awesome profilers, debuggers, IDEs, dependency management, etc. Where it looses compared to C/C++ is when you need to have absolute control over the emitted native code (this is getting very close to solved with Graal) or when you need to prevent deoptimization storms when hitting an uncommon branch in the middle of the trading day (there are ways to prevent or limit it but it's ugly).

gpderetta 6y ago

In your experience, which one was more pleasant to write? Did java allow for iterating quicker?

DrBazza 6y ago
> which one was more pleasant to write? Did java allow for iterating quicker? Java. And I'm a career C++ programmer. The whole system was built to be event driven (messaging) from the ground up too. It had a lot of benefits like performance testing code without instrumentation, the whole junit/mockito ecosystem, code completion in Intellij that actually worked. You only had to worry about code errors, not linker errors. We had over 100,000 unit tests. We leveraged the whole JVM and ecosystem too. Outside of the hot path code, we could just go and use json libraries, webservers, and so on. In C++ we'd be struggling (not so much these days), to throw together a JSON/REST/ws webserver in the same code base. Though Java always feels like to trying to unwrap a present whilst wearing mittens. It's excessively verbose. We didn't pick Kotlin as at the time as that was known to emit various extra byte code for seemingly trivial calls, and was only on v1.0 at the time.
- gpderetta 6y ago
  Thank you (and the sibling as well) for the comment. As a non-Java programmer, I'm probably underestimating the value of the java ecosystem.
bitcharmer 6y ago
Not the OP but we seem to have very similar experience developing low latency HFT systems in both languages. Java is much more comfortable to work with when you need to rapidly deliver some latency-sensitive functionality, doesn't blow up with segfaults if you do something stupid and has awesome profilers, debuggers, IDEs, dependency management, etc. Where it looses compared to C/C++ is when you need to have absolute control over the emitted native code (this is getting very close to solved with Graal) or when you need to prevent deoptimization storms when hitting an uncommon branch in the middle of the trading day (there are ways to prevent or limit it but it's ugly).