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

361–370 of 483 posts

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

#361

Post by opportune »

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.

They mention not even using most of the Java features (exceptions, built in GC) that make it safe. So I think it's a pretty fair question, since they are essentially using a very stripped down version of the language that removes most of the compelling reasons to use it, and seemingly fighting the language runtime along the way.

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

#362

Post by [deleted] »

lmilcin wrote: post #357

Let me put my perspective on this. As it happens, I have developed one algorithmic, low latency trading system in Common Lisp / ANSI C, and then was asked to rewrite it in Java which I did. It actually traded on Warsaw Stock Exchange and was certified by WSE and was connected directly to it (no intervening software). Yes, it is possible to do really low latency in Java. My experience is my optimized Java code is abou…

[deleted]

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

#363

Post by lmilcin »

news_to_me wrote: post #359
lmilcin wrote: post #357

Let me put my perspective on this. As it happens, I have developed one algorithmic, low latency trading system in Common Lisp / ANSI C, and then was asked to rewrite it in Java which I did. It actually traded on Warsaw Stock Exchange and was certified by WSE and was connected directly to it (no intervening software). Yes, it is possible to do really low latency in Java. My experience is my optimized Java code is abou…

I'm curious, what role did Common Lisp play in the original version of your trading system?

Common Lisp was doing all the "high level" stuff. No CL code was on the actual critical path but it still was responsible for some critical things that would be difficult otherwise.

For example, I had piece of Common Lisp code optimize and compile decision trees to machine code. These were used, for example, to check whether the trade is allowed to go to market. This had to be very optimized as it was running in parallel to constructing the message and had to deliver verdict before the message was actually created to have a chance at actually stopping anything from reaching exchange. This was my solution to have order verification in essentially zero time (the cost was single branch instruction that would only be mispredicted if the verdict was to stop the order).

Another piece of Common Lisp generated machine code to parse XDP messages coming from exchange. The spec for these was in XML, Common Lisp macros created extremely optimized machine code that used absolute minimum instructions to parse out the information we were interested in without having to write all that code manually. I actually used concept from Practical Common Lisp book for this (http://www.gigamonkeys.com/book/practical-parsing-binary-fil...). Thanks, Peter Seibel.

The entire application was essentially a Common Lisp application that used FFI to call a library with optimized ANSI C code. Some Common Lisp code was running in parallel to constantly update things like decision trees that required regular recompiling based on market situation but most was really just to setup everything and give control to the C part.

The application did not talk to operating system (Linux) after it started (no syscalls at all) and used full kernel bypass to talk to NIC.

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

#364

Post by opportune »

arthurcolle wrote: post #60
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…

I thought the actual approach taken these days is to disable GC for any JVM based trading systems and use arena based architectures or similar for application where you need super low latency, like a LOB mirror or execution engine, no?

What is an arena based architecture? A quick google didn't show any results. My assumption is that you mean pre-allocating all the memory you want to use at once, but I'm not sure and I'm curious.

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

#365

Post by SlipperySlope »

Java code can be written to run without any garbage collection. The code is not much faster, but there are no GC pauses whatsoever.

The app creates pools of the required objects and reuses them as needed. Certain java constructs create objects and they can be avoided. For example;

for (final String myString : myStrings) {...}

... creates an iterator over myStrings. It can be recoded as

final int myStrings_size() = myStrings.size(); for (int i=0;i A java profiler will show where objects are created and that code can be rewritten.

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

#366

Post by astral303 »

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.

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.

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

#367

Post by mhh__ »

beagle3 wrote: post #143
mhh__ wrote: post #34

Earlier quoted context omitted.

For that reason I generally motivate not using python to people on grounds of correctness rather than performance as per se. I can't be bothered to explain how compiler optimizations work so I usually just resort to "it's magic" when it comes to performance. Going from a statically typed language to using python to do number crunching genuinely makes me want to vomit. I don't understand how people convince themselves…

Take a look at Nim if you haven't already - It has a Pythonesque syntax, but strong static typing with extensive user control of semantics you seem to care about; e.g. floats and ints do not convert automatically unless you explicitly "import lenientops"[0] ; You can define 'operational transform' optimizations (such as: c b converts to multiply_accumulate(c,a,b) - which is a big performance difference for e.g matric…

I am involved with the foundation that runs the D programming language so I've found my home.

Other than syntax obviously.

FFI: Can nim use a C++ class and vtables? D does it all the time, nearly every language proclaims to have the best C++ interop but only D seems to be actually able to do it. Templates, classes, structs, and more all work.

We also have Mir, which I haven't benchmarked for a while but was faster than OpenBLAS and Eugene a few years ago and was recently shown to be faster than numpy (the c bits) on the forum.

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

#369

Post by dkersten »

This seems to not really be about Java and more be that C++ is complex and error prone. If you reframe it as "C++ may not be the best choice for high speed trading systems" instead, then you can evaluate other languages, like Rust, or Erlang, or OCaml, or any of the newfangled C++ "replacements" like Zig.

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

#370

Post by tayistay »

nv-vn wrote: post #288
TomSwirly wrote: post #186

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…

> High speed trading has no societal value And investment banking does? >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. Tell me this, what is the actual harm of these orders?

> And investment banking does?

Whataboutism.

Post reply on HN