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

181–190 of 483 posts

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

#181

Post by scatters »

bboygravity wrote: post #150
scatters wrote: post #124

Earlier quoted context omitted.

I don't know about java, but when using c++ you can use the OS to start the program, set up the hardware mappings and then move it to an isolated core where you talk to the hardware directly without ever issuing a system call. Compilers already offer flags to optimize for specific processor generations (and use the newly available instructions); you aren't going to be able to do better than that with a custom compile…

Oh, that's cool. However, you'd still be sharing at least 1 core (and all peripheral hardware and memory access in the system) with the OS. A core, other hardware and memory that you could otherwise access directly from your application without having to wait for the OS to finish its business? I'm not sure whether it's worth it to go through this trouble (writing for bare metal vs just using an off-the-shelve OS) in…

Accessing other hardware isn't latency-sensitive, though; that's usually disk and the internal network, for logging, telemetry and control. Typically a trading application will keep a thread running on the shared core and send messages between that and its dedicated core thread using lock-free queues, or simple atomics. As you say, writing for bare metal is a lot of hassle and it's unnecessary for the parts of a trading application that don't need to be super fast; using a commodity OS and isolating resources gives the best of both worlds.

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

#182

Post by knuthsat »

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 features to do so.

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

#183

Post by DrBazza »

cies wrote: post #118
roca wrote: post #4

So they want super efficient but safe code ... sounds like Rust.

Does anyone know of Rust in HTF teams? I think Haskell and OCaml may also be a good fit (and I know for a fact those are used in HFT teams).

From job ads I saw a year ago, there's at least one company in London doing HFT Rust.

Also, if memory serves, one of Lawrey's ex-colleagues has written his own version of Chronicle in D that's being used somewhere too.

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

#185

Post by epage »

Geminidog wrote: post #127
bra-ket wrote: post #61

C++ is a fantastic language but it somehow attracts people with big ego. The smartest people I know would always try to simplify things, but many C++ developers (especially in financial industry) have this preference for complexity I can't explain. And C++ is the worst language to get clever with.

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…

I worked at a large C++ shop (the kind that maintains a stdlib fork) and never saw them looking down at Python.

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

#186

Post by TomSwirly »

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.

Market makers are the ones who provide consistent liquidity, because they have to keep inventory of the stocks.

Now look at what HFT does - they flood the wires with hugely out-of-the-money bids and asks, all of which are in bad faith, because they know they won't even get hit or lifted.

So everyone else pays for this, and they get to shake absolutely everyone down for a few pennies, a trillion times a year.

---

It would be trivial to stop them without changing the markets in the least. Even just charging a dollar for every "bad faith" bid or offer made that expires without being within, say, 10% of the actual price, would put a big dent in them. Punitive taxes on trades where the trader doesn't keep the position for more than a few seconds would also be very effective.

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

#187

Post by DrBazza »

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 file. No GC. When taking market data off the wire, or sending messages around a system, that is competitive with C++ and certainly has a fast time to market, and lower defect rate.

The other thing people are conflating is high frequency part: get the market data and... do a complex calculation as fast as possible, and place or pull an order. Placing or pulling orders can be further optimized too.

The fast complex calculation part is where Java isn't as competitive and you run into the GC unless you use object pooling, warming up the JVM and so on. We had a 50-50 system of Java for the bulk of the system, and C++ for the complex algorithms where we mark hot paths and check the assembly on godbolt (thank you Matt Godbolt).

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

#188

Post by paganel »

mnw21cam wrote: post #151
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…

I'm primarily a Java programmer, but I had a go at learning Python a little while ago. I couldn't stand it - it just seemed so sloppy and poorly-defined. I don't consider myself as being superior to Python devs or having an astronomical ego, but Python-hate? Yeah.

I got myself my first job as a Python programmer 15 years ago by (among other things) mentioning this blog entry: "Python Is Not Java" [1]

[1] https://dirtsimple.org/2004/12/python-is-not-java.html

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

#189

Post by mcqueenjordan »

chrisseaton wrote: post #139
blackrock wrote: post #133

Earlier quoted context omitted.

Why not just write it in C? And pre-allocate all the data structures, make them global, put them into a queue, and constantly reuse them. No more need to instantiate objects.

Why not just write it in assembly while you’re at it? The answer to both questions is that many people prefer writing in higher-level languages with more safety guarantees.

This is a bit of a false equivalency -- there aren't many perf benefits in rewriting a C program in asm. The cost you pay for that rewrite is also much greater.

Yes, of course $HIGH_LEVEL_LANG is preferable for many many use cases. In this context, we're discussing "high speed trading systems", for which native implementations are going to be the favorite.

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

#190

Post by aljarry »

littlecranky67 wrote: post #68
brundolf wrote: post #38

Hearing them describe this "C-like Java", I'm surprised C# wasn't a better fit given that it has value-type "structs" that don't have to sit behind a reference on the heap. As far as I know, Java still doesn't have an equivalent feature. Maybe the JVM's GC is just so much faster that it's worth it?

Am also wondering (I have no experience on that matter) how .NET performs in terms of GC as I remember at some point they introduced a threaded GC that dropped the stop-the-world approach and perform garbage collection in dedicated threads. Anyone got some insights?

If you're using "background GC" (new default), they are doing GC in multiple steps, by running part of GC work in another thread - there are still parts which require suspension of managed threads. Here's some more insight:

https://devblogs.microsoft.com/premier-developer/understandi...

Post reply on HN