Kevin Greer's Stuff
[ start | index | login ]
start > 2006-12-04 > 1

2006-12-04 #1

Created by kgr. Last edited by kgr, 2 years and 209 days ago. Viewed 2,531 times. #6
[diff] [history] [edit] [rdf]
labels
attachments

Java vs C++ Performance

There's a discussion going on at >>Lambda the Ultimate about how >>C++ has become too "expert friendly". Someone made the following comment about C++ and Java performance to which I just had to reply:

Java does not have value objects, stack-based allocation, templates, etc. I would hardly call it the same. C++ is more efficient due to these features.

Java will also allocate from the stack when it can prove that it is safe to do so. C++ forces the developer to make the decision, often to disastrous effect.

You can use polymorphism to write generic code in Java, as is done with the standard collection classes. With Java's partial-evaluation/method-specialization feature this gives you the same performance as C++ generics but without the huge memory overhead of having to internally generate type specific versions for each type. Java's HotSpot compiler only creates specializations of classes which are actually used a lot. Infrequently used classes are not specialized. This saves memory and as a result can even improve performance by improving cache consistency.

Java's average amortized memory allocation takes less that three CPU instructions whereas C++'s malloc/free combination takes around 27 (on Sparc, according to Sun).

The performance advantages of GC are discussed in the famous pager by Andrew Appel, of ML fame, called >>Garbage Collection Can Be Faster Than Stack Allocation.

Java also derives several other advantages from waiting until run-time to perform compilation. It can collect real-world statistics for things like branching or method in-lining so that it can make better choices that a statically compiled language like C++ can.

Consider the example where you have three methods, a(), b(), c() such that a() calls b() and b() calls c(). Both C++ and Java have a size limits for the size of methods that they will in-line. In C++ if c() is sufficiently small then it would be in-lined into b(). However, this might push b() over the in-lining limit which would prevent it from being in-lined into a(). With Java c() would only be in-lined into b() if it were actually a hot-spot. If it weren't, then if b() were a hot-spot then it could still be in-lined into a().

When working with arrays Java is allowed to make some optimizations that C++ cannot make because of the possibility of issues related to pointers. This is the same reason that C++ is slightly slower than Fortran for working with arrays.

Many C++ programmers assume that because Java doesn't give them the "freedom" to perform many optimizations themselves, that these optimizations aren't being done. The truth however is that Java has just moved the complexity of deciding when and how to make many types of optimizations out of the hands of the language and its developers and instead put them into the compiler and the runtime environment. If you have the compiler technology to do it, then this seems like a much better solution.

Here's some >>C++ vs Java benchmarks. At the bottom of the page you'll find a collection of related links.

This blog entry has received some >>comments at >>reddit.

no comments | post comment
peerbox.com | Copyright 2005-2006 Kevin G. R. Greer