3

Could Java ever match C++ with regards to programming ultra high frequency systems? Has the JVM improved enough to allow this? From a theoretical or practical point is it possible?

Is C++ used in most UHF systems simply because out of habit?

If you agree/disagree, what parts to Java/C++ is the basis for your viewpoint?

DeadMG
  • 36,794
  • 8
  • 70
  • 139
user997112
  • 1,469
  • 2
  • 19
  • 24

3 Answers3

6

The inherent problem is the garbage collector. It's non-deterministic- something that UHF can never cope with. Working around this issue is basically equivalent to re-inventing native allocators. Moreover, the language carries a lot of intrinsic overhead that cannot be reduced, where C++'s constructs are directly more efficient- for example, a Java member variable has to be another reference, even if in reality it could be allocated as part of the block, which is how it's done in C++. This enforces extra indirection/cache overhead/etc. This means that a Java UHF program would be inherently significantly harder to write, for poorer results, than a C++ equivalent.

Fundamentally, high performance determinism is in the design of C++. It's not in the design of Java.

Edit: What I meant by "part of the block". In C++, a class or struct is allocated as one, single, big chunk- effectively, it's an array. This means that indexing into that array almost arbitrarily is pretty much free- that is, accessing a member variable in C++ is equivalent to an array index, for any nesting. In Java, however, every member variable of class type must be pointed to. This means that classes in Java necessarily form linked lists, which are massively slower to access. Every member variable you access in Java is a pointer de-reference, which is terribly slow in comparison. Now, in C++, if you need it, you can make pointers members and access through them, but in Java there's no equivalent option to make members into an array. This means that Java enforces the slower, linked-list access semantics. The same principle applies for many other similar cases.

And a concurrent GC is only going to help with a non-maximally-concurrent program. If you have a program that's using 100% CPU, there's no way to GC it without reducing the amount available for the program.

DeadMG
  • 36,794
  • 8
  • 70
  • 139
  • HI, could you elaborate on the example you gave, regarding a Java member variable and the "block"? Thanks – user997112 Nov 25 '11 at 20:43
  • 1
    IMHO it's not so one-sided, although it is true C++ is in general more suitable for really performance-critical applications. Modern Java GCs have several different collection strategies to choose from, including Concurrent Mark-Sweep, which goes a long way towards making GC nonobtrusive and "deterministic", i.e. with proper configuration the GC will never "stop the world" in the middle of processing. Moreover, method calls and object allocation/deallocation are way cheaper in Java than in C++. – Péter Török Nov 25 '11 at 21:37
  • @Peter Im really intrigued by your last sentence. Could you elaborate or point me to some reading going into detail more? – user997112 Nov 25 '11 at 22:58
  • 2
    @user997112, short lived objects are incubated by the GC in so called "eden" and "survivor" memory areas. Whenever the eden space fills up, the GC tracks down all known references and moves all alive objects to the survivor space. All what's left is the dead objects, thus they got "GC-d" with practically zero effort. Method calls are cheap because the JIT compiler can inline them runtime whenever needed. – Péter Török Nov 25 '11 at 23:46
  • @Peter, fascinating! Do you know any good books/white papers so I can read up more on this? – user997112 Nov 25 '11 at 23:52
  • @user997112, an extensive discussion of the topic on SO: http://stackoverflow.com/questions/2163411/why-did-java-have-the-reputation-of-being-slow . A whitepaper on Java 6 GC tuning, with good explanations about how the GC works: http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html – Péter Török Nov 26 '11 at 00:13
  • +1 This is a definite problem with Java for HPC. Companies like Azul have got pauseless GC's, but it's specialised stuff.... – Martijn Verburg Nov 26 '11 at 11:06
4

Yes it can if you design your data structures, objects and architecture properly (which is true under any platform). The Disruptor has more than proven this recently.

That said, C and C++ still offer natively lower level constructs than Java (which probably needs something like tuples to help push it over the edge)

Your Mileage May Vary (YMMV) with all of this.

Martijn Verburg
  • 22,006
  • 1
  • 49
  • 81
1

For the speed sensitive part in High Frequency Trading, Java is just not good enough.

Java doesn't allow one enough control over object layout. In particular, it lacks a compact memory layout that the array and vector provide. An ArrayList of object references is not the same.

Java also has a non-zero object overhead, resulting in objects being larger.

Both results in cache misses, which worsens reaction time.

And in HFT, Winner takes all - There is no second place.

Lots of comments on the other answers incorrectly concentrate on the Garbage Collector. GC doesn't matter at all. During the speed sensitive part, GC won't be triggered. And there will be enough time between two speed sensitive events to do as much house keeping as required- no HFT system should be anywhere near 100% load.

Part of any as-fast-as-possible design, is postponing anything not crucial for sending out the order until after sending it. In fact, GC could actually help in that aspect! In practice, it is usually easier to just allocate the memory required on startup, and reuse it.

Of course, there are also parts that are not speed sensitive: GUI, post-processing, risk calculations, monitoring, and so on. Those parts can be done in almost any language, including Java.

Sjoerd
  • 2,906
  • 1
  • 19
  • 18