Using Java In Low Latency Environments

twofishy writes "Something I've noticed amongst financial service companies in London is a growing use of Java in preference to C/C++ for exchange systems, High Frequency Trading and over low-latency work. InfoQ has a good written panel discussion with Peter Lawrey, Martin Thompson, Todd L. Montgomery and Andy Piper. From the article: 'Often the faster an algorithm can be put into the market, the more advantage it has. Many algorithms have a shelf life and quicker time to market is key in taking advantage of that. With the community around Java and the options available, it can definitely be a competitive advantage, as opposed to C or C++ where the options may not be as broad for the use case. Sometimes, though, pure low latency can rule out other concerns. I think currently, the difference in performance between Java and C++ is so close that it's not a black and white decision based solely on speed. Improvements in GC techniques, JIT optimizations, and managed runtimes have made traditional Java weaknesses with respect to performance into some very compelling strengths that are not easy to ignore.'"

memory monster

[Anonymous Coward]

You forgot to mention that Java programs don't even compare to C/C++ in terms of memory usage. Past 10 years didn't change that.

JAVA could be great if it lost weighrt.

[sg_oneill]

The chest beating about Java vs C is kinda sad. Look, I've spent the past 20 years hating java with the fire of a 1000 suns, but having been kinda forced to use it lately I've realised its actually not a bad language, in fact its quite neat and well thought out (But god help me, somehow its date handling is even more broken than javascript)

The problem is all the verbose cruft that goes with it. The giant overly complicated frameworks that require configuring 50 different XML files fed through a labrynith undocumented build process that allows you to write terse and insane pattern-madness code ....or alternatively just fire up JDBC and write a bloody SQL query instead.

I think JAVA could shine if people just threw out about 15 years of insane and overly complicated frameworks and took some tips from the python and perl people and replace them with some simple but effective libraries that do one thing and do it well.

But hey, at least its not bloody javascript!

Re:Huh?

[elfprince13]

Manual memory management is a whole class of bugs that Java doesn't have to deal with. A good C/C++ programmer shouldn't have *that* much difficulty, but it does add to debugging costs and detracts from mental focus on the algorithmic aspects of the problem.

Warm up is a big deal

[johndoe42]

I'm not a Java user, so I've never directly tuned for things like GC, nor do I interact with it directly. Warm up is a different story.

I interact with quite a few exchanges (over all kinds of protocols). Most are, unsurprisingly, written in Java. Almost all of them perform terribly at the beginning of the week. The issue is a standard one: the JVM hasn't JITted important code paths, and it won't until several thousand requests come in. For a standard throughput-oriented program, this doesn't matter -- the total time wasted running interpreted code is small. For a low-latency network service, it's a different story entirely: all of this wasted time happens exactly when it matters.

The standard fix seems to be to write apps to exercise their own critical paths at startup. This is *hard* when dealing with front-end code on the edge of the system you control. Even when it's easy, it's still something you have to do in Java that is entirely irrelevant in compiled languages.

If JVMs some day allow you to export a profile of what code is hot and re-import it at startup, this problem may be solved. Until then, low-latency programmers should weigh the faster development time of Java with the time spent trying to solve annoying problems like warm-up.

Re:Troll much, slashdot?

[mark-t]

This. I've actually personally witnessed a case where a java test application outperformed a (roughly) equivalent C++ application by a startling amount. The two applications were more of a benchmark program than a real app, since it was only testing the timing characteristics of allocating many thousands of objects on the heap, discarding some of them, allocating more, then discarding more, and so on.... The C++ version used the default new and delete operators, while the java version just used the normal new keyword and left the discarding of memory of old objects to the GC. The Java version outperformed the C++ version by more than a factor of 10. Altering the C++ version so that it used custom new and delete operators for the objects, pooling unused objects instead of always just returning them to the heap as the default delete operator did, the C++ version of the application sped up considerably, outperforming the Java version only slightly over a period of about one billion allocations. In consideration of this experience, I think that one is left with answering the question for themselves of whether spending the extra time to specifically optimize a C++ program is truly worth the marginally improved performance. Sometimes it might be... but sometimes it won't.

Re:Troll much, slashdot?

[serviscope_minor]

And you'll notice even on your linked counterexample there are 5/11 examples where Java is within the margin of error on CPU time.

Yeah and in the rest C++ is quite definitively faster. In other words as I claimed, C++ is either the fastest or within a small percentage, across the board. There are precious few examples where C or C++ is substantially outperformed by another language (and in almost all of those precious few examples, it's Fortran) and plenty of examples against just about any other languages where it is a clear winner.

Take the time to go back and read the link I posted. "Java vs C" goes back and forth depending on the algorithm in question and the cache characteristics of the target platform.

I did though the one I posted has much more recent results and no dead links. All the benchmarks are similar. In some cases C++ is slightly otuperformed by Java, in other cases C++ substantially outperforms Java.

Mostly it doesn't matter.

But when people routinely benchmark against Java rather than C++, then I'll accept Java as the faster language.

Re:Uh , since around 1998?

[phantomfive]

All that is nice theory, but in practice C still runs faster, for various reasons. The problem you have is that you're only looking at facts that support your position. That is the problem with the world.

Consider that every single array access in Java is checked, for starters.

Re:Huh?

[smcdow]

The article suggest that one solution is to simply not do GC until the end of the trading day. I have to admit that's a good pragmatic solution, certainly so for HF prop traders.

Not enough memory on your servers? Add more. Still not enough? Add even more. The cost would be a pittance for any prop trading company worth its salt.

Re:memory monster

[Anonymous Coward]

I work in the finance industry in London on systems written in Java. and this comment is completely misleading.

First of all, ANY memory leak discovered in this kind of critical Java code is found during testing, using JVM profilers such as this : http://docs.oracle.com/javase/6/docs/technotes/guides/visualvm/profiler.html and is considered a major problem, and a lot of high priority effort is focused on fixing it. Believe me, the "no problem just throw gigabytes more memory in the server" is NOT an acceptable solution - the JVM performance deteriorates as you start to let the heap size grow too high, indeed if Garbage Collection starts at these kind of sizes it can slow to completely unacceptable speeds. It's actually more sensible to let garbage collection run fairly regularly to keep the memory usage limited, and with modern multicore servers you don't notice any penalty for it.

The JVM on the IBM servers these large organisations use is also super optimised for the specific chip sets in the servers - the performance is in a different league altogether to the bog standard Oracle version on your PC.