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

401–410 of 483 posts

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

#401

Post by lmilcin »

vbezhenar wrote: post #387
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…

Sounds like it should be possible to wrap it all into some kind of library and set of guidelines. On a positive side you probably could have much more confidence in Java code, because lots of boring and hard to debug memory errors just not possible (but may be C professionals don't do those errors?).

The cost of environment not making it possible for you to make a mistake is always there, somewhere.

I think best hypothetical development environment would allow you to specify the tradeoff and choose whether you want strong typing, fully managed memory or ownership semantics.

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

#402

Post by Rebelgecko »

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…

One interesting approach I heard about for doing garbage collection in finance is to get computers with a shitload of RAM and just turn off GC. At the end of the trading day you can reclaim memory by killing the process. Not sure how common that strategy is.

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

#403

Post by jandrewrogers »

aldanor wrote: post #382
jandrewrogers wrote: post #313

Earlier quoted context omitted.

Rust improves on Java in that it doesn't have a GC, so no pauses, and the code gen is similar to C++ in terms of performance. Rust is worse than C++ in that it struggles to express some idiomatic high-performance code architectures, such as using DMA for I/O, because they violate axioms of Rust's memory safety model, or in other cases because Rust currently lacks the language features. To make it work in Rust require…

Hm... unsafe {} + use pointers and you're back to c++-style? You've had unsound code in one language, now you have unsound code in other language, how come it's suddenly worse other than having to type unsafe explicitly? I've done my fair share of C++, including low latency stuff, and in the grand scheme of things I'd say "expressiveness of C++" is completely overshadowed by its complexity and occasional ambiguity, l…

The issue, beyond having no visible references at compile-time, is that DMA has no concept of objects and has its own rules for how and when it interacts with regions of memory. It is oblivious to ownership semantics. In things like databases, most of your address space is DMA-able memory and therefore "unsafe". In C++, you can completely hide these mechanics behind constructs that look like unique_ptr/shared_ptr but which are guaranteed to be DMA-safe. In this context, all references are treated as mutable because mutability is not a property of references per se. Conflicts can only be resolved at runtime.

Instead of using an ownership-based memory safety model, which is clearly broken for systems that use DMA, they can use schedule-based memory safety models, which are formally verifiable. These don't rely on immutable references for safety, and also eliminate most need for locking -- many of the concepts originate in research on automated lock-graph conflict resolution in databases. The evolution away from ownership-based to schedule-based models is evident in database kernels over the decades. It was originally motivated by improved concurrency; suitability for later DMA-based designs was a happy accident and C++ allows it to be expressed idiomatically.

As for expressiveness, beyond the ability construct alternative safety models, modern C++ metaprogramming facilities enable not only compile-time optimization but also verification of code correctness that would be impractical in languages like Rust.

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

#404

Post by gbronner »

Rebelgecko wrote: post #402
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…

One interesting approach I heard about for doing garbage collection in finance is to get computers with a shitload of RAM and just turn off GC. At the end of the trading day you can reclaim memory by killing the process. Not sure how common that strategy is.

It works until it doesn't and you lose a ton of money

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

#405

Post by invaders78 »

Why not Fortran? Genuinely curious. It is more difficult to shoot yourself in the foot in Fortran than in C. The perils of garbage collector is missing from Fortran. The syntax is clean. Performance is as good as and sometimes even better than C and most definitely better than Java.

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

#406

Post by maccard »

simonh wrote: post #400
maccard wrote: post #209

Earlier quoted context omitted.

But a pause that can happen when you want it is acceptable. A 3 second stall might be totally acceptable as long as it happens outside of a trade, and you can guarantee that.

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.

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

#407

Post by iphorde »

I have a number of patents revolving around this specific issue, and I can tell you certainly this guy has no idea what he is talking about.

First, let me preface this, the language does matter, but the larger complications revolve around the operating system. Most transactions have a hard real-time deadline of 20ms or less. JVM creates additional issues on top of what are already present from the OS. If you're on Linux, a real-time kernel is required to handle these transactions.

For Windows, there are asynchronous methods you achieve this functionality, it is possible, but very difficult to do.

After reviewing this guys LinkedIn profile, all he has ever done is Java. He is a Java advocate. I think Java is great language, but this is one place it doesn't belong.

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

#408

Post by the_only_law »

invaders78 wrote: post #405

Why not Fortran? Genuinely curious. It is more difficult to shoot yourself in the foot in Fortran than in C. The perils of garbage collector is missing from Fortran. The syntax is clean. Performance is as good as and sometimes even better than C and most definitely better than Java.

Probably because it’s not sufficiently C like to meet the threshold for adoption.

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

#409

Post by pjmlp »

secondcoming wrote: post #166
thangalin wrote: post #45

Earlier quoted context omitted.

Currently developing a radio communications system using Java, with JNI calls for hardware integration, running on a quad-core 32-bit ARM processor. We have constraints of around 20ms for real-time audio packet processing. Recently some stop-the-world pauses introduced by the GC resulted in calls dropping. A few GC parameter tweaks brought our latency below 20ms and the application no longer drops calls. This is usin…

> real-time, safety-critical operations Doesn't Java itself say it shouldn't be used for anything like this?

Nope, there are even two vendors specialized in real-time Java based solutions.

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

#410

Post by iphorde »

DC-3 wrote: post #384
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…

So Java is nearly as low-latency as C if you're willing to write your Java as if it were C?

No. Java is not low-latency by any stretch. Java advocates would like to think it is, until a Bank, like BoA spends $8 million on Java in 2014, just to have it fail compliance testing. Entire project was scrapped.
Post reply on HN