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

351–360 of 483 posts

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

#351

Post by fakedang »

rcxdude wrote: post #196
Geminidog wrote: post #127

Earlier quoted context omitted.

I switched to C++ after years of doing web development in python, javascript and typescript, go and other high level languages associated with web dev. You're not wrong, the ego among C++ devs is astronomical. There's a huge amount of serious hate for python and this idea that being a C++ dev is superior. Get this we use Nix and C++ and the nix part of the code base is just as complex as the C++ code base. The nix st…

It's strange, I think that python and C++ are great languages to complement one another. You can write your critical stuff in C++ and use python to glue it all together, and it'll be a pretty effective solution (especially with the sheer amount of options in the python library ecosystem).

This is so true. Put your critical stuff, memory management, etc in C++. Run your ML/computation/data analysis on the side on Python.

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

#352

Post by iamcreasy »

knuthsat wrote: post #182
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…

From my experience, JVM can't do much when there's a deep stack. I remember just refactoring all of foreach-loops/iterators into for-loops and got insane speedups. Functions with inefficient iterations would get optimized if called directly but deep in the call stack and nothing happens. These kinds of things are impossible with C++. It's possible to write efficient Java but you have to not use some of the language f…

> I remember just refactoring all of foreach-loops/iterators into for-loops and got insane speedups.

Wow! Can you please provide a simple example when/where it happens?

> It's possible to write efficient Java but you have to not use some of the language features to do so.

Please tell us more.

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

#353

Post by ryandrake »

Enginerrrd wrote: post #252
levosmetalo wrote: post #228

Earlier quoted context omitted.

"I need that bridge yesterday. If my army doesn't cross the river today, we are all dead. I don't care if the bridge collapse tomorrow, or if the rain wear it down, as long as I can use it today." If it's your job to do what is requested from you, then you do it. It's not like having brittle unmaintainable code is morally wrong. It's not engineers responsibility to judge use case of the customer paying for the bridge…

>It's not engineers responsibility to judge use case of the customer paying for the bridge. Actually yes, yes it is! I am a civil engineer and there's a standard of ethics and personal responsibility among engineers that is very, very high. When we graduate, most engineers participate in a ring ceremony. They get a funny, angled ring on their right pinky. It was originally made from the metal from a bridge that fell…

This is a key common thread in all these discussions. At so many development shops, developers have no agency to push back against poor quality. They don't have a license on the line that they can stand behind and firmly say "NO we will not do it that way or I could be personally liable for its failure!" When they point out that they're shipping buggy crap, the response simply is: Ship the crap on time.

It's strange too, you hear in other threads about how high the demand is for software engineers, how high their salaries are, how much negotiating power they have with their companies, but when it comes to the actual product content, suddenly they have no power at all and it's just Yes boss, whatever you say, boss. How is this true?

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

#354

Post by chrisseaton »

aweinstock wrote: post #348
chrisseaton wrote: post #229

Earlier quoted context omitted.

> 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? Yes... but let's not say 'broken up on the stack' - the object's fields become dataflow edges. The object doesn't exist reifed on the stack - fields may exist on the stack, or in registers, or not at all.

LLVM calls the process of breaking a struct/object into dataflow variables "Scalar Replacement of Aggregates". https://llvm.org/doxygen/classllvm_1_1SROA.html#details

Yes that's what the JVM calls it - and then the node the ties together the state is the virtual object.

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

#355

Post by beagle3 »

ryl00 wrote: post #254
beagle3 wrote: post #145

Earlier quoted context omitted.

> When you write Java in a C like syntax And C is faster still when you write it with Fortran like (column order, and "restrict" mostly) semantics. An old mentor said to me 30 years ago that "A good programmer writes FORTRAN no matter what language they are using" (he was referring to speed of execution in the context of "good"). It seemed super funny at the time, but there's a lot of truth in that.

Why does column order matter? If you translate to the equivalent C/C++ row-major order, it should be laid out in memory the same way.

What do you mean by "if you translate to C/C++ row major order?"

What I meant was: In FORTRAN, you idiomatically do Struct-Of-Array=Column-Major order by default, In C/C++ you do Array-of-Struct or Array-of-Pointer-to-Struct (both of which are Row-Major) by default. The former tends to be much more efficient than the latter in computational code.

It turns out that, often and especially in computationally intensive code, only a small number of fields of an object/record are used in every part of the computation pipelines, but almost all records are.

As a result, if you do your data in column major order, then the cache usage patterns reflect that - whereas if you are in row major order, a lot more field get loaded into cache when they are not needed (thus, much lower cache utilization and lower performance).

FORTRAN did not have structures until quite late (FORTRAN-95 has them for sure, but IIRC FORTRAN-77 and earlier didn't). Thus, the idiomatic way to do stuff is have an SoA=Coiumn-Major implementation, rather than the C/C++ AoS=Row-Major order.

Furthermore, FORTRAN didn't have any pointers. As a result, most code was written with very little pointer chasing / foreign key reference chasing -- which also contributes to efficient use of cache and memory bandwidth.

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

#356

Post by trhway »

bluGill wrote: post #279
trhway wrote: post #76

Earlier quoted context omitted.

absolutely. Few years ago i got back deep into C++ after 18 years of mostly Java, and i'm amazed, it is like travel back in time - we (a large C++ platform) are looping over vectors instead of using hashtables/maps, copying strings all the time (we have 4 major types of strings plus some minor ones), and don't get me started on multithreading and locking/synchronization - such an easy and natural thing in Java - even…

In many cases n is small enough that looping over a vector is faster than a hash lookup. The vector loop is very ry cache friendly, while the hash lookup typically involves a cache miss or two.

it would be for a vector where values are stored in the vector entries. Instead it is usually pointers to strings or objects. So you pull from memory by pointer (i.e. cache unfriendly) every string, compare, etc... And small n is usually small until customer actually generates couple orders of magnitude more of those objects than it was in test/dev :)

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

#357

Post by lmilcin »

Let me put my perspective on this.

As it happens, I have developed one algorithmic, low latency trading system in Common Lisp / ANSI C, and then was asked to rewrite it in Java which I did.

It actually traded on Warsaw Stock Exchange and was certified by WSE and was connected directly to it (no intervening software).

Yes, it is possible to do really low latency in Java. My experience is my optimized Java code is about 20-30% slower than what very optimized C code which is absolutely awesome. We are talking real research project funded by one of larger brokerage houses and the application was expected to respond to market signals within single digit microseconds every single time.

The issue with Java isn't that you can't write low latency code. The issue is that you are left almost completely without tools as you can't use almost anything from Java standard library and left scratching your head how to solve even simplest problem like managing memory without something coming and suddenly creating a lot of latency where you don't want it to happen.

Can't use interfaces, can't use collections, can't use exceptions, etc.

You can forget about freely allocating objects, except for very short lived objects you must relegate yourself to managing preallocated pools of objects.

I don't know what is the current state of garbage collection but in our case garbage collection had to be turned off and nothing outside of Eden could be collected during program execution (Java 8).

Writing that kind of optimized code is all about control and Java is all about abstracting it so you don't have to worry. As you see, both goals are at odds.

So I still prefer working low latency in C as it is more natural, native solution for managing problem where you absolutely need to control memory layouts, preallocated object pools, NUMA, compilation of decision trees to machine code, prefetcher, etc.

I have about 10 years combined experience working with C and 15 years working with Java.

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

#358

Post by thangalin »

wankeler wrote: post #137
thangalin wrote: post #45

Earlier quoted context omitted.

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…

You’re coding safety critical systems and depending on severely non-deterministic tweaks to GC to get it to run right?! Where is this for? (Just so I can avoid it)

> You’re coding safety critical systems and depending on severely non-deterministic tweaks to GC to get it to run right?!

That's certainly one way to look at over five years of engineering effort, extensive systems testing, countless hours of automated regression test development, independent product quality verification, rigorous code reviews, risk assessment processes, mandatory four 9s call quality requirements, integration analysis of JVMs with deterministic GC, and so on.

Judge not a galaxy from a single star.

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

#359

Post by news_to_me »

lmilcin wrote: post #357

Let me put my perspective on this. As it happens, I have developed one algorithmic, low latency trading system in Common Lisp / ANSI C, and then was asked to rewrite it in Java which I did. It actually traded on Warsaw Stock Exchange and was certified by WSE and was connected directly to it (no intervening software). Yes, it is possible to do really low latency in Java. My experience is my optimized Java code is abou…

I'm curious, what role did Common Lisp play in the original version of your trading system?

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

#360

Post by thangalin »

blub wrote: post #94
thangalin wrote: post #45

Earlier quoted context omitted.

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…

It would be interesting to know what the trade-off for those tweaks was. Typically it's increased memory usage. Another relevant aspect is what happens when one hits GC pauses again. Will there be any tweaks left? Will they conflict with the previous ones? Using such high-level levers to fix performance problems in a specific component is great when it works, but when it doesn't you're out of options.

Another option is to use a JVM that offers hard real-time constraints to achieve guaranteed performance characteristics. Such JVMs are in use in the automotive and airline industries---JamaicaVM, for example, offers deterministic garbage collection.
Post reply on HN