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

321–330 of 483 posts

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

#321

Post by firethief »

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.

If software developers aren't engineers, why are we judging this person's engineering? I think this case is an argument that software developers are engineers, even when their employer fails to see it that way

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

#322

Post by hnracer »

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

It depends on what the edge is. Presumably you're competing for a sub 3us edge but they're not all like that. For slower edges Java might be a better idea.

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

#323

Post by zanellato19 »

Karellen wrote: post #269
zanellato19 wrote: post #195

Earlier quoted context omitted.

Given the same conditions (i.e. people don't die) the same outcome would present itself. We have a history of bridges falling down, so much so that Wikipedia has a list on that: https://en.wikipedia.org/wiki/List_of_bridge_failures A particular one that caught my eye: Cimarron River Rail Crossing Dover, Oklahoma Territory United States 18 September 1906 Wooden railroad trestle Washed out under pressure from debris du…

The point isn't that bridges never fall down. The point is that engineers who build bridges know that it's their responsibility to do everything in their power to make sure it doesn't, even if no-one else around them seems to care about that, or specifically asked for it. That they should walk away from a project rather than sign off on one where they will not have the resources or support to do a competent job. That…

> The point isn't that bridges never fall down. The point is that engineers who build bridges know that it's their responsibility to do everything in their power to make sure it doesn't, even if no-one else around them seems to care about that, or specifically asked for it. That they should walk away from a project rather than sign off on one where they will not have the resources or support to do a competent job.

The law takes care of that though. The law and inspection. If it was up to the business, any engineers building bridges who would refuse to project it faster because of that would be fired.

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

#324

Post by PaulDavisThe1st »

tdons wrote: post #21
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++.

An iron man is a triathlon, you are looking for steelman! https://en.wiktionary.org/wiki/steelman

There is (was?) a Steelman triathlon too (actually, more than one of them, in different parts of the US).

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

#325

Post by karussell »

We developed the high-speed routing engine GraphHopper in Java and have never regretted it (think Google Maps not network routers :)). Although I'm unsure if I would have used it for a trading systems as every GC hiccup can be problematic and for our use case GC hiccups need only to be under 10ms.

But still the topic ("trading system" or in our case "routing engine") is already very complicated due to the involved algorithms and C++ likely makes it a bigger challenge also regarding attracting good developers.

The memory waste in Java is the biggest challenge that you have to solve. Usually you solve this via primitive arrays i.e. do not use List but int[] x and y and before this gets complicated wrap this in an iterator or other thin Object (flyweight pattern?). And today you can use advanced GCs like ZGC or Shenandoah that work well also for >100GB of RAM and you can heavily reduce hiccups. And you need to be aware of some smaller pitfalls e.g. foreach loop or Java streaming API might be slower than the raw loop. But you should never follow rules or trust a "guru" and only use your performance tests to guide development :)

And in non-performance critical sections (70% of the code?) you just do not care and can program "idiomatic Java". Also do not underestimate the crazy work that a modern JIT can do for you.

And now after years of work we are for several aspects better or same memory-wise and speed-wise compared to other open source C++ routing engines. And the interesting thing is that IMO this is because of the tooling and habits (like rigorous testing) which reduces bugs and debugging sessions and slowly shifts your focus from language problems to the actual domain problems. But of course all very subjective.

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

#326

Post by sorokod »

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.

There may be reasons for not calling software developers engineers but this is not one of them. The software "bridge" in this case has the following properties:

1. It can be rebuilt in a matter of hours by a single person.

2. The customers that ordered the bridge are also the people on the bridge and are totally fine with the bridge crashing on them from time to time.

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

#327

Post by masklinn »

bluGill wrote: post #201
masklinn wrote: post #177

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?

Remember back in cs101 where you had class animal, with subclasses dog and cat. You can call speak() on animal and get either ruff or meow depending on what animal is. Animal is a virtual object. The system needs to do some work to figure out which speak to call every time, the work isn't too bad, but it turns out that cpus basically never have the right thing in the cache, so it ends up being very slow compared to m…

Please don't take others for complete morons.

And that makes literally no sense in-context, you're mapping those words directly to the concept of virtual methods but that's the opposite of the way chrisseaton uses them (and they're clearly familiar with the concept of virtual calls and it's not what they're using "virtual" for), hence asking them what they mean specifically by this terminology.

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

#328

Post by fefe23 »

This reads like what they actually mean is "I don't think we could rewrite this in C++".

That is a common sentiment. So much work went into this! We don't understand how we got here in the first place. It's so big! Look at all this legacy code and technical debt! There is no way we or anybody else could rewrite this in Java let alone C++ in any useful time frame! We sunk decades of work into this monstrosity!!

The text boils down to a "time to market" argument. I find that surprising because you'd think for high speed trading correctness is more important than time to market.

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

#329

Post by dnautics »

derefr wrote: post #274
Karellen wrote: post #193

Earlier quoted context omitted.

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

I think it’s not that software engineers aren’t engineers; but more that they’re most equivalent to combat engineers — engineers operating under time-pressure and shipping-pressure, where the systems they build need to “work” (in the sense of a bridge getting people across a ravine) but may only need to work once ; and where it may be perfectly fine/expected/required to need to “baby” the resulting engineered system…

you mean they're more like train engineers, or maybe to be charitable, like geordi laforge engineers, someone who runs an engine.

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

#330

Post by b20000 »

DrBazza wrote: post #312
b20000 wrote: post #307

Earlier quoted context omitted.

I was an intern in a startup years ago where they had a product that was a mix of java and C++. the company went bankrupt on that decision. there was only one engineer who understood the java/C/C++ interface at the time and that interface was responsible for all the bugs and performance problems.

Well this was the reverse of a startup - an established company that had a working system, historically in Java, and then added a mixture of C++ processes, and Java-C++ interop libraries to improve performance. Picking two significant languages as a start up is a bold choice. Measurement and QA is everything in terms of performance.

I don't think that matters. It all stands or falls on whether you have people that are capable of bridging both worlds correctly, and those people are rare, and I see no advantage to using java. So why bother? Just hire good C++ developers and you don't need to go find the ultra rare masterminds who can bridge both worlds. The time to market argument is debatable as there are an enormous number of libraries for C and C++ available and a lot of language features have been added to recent standards to address this issue. I also think that one of the key problems with java is that it forces the OOP paradigm on the user.
Post reply on HN