Live data from Hacker News

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

news.efinancialcareers.com

301–310 of 483 posts

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

#301

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

The question is how much of your remaining tick-to-trade is really in the software loop. Realistically at the bleeding edge more and more logic is going into FPGA (and maybe ASIC t some extent). Your software is primarily there to make sure that you've processed the previous tick and re-configured the FPGA rather than actually competing in tick to trade. Given that's the case the software doesn't need to be the faste…

+1, that's how things typically work these days. Note that "processing previous tick" may take a very-very long time (up to fractions of a millisecond) to execute, in which case you still want that part to be as fast as possible.

(Source: hft quant)

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

#302

High speed trading systems, what a stupid, useless, and artificial domain. You could shutdown all of this and nobody will care in all societies.

Why so many down votes? I agree with what he said. HFT is just a scam. Anybody remembers Flash sales? And there were consideration like digging tunnel from nyc to chicago due to small latency. HFT is just ran by powerful and rich people thats why the are still now. There are preety bad thing hft has done like Intensifying Volatility, Ripple Effects,Uncertainty, Stock Manipulation.

As a game HFT is interesting but in real life its just a plain scam. Yes you may have a job and you may work on HFT but that doesn't mean you have to give your heart and support it.

Disclaimer: I worked on HFT but I still don't like it and the money HFT generate is just insane.

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

#303

Earlier quoted context omitted.

You missed one comparison: C infra (no C++). (well strictly speaking, additionally you could also have hand-written assembly infra).

You can write C style code in C++ and still get access to features that are still interesting in the problem domain. constexpr functions, typesafe enums, static assertions, and destructors come to mind. No need to even touch a template or inheritance if you don't want to. The main benefits of C per se are ABI stability and availability of compilers.

[deleted]

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

#304

from another discipline, but similar rigor -- a FOSS community with both C++ and Java servers, serving high-requirements responses.. a sort of friendly "coopetition" contest around 2012.. many hands and eyes, certainly top-level engineering on both sides. The results were basically -- with the best teams, almost identical times; the obviously slowest entries were on the C++ side. Admitting bias now, I was surprised t…

How did they avoid GC penalty? Arena allocation and buffer reuse? Java is pretty good, I've used it for over 20 years, but it wastes memory for basic use cases, and yet GC pause limits the utilization of huge memory cases. Did anyone try Go? IMO Go tries to address the slowness of java startup and commands, but it punts GC/memory waste so the huge-memory systems are even worse.

the results that counted were "warm" responses

no one tried go-lang, the elaborate specialty code needed for the actual work did not exist

the Java probably did use pre-allocation and flat heirarchy a lot, but I do not know the details. Some Java did win by a significant margin, in very odd corner cases, probably due to simple code-coverage miss on the C++ side

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

#305
in other words: we invested a ton of money into building java infrastructure and to make it work well for this application and now we need to find ultra rare developers who will maintain it! those who do java don't bother with performance or low latency and those who do C++ don't bother with java. Problem! We need to convince everyone that java is better!

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

#307

The title of the article and the comments here are conflating several things. We had Peter Lawrey consult at one of my employers, and I've worked on both C++ and Java HFT systems. We used Chronicle as a high performance messaging system. The secret sauce is just memory mapped files, single threaded processes, and using Java objects as flyweights that just write to the end of the file, or are read from the end of the…

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.

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

#308

Ex-Wall Street guy here. High speed trading has no societal value and relies on a large number of bad-faith bids and offers - these people are parasites. Creating liquidity has some value - though not as much as bankers tell themselves. But HFT does not add liquidity. No one needs subsecond liquidity, but even more important, HFT traders vanish like a fart in a windstorm the moment liquidity is actually challenged. M…

I think your definition of HFT is very narrow. Many companies that use the term HFT are not involved in the type of activities described in The Big Short.

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

#309

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 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…

Enginners where not requested to make the Voyagers last a hundred years, yet they're still up and running. Personally I think the correlation between quality of code and time to delivery are not linear. People can cram more work and quality in the same ammount of time if they want and have the right incentives to do so.
Post reply on HN