Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
3  
Is C++ used in most UHF systems? –  Loki Astari Nov 25 '11 at 19:34
    
I get the impression it is, especially from a few hedge funds I know of and one investment bank. c++ with unix –  user997112 Nov 25 '11 at 20:42

2 Answers 2

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.

share|improve this answer
1  
I dont understand your last line? :) –  user997112 Nov 25 '11 at 20:42
    
@user997112, urbandictionary.com/define.php?term=YMMV –  Péter Török Nov 25 '11 at 21:39
2  
See also LMAX - How to Do 100K TPS at Less than 1ms Latency –  Jonas Nov 25 '11 at 21:47
    
@Jonas, do you know where I could find more HPC videos? Is there a centralised organisation? I doubt youtube has much on it! lol –  user997112 Nov 25 '11 at 22:55
    
"properly" - such a small, innocently looking word :) –  user1249 Nov 26 '11 at 12:29

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.

share|improve this answer
    
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
1  
@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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.