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

51–60 of 483 posts

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

#51

Post by mypalmike »

carlmr wrote: post #27
euske wrote: post #18

While I might not agree with the conclusion of the OP, the performance of a programming language should be always paired with its "average" programmers. A lot of people tend to straw-man a language they dislike and iron-man (?) a language they like. For an average programmer, I think it might be possible that Java produces a more performant/maintainable code than C++.

This is very true. I've seen colleagues port Python to C++ and wonder why it's slower. Of course Python is slow, but it will call into efficient C routines for a lot of things that aren't just available out of the box in C++. So what does the average programmer do? They implement their own, inefficient version of this in C++. Now you've saved the overhead of copying your data from the Python to the C-world and back,…

When I moved from C/C++ to Java on the 90s, I was amazed how casually things like hash tables would be used. A single function might create a couple hash tables, do some data juggling and sorting, and solve a problem in like 20 lines of readable, performant code. In my experience, C coders almost invariably employ less performant algorithms and data structures due to the incidental complexity involved in memory allocation, pointer indirection, etc.

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

#52

Post by [deleted] »

m_mueller wrote: post #43
Cojen wrote: post #26

Earlier quoted context omitted.

I've found that coding in a "C-like style" offers great performance too. Are there any languages that target the JVM and are designed for higher speed? If it enforced the "C-like style" at the language level, perhaps it would be easier to follow? Of course at this point the usual answer is just use Rust, but is there a language that meets in the middle? Sometimes I just want the GC to do the work and I'm okay with th…

I find Java itself works quite well for this. Especially newer Java versions with functional interfaces. You keep your data in data centric classes (e.g. something akin to struct-of-arrays in C) and have some functional interfaces to access this data, the only place where you loop over it, maybe in batches if it's really large (test it though, up to 10s or 100s of millions of elements is still fast to loop through in…

[deleted]

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

#53

Post by jmnicolas »

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?

.NET was slower than the JVM before .NET Core but nowadays it's faster.

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

#54

Post by m_mueller »

jbverschoor wrote: post #48
m_mueller wrote: post #36

Earlier quoted context omitted.

Another user commented here a while ago that they solved this problem by just throwing it on the largest instance by memory (1TB or so), disabled GC and restart it after market closes.

Largest instance sounds like aws. There’s your nr 1 performance bottleneck

well, you choose the node infrastructure by whatever network latency you need to have guaranteed - obviously public clouds have their limits there.

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

#55

Post by danielscrubs »

If any company thinks they can just get a consultant that fixes these things they are just not going to make it. Bosses and programmers need to be fired and senior developers put in place. There are no free lunches.

Interesting to note the comment section there vs here.

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

#56

Post by logicchains »

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…

>A few GC parameter tweaks brought our latency below 20ms and the application no longer drops calls.

Tick to trade latency for a modern software HFT stack needs to be under 10 _microseconds_, which is over three orders of magnitude more stringent.

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

#57

Post by taneq »

patrec wrote: post #46
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…

Why did your system dynamically allocate memory in the first place? High speed messaging sounds like an area where it should be doable to figure out at startup what resources you need to meet your latency and throughput requirements and then allocate them once and basically never gc anything. Was there some fundamental difficulty with that, or was it more that by the time your realized that GC would kill you, all you…

The best part about using a garbage collected language for high performance software is it's exactly the same as a non-garbage-collected language.

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

#58

Post by jeffreygoesto »

selestify wrote: post #32
CoolGuySteve wrote: post #29

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++.

Do you think it’d be even faster if you used C?

Nope. Watch the CppCon video mentioned in one of the top level comments. It's all about not allocating. C or C++ is not the real difference.

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

#60

Post by arthurcolle »

vgatherps wrote: post #25

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