Live data from Hacker News

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

news.efinancialcareers.com

171–180 of 483 posts

Re: Java is better than C++ for high speed trading systems

#171

Earlier quoted context omitted.

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 what you think the practical benefit of running with no OS is?

    - raw, unshared access to devices.
    - no more interrupts.
You can get really close to this via virtualization though. Run a guest machine without operating system on the hypervisor. It doesn't even have to be low level code to get most of the benefits (for example MirageOS)

Re: Java is better than C++ for high speed trading systems

#173

Earlier quoted context omitted.

Yeah, basically everything has to be that way. At the super fast speeds you start running into things like: * why won’t the devirtualizer trigger? * these object headers are sure wasting a lot of cache * there’s a lot of forced pointer indirection And you just end up spending vast amounts of time and effort trying to shave off those few microseconds you’re wasting in the JVM. Once you add in all the effort trying to…

What do you mean by ‘devirtualizer’ and why would you want that triggered? Sounds like something you wouldn’t want to trigger?

See Aleksey Shipilёv on JVM method dispatch: https://shipilev.net/blog/2015/black-magic-method-dispatch/

Re: Java is better than C++ for high speed trading systems

#174
It really depends on the edge that needs to be captured. If we're trading a low latency edge in SP500 E-Minis, then not only is C++ better but it might be the only option to successfully capture that edge.

On the other hand it we have some niche edge in a smaller market that's less speed competitive, Java might very well be the better choice given that we might be able to capture that edge with 8us tick to trade latency.

So the answer totally depends on what edge you're trying to capture. There are still a large number of edges where Java is good enough. GC is not really a problem, either using a commercial JVM or coding without much garbage and large memory.

Re: Java is better than C++ for high speed trading systems

#175

Earlier quoted context omitted.

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 compile…

The jit compiler of typical jvms automatically uses the instruction sets (with limits afaik) that are available on the hardware that it is running on.

Re: Java is better than C++ for high speed trading systems

#176

Earlier quoted context omitted.

The devirtualizer (maybe this is the wrong JVM terminology, it’s basically what clang/GC call it) is part of the optimizer which sees that you have a virtual function call (like most in Java) where there is a unique caller, so you can replace the virtual call with a direct one and possibly inline it. In the JVM I think this can only be done speculatively (you have to double check the type), but it still matters.

Ah right yes conflict of terminology. In the JVM devirtualising means making a virtual object a full object again, so the opposite of what you want to be happening. I don't think the JVM really names the optimisation you're talking about, but it does do it, through either a global assumption based on the class hierarchy, or an inline cache with a local guard.

[deleted]

Re: Java is better than C++ for high speed trading systems

#177

Earlier quoted context omitted.

The devirtualizer (maybe this is the wrong JVM terminology, it’s basically what clang/GC call it) is part of the optimizer which sees that you have a virtual function call (like most in Java) where there is a unique caller, so you can replace the virtual call with a direct one and possibly inline it. In the JVM I think this can only be done speculatively (you have to double check the type), but it still matters.

Ah right yes conflict of terminology. In the JVM devirtualising means making a virtual object a full object again, so the opposite of what you want to be happening. I don't think the JVM really names the optimisation you're talking about, but it does do it, through either a global assumption based on the class hierarchy, or an inline cache with a local guard.

What do you mean by “virtual object”, an object which has been broken up on the stack instead of a “real” object living as a single entity on the heap?

Re: Java is better than C++ for high speed trading systems

#178

Seems like bending over backwards to use Java. If you are using Java in a c-like fashion, what's so bad with C++ which is c-like by default and has some Java-like features?

The article mentions crash logs. I can sorta relate, my company has their core application built in C (or C++? idk), and they will often have one FTE slave away for weeks analyzing a crash report / core dump, because apparently the code doesn't give nearly enough information to debug a production crash.

whereas in Java you get an exception, a stack pointing neatly at where the issue was and an error that explains what's going on, and you can fix it and move on.

I'd argue that C-like Java is much easier to debug than C.

Re: Java is better than C++ for high speed trading systems

#179
post #169
post #110

Earlier quoted context omitted.

A pause is still a pause though. One system I know of had a solution. Throw in a huge amount of RAM on the server and delay garbage collection until end of day.

Interesting but doesn't allocation get slower as the heap increases?

Normally yes but that’s mostly a factor of heap fragmentation. It the GC never runs the “old” buffers are always full so you never bother going through them.

Re: Java is better than C++ for high speed trading systems

#180
post #118
post #4

So they want super efficient but safe code ... sounds like Rust.

Does anyone know of Rust in HTF teams? I think Haskell and OCaml may also be a good fit (and I know for a fact those are used in HFT teams).

Not sure whether this counts but someone did post their experiences of it on reddit.

https://www.reddit.com/r/rust/comments/bhtuah/production_dep...

Post reply on HN