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

461–470 of 483 posts

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

#461

Post by lmilcin »

RobLach wrote: post #446
stingraycharles wrote: post #397

Earlier quoted context omitted.

Probably the usual suspect, it’s easier to find engineers that know Java than C/C++.

And it’s a foolish assessment. Finding Java programmers who can navigate all the hoops of low latency Java is more difficult than finding a C programmer who can do the same with C.

There is couple of reasons for this.

If you choose Java for your project it usually means you don't care a lot about latency and performance (you care some, but not all that much compared to, for example, linux kernel development). You care more about managing larger codebase, having easy access to whole lot of frameworks and libraries, good development tools and easy development / deployment process.

Developers who have experience with Java are inevitably people who have mostly had experience with those kinds of projects of which I would say most are corporate backend systems or Android applications. It really is difficult to find any other projects.

On the other C is inflicted pain of having much harder development environment for the size of the project. You only use low level language like C when you have a specific need. Maybe you need to develop Set Top Box software, or video codec, or some device controller, or high performance quant library, that kind of stuff.

So it isn't really fault of Java developers to not know the stuff. It is natural result of Java being suited to a different type of projects than C is.

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

#462

Post by lmilcin »

KMag wrote: post #442
lmilcin wrote: post #431

Earlier quoted context omitted.

That is exactly what I did. It was much less elegant and performant, though, than my initial solution with Common Lisp and C which basically allocated buffers in memory and mapped them with huge pages so that memory access don't ever require switch to kernel for mapping. We also had custom Intel CPUs that are auctioned individually. And cutthrough switches that stream the IP packet immediately when they receive the I…

> would be delayed by less than a meter That's just latency to your NIC, right? 1 meter ~ 3 ns ~ 9 CPU cycles at 3 GHz, less than the integer pipeline depth last I checked.

Latency through switch (ie. how much the switch added compared to if the signal traveled unimpeded in vacuum).

Decade ago.

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

#463

Post by shitgoose »

angry_octet wrote: post #75
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…

The worst (messiest, laziest and most chaotic) engineer I know works at a brokerage, coding obscenely large and unreliable edifices (and in a number of languages, from C++ to Excel+VB)... He does what he is asked, and doesn't worry about telling them what they need. They never demand code that doesn't crash, they see that as a fact of life, and developers are an overhead. Basically someone else owns the risk, the bro…

I know exactly the type of guys you are talking about. They write tools for traders, a mix of Excel, VB, .Net, you name it. They are not obsessed with architectural beauty, patterns and frameworks. They just write what users ask them (and they do not tell traders what traders need - the response will be swift and insulting). The traders take these tools and generate profit. And they do not give a shit about test coverage or not sound architecture principles. If software generates profit, then it works.

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

#464

Post by iamcreasy »

knuthsat wrote: post #453
iamcreasy wrote: post #432

Earlier quoted context omitted.

But you still have to make the next and hasNext calls in a for loop. What guarantees that they would be inline in a for loop?

I inline them manually.

How much was the performance improvement?

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

#465

Post by astral303 »

criddell wrote: post #374
astral303 wrote: post #366

Earlier quoted context omitted.

The Bridge analogy is often applied with flaws. Bridges are not free to build. Software essentially is. Here is a 1992 truth bomb rewind about it: https://www.developerdotstar.com/printable/mag/articles/reev... Basically engineers care about the quality of the code because they know that is the design. As soon as caring about codebase quality leaves the building, so will the quality of the product.

A civil engineer will put their stamp on the design of a bridge certifying that it will not fail. If it does fail, they will be held responsible and may lose their license to practice. Software engineers often hide behind a contract saying they aren't responsible for anything.

Software engineers are held responsible to plenty of things (HIPAA) when there is a will to do so.

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

#466

Post by knuthsat »

iamcreasy wrote: post #464
knuthsat wrote: post #453

Earlier quoted context omitted.

I inline them manually.

How much was the performance improvement?

The biggest improvement I measured was about 15x. I'd say you can get 3x most of the time (go down to 33% of previous runtime).

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

#467

Post by iamcreasy »

knuthsat wrote: post #466
iamcreasy wrote: post #464

Earlier quoted context omitted.

How much was the performance improvement?

The biggest improvement I measured was about 15x. I'd say you can get 3x most of the time (go down to 33% of previous runtime).

That is insane speedup! Thanks for sharing. How do I find next and hasNext is the bottleneck? Should I run profiler to see if they are being called a large number of times?

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

#468

Post by knuthsat »

iamcreasy wrote: post #467
knuthsat wrote: post #466

Earlier quoted context omitted.

The biggest improvement I measured was about 15x. I'd say you can get 3x most of the time (go down to 33% of previous runtime).

That is insane speedup! Thanks for sharing. How do I find next and hasNext is the bottleneck? Should I run profiler to see if they are being called a large number of times?

Unfortunately, any profiler I tried does not show these issues. Because the code you are profiling will be optimized completely differently. Although it makes sense to do the optimizations/inlining inside the top-level functions that profiler reports to take a lot of time (even if the iteration happens in deeper levels).

You just have to try it and see. I remember it was quite easy in IntelliJ, I believe there's an option to inline all invocations of a function. I just went crazy with that option but did it systematically to really find where the bottleneck is and make a minimal change.

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

#469

Post by maccard »

simonh wrote: post #421
maccard wrote: post #406

Earlier quoted context omitted.

You don't need to predict in advance, you just need the capability in the system. If a system takes X time from the beginning of a trade to being ready to process the next trade, with Y of that time being GC, it doesn't matter how long Y is if you can execute the entire trade before all of the GC happens.

I used to support a derivatives trading system at a company called Patsystems, so I’ve seen this. Our legacy system could process trade triggers from 4ms to 7ms, but tracing the behaviour of the new system it could do it in 3ms, great. Except every now and then a GC pause would halt order processing for around 50ms. Our customers hit the roof. Trading systems trigger almost all their orders based on detecting market…

(Sorry, I missed this over the weekend) - I think the issue in this case is you're selling this as a guaranteed 3ms, going down from 4-7ms. If you have to pause for this 50ms GC once every X trades, then you force the GC to happen _after_ the X-1th trade has completed, but you need to provision an extra 15(?) machines to cover the pause. Otherwise, you're not delivering 3ms trades, you're delivering (3 + GCTime/X) ms. It doesn't matter if GC takes 1ms or 1s, you "simply" need to have the capacity to cover the extra GC time.

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

#470

Post by peter_lawrey »

lmilcin wrote: post #388
DC-3 wrote: post #384

Earlier quoted context omitted.

So Java is nearly as low-latency as C if you're willing to write your Java as if it were C?

It can be done. It is just not very practical, you are better off writing C. The only situation I can think of where Java would be right fit is where you have an application with a lot of logic and just a small part that needs to be highly optimized.

Most trading systems I work on only need a very small portion to be highly optimised. As long as most of the code is pretty efficient that is fine.
Post reply on HN