Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.efinancialcareers.com

Post reply on HN
Print view View original

161–170 of 483 posts

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

#161

Post by vgatherps »

chrisseaton wrote: post #157
bboygravity wrote: post #149

Earlier quoted context omitted.

More processing capacity for your application (no need to share with OS), no more interruptions by the OS that are unpredictable in duration, no more interruptions by the OS that are unpredictable in terms of timing and priority and above all, since this seems to be the main goal of the software we're talking about: lower overall latency. Standard C++/JAVA (as far as I know) talks to hardware through a software layer…

You can get all this by pinning to a core and DMA to hardware. Think of the OS like a library - if you don't call it and don't ask it to call you it stays out of the way. There's no need to throw away the OS.

This is exactly what is done. OS’s are really nice to have around and will stay out of the way. In the day and age of fpgas no reason to ruin the software side to maybe kind of sort of get a bit faster in your software?

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

#162

Post by chrisseaton »

vgatherps wrote: post #158
chrisseaton wrote: post #138

Earlier quoted context omitted.

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

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.

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

#163

Post by gameswithgo »

chrisseaton wrote: post #162
vgatherps wrote: post #158

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.

the jvm names the optimization exactly like he said

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

#164

Post by gameswithgo »

brundolf wrote: post #38

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?

Java got popular for HFT before .NET core. c# was just generally slower at the time. It would likely be the preferred choice at this point. Though Rust is really perfect for this kind of thing.

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

#165

Post by gameswithgo »

littlecranky67 wrote: post #68
brundolf wrote: post #38

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?

Am also wondering (I have no experience on that matter) how .NET performs in terms of GC as I remember at some point they introduced a threaded GC that dropped the stop-the-world approach and perform garbage collection in dedicated threads. Anyone got some insights?

its on par with the jvm but still has to stop the world sometimes

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

#166

Post by secondcoming »

thangalin wrote: post #45
howlgarnish wrote: post #8

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…

Currently developing a radio communications system using Java, with JNI calls for hardware integration, running on a quad-core 32-bit ARM processor. We have constraints of around 20ms for real-time audio packet processing. Recently some stop-the-world pauses introduced by the GC resulted in calls dropping. A few GC parameter tweaks brought our latency below 20ms and the application no longer drops calls. This is usin…

> real-time, safety-critical operations

Doesn't Java itself say it shouldn't be used for anything like this?

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

#168

Post by hnracer »

Ragib_Zaman wrote: post #102
vgatherps wrote: post #95

Earlier quoted context omitted.

The third one was definitely the least, it was losing money (and specifically to trader-invisible things that never got worked on). The whole of the trading strategy (and capital traded, return profiles, etc) between the first two was fairly different, so it’s hard to compare. I would say though that the first firm was significantly outperforming its peers in a way the second firm did not, although both were very suc…

It's generally pretty rare for a market maker to lose money over a whole year. Colour me surprised.

True but I feel that the market maker label gets applied pretty loosely nowadays, couldve been a firm that mixes in a lot of intraday position taking trades that blew up

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

#169

Post by 2sk21 »

simonh wrote: post #110
dehrmann wrote: post #67

Earlier quoted context omitted.

I've heard of people doing that 10-15 years ago. I'm sure it still works, but hopefully the GC situation has also improved.

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?
Post reply on HN