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

421–430 of 483 posts

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

#421

Post by simonh »

maccard wrote: post #406
simonh wrote: post #400

Earlier quoted context omitted.

If you can predict 3 seconds in advance if you’re going to need to trade or not, you’d make millions very quickly. In trading terms, that’s basically having a time machine.

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 changes, which you cannot predict. If a symbol hits a price that triggers one of your trades you want that trade in the market ASAP every millisecond matters. Randomly add 50ms on to that and your trading system is out of business. The customers will go elsewhere.

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

#422

Post by knuthsat »

iamcreasy wrote: post #352
knuthsat wrote: post #182

Earlier quoted context omitted.

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.

Let's say you write an Iterable class so that you can use foreach on your data structure. It's quite possible iteration won't be completely inlined and the overhead of calling hasNext & next can become non-significant.

An even worse case that made massive speedups is just inlining everything. I believe modern IDEs can automatically inline all invocations of a function. You'd be surprised how much performance you can get with that.

As for writing efficient Java, it comes down to using primitive and value types.

Although, my experience is mostly with Java 8. I have no idea how streams or other new syntax works. After optimizing a really massive Java code base I've never used it since.

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

#423

Post by acqq »

pjmlp wrote: post #417
acqq wrote: post #263

Earlier quoted context omitted.

To those who miss the point, nobody is here denying that C++ has something to bring, it's just that what it brings isn't what those who promote some fashion would claim that is to be universally used, and, honestly, there's no actual reason to believe such claims, for they being not more true now than at the times where "making complex OOP hierarchies" was the most popular advice -- I remember these times too. Or the…

I guess this is for you, in case you haven't seen it already, "Orthodox C++" https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b

Haven't seen, but thanks. Lived and worked while following some of the ideas mentioned.

E.g. at the whole bottom of the page in some comment is a link to:

"Why should I have written ZeroMQ in C, not C++ (part II)"

https://250bpm.com/blog:8/

where the author writes "Let's compare how a C++ programmer would implement a list of objects..." and then "The real reason why any C++ programmer won't design the list in the C way is that the design breaks the encapsulation principle" etc.

I have indeed more than once used intrusive data structures in non-trivial C++ code, and the result was easy to read, and very efficient. There I really didn't care about some "thou shalt not" "breaking the encapsulation principle" because whoever thinks at that level of "verbot" 100% of times is just wrong.

The "encapsulation principle" is an OK principle for some levels of abstraction, but nobody says that one has to hold to it religiously (exactly my point before). I would of course always make an API which would hide what's behind it. But where I implement something ("the guts" of something), I of course have my freedom to use intrusive elements, if that solves the problem better. I have even created some "extremely intrusive" stuff (with a variable number of intrusive links in the structures). It worked perfectly. Insisting on doing anything as "ritual" all the time is just so, so wrong.

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

#424

Post by dmz73 »

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…

It is difficult to compare software development with civil engineering as they operate on different levels. Software development is better compared to building houses. No one expects single story house to support 4 extra levels or for internal walls to be resistant to hammer blows. Imagine what civil engineering would produce if you were building a bridge from a to b and then 3/4 way through you were required to add two extra exits c and d that were miles apart from a and b and another 4 lanes and extra level for train traffic...all in the same time frame and for no extra cost. Civil engineers would not be able to do it and no-one would even expect them to but this is regular occurrence for software developers and most of them actually manage to deliver. Sure there are bugs but bridges need constant maintenance too, some quite substantial and that is expected. For some reason, lots of non-software engineers expect software to be perfect when their own products are not, not even close.

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

#425

Post by angry_octet »

MaxBarraclough wrote: post #292
fsflyer wrote: post #281

Earlier quoted context omitted.

There seems to be plenty of software issues found: The MCAS software was modified to read from both angle of attack sensors and to be less aggressive in pushing the nose of the plane down. The software that controlled the indicator light that illuminated when the two angle of attack sensors disagreed was also fixed. While reviewing the software systems, a number of other software issues were found. The wiring bundle…

I phrased that poorly, I should have said The 737 Max issues that caused the crashes were not with the software implementation . They were at the level of requirements and high-level design, and were not specific to the discipline of software engineering. We're not talking about a missing break statement here. > The MCAS software was modified to read from both angle of attack sensors and to be less aggressive in push…

Exactly. People seem to have skipped the V&V lectures. The code did exactly what it was asked to do. But the system/aero engineers made that decision. Even the lights issue was specified that way in the system diagram.

But the biggest defect was the decision that the pilots didn't have to be told about the risk (to avoid retraining and certification costs). If they had been told the pilots/airlines may well have protested about the lack of redundancy. All those higher ups in Boeing and the FAA should be in prison.

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

#426

Post by ncmncm »

Hi-speed trading is a zero-sum game, like poker. Every single gain is somebody's loss. Either you rip the other guy's heart out and eat it, or he rips your heart out and eats yours. There is no other choice.

Choosing Java over C++ is choosing to be that second guy.

Sure, Java coders are cheaper and easier to hire, and they produce lots more code. But if lots of code is a liability, lots of Java code is a bigger liability.

A trading house with a lot of Java code is a red warning.

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

#427

Post by MrDresden »

Karellen wrote: post #193
angry_octet wrote: post #75

Earlier quoted context omitted.

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…

^^This^^ is why you shouldn't call software developers "engineers" (disclaimer, am software developer). "No-one ever explicitly specified that the bridge shouldn't fall down and kill everyone who was on it at the time", said no engineer, ever.

Except those who go through university level software engineering or computer science degrees

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

#429

Post by gbronner »

He doesn't define high speed or better. If you turn off gc and use pool based allocators, you can build a reasonably fast general purpose trading engine that can connect to lots of exchanges, use lots of apis etc. It will be fast enough for algo trading, but will never be fast enough for market making / hf / colo stuff.

You can never get around the boxing/unboxing, the larger sized objects, jvm inefficiencies, lack of direct access to assembly, etc.

But the cost of building a super low latency setup, and then doing anything useful with it is much higher than doing it with Java/c#

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

#430

Post by vgatherps »

vmception wrote: post #251
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…

VHDL is faster no? Isn’t everything you wrote from the wrong decade?

Fpgas have a huge amount of operational and practical difficulties. They’re great for fixed-function stuff like feed parsing or dumb triggers your software can direct in real-time, but absolutely terrible for something where you the ability to be flexible and adaptive.

Pure latency arb isn’t the only hft trade there is anyways.

Post reply on HN