Java Faster Than C++? 1270
jg21 writes "The Java platform has a stigma of being a poor performer, but these new performance benchmark tests suggest otherwise. CS major Keith Lea took time out from his studies at student at Rensselaer Polytechnic Institute in upstate New York's Tech Valley to take the benchmark code for C++ and Java from Doug Bagley's now outdated (Fall 2001) "Great Computer Language Shootout" and run the tests himself. His conclusions include 'no one should ever run the client JVM when given the choice,' and 'Java is significantly faster than optimized C++ in many cases.' Very enterprising performance benchmarking work. Lea is planning next on updating the benchmarks with VC++ compiler on Windows, with JDK 1.5 beta, and might also test with Intel C++ Compiler. This is all great - the more people who know about present-day Java performance, the better.""
Um, it's online (Score:5, Informative)
The Java is Faster than C++ and C++ Sucks Unbiased Benchmark [kano.net]
Re:Um, it's online (Score:5, Insightful)
Re:Um, it's online (Score:4, Informative)
So yes, there are cases when runtime optimizations that are unavailable at compile time can speed things a lot. Does this make Java faster? yes, if you look at the right corner case. Hell NO, if you look at the wrong one.
The right tool for the job, as usual. And the right tool wielder, otherwise any tool will suck.
Command and source/test review. (Score:5, Informative)
This is known as the "halting problem". No, the compiler cannot guarantee the ability to transform a recursive solution to a non-recursive one. The case of the fibonacci algorithm is a particularly difficult one to transform properly if the compiler hasn't special cased it.
That said -- Ack and Fib are call overhead limited. They examples of poor quality code whose performance is not inner loop based.
Hash will be C-string (specifically strcmp and sprintf) limited in performance. The performance is therefore very data dependent (since Java uses length delimited strings.) Using a fast string class such as "The Better String Library" (http://bstring.sf.net) would have yielded C++ far better performance. A similar comment applies to the strcat test.
The Heapsort is a particularly bad implementation. In good implementations, the Intel compiler really takes gcc to town. See: http://www.azillionmonkeys.com/qed/sort.html
Integer Matrix multiplying is an extremely rare application. So I wouldn't put too much stock in the results here -- though, I would be surprised if there was much differentiation between either Java of C++ on this test.
The method calling, I think, will be very much limited by the compiler's ability to inline past method calls. I think Intel C/C++ differentiates itself on such things.
The Nestedloop and random tests are interesting -- I don't see how Java is supposed to beat C++ on it, but its possible to be equal.
I don't know enough about the Java object system and barely enough about C++ object system to comment on sieve or objinst.
It seems to me that sumcol and wc are going to be IO limited.
I don't think this test is exactly fair, as the code is not representative for tasks where performance really matters.
Re:Command and source/test review. (Score:5, Informative)
It's worth pointing out that inlining is a case where a VM can really shine for optimizing because it has alot more options available (partial inlining, etc) and can make better decisions about tradeoffs. But this particular benchmark is comparing apples to oranges.
Re:Command and source/test review. (Score:5, Informative)
Changing the objects the be stack allocated and adding -funroll-loops moves the c++ benchmark up to just ahead of the java benchmarks.
Of course, this does point to several advantages of a runtime optimizer. A static optimizer will never be as good at optimizing virtual function calls as a runtime optimizer, since it will never be as good at identifying types. Also, a runtime optimizer will always be better at creating specializations of existing functions (creating a special version of a routine when some input value is treated as a constant).
Re:Um, it's online (Score:4, Informative)
Re:Um, it's online (Score:4, Informative)
It also does stupid things. Like this:
When this would have worked just fine:The alternative is actually shorter, besides being faster and using less RAM.
I think the person which wrote this didn't know how to program in C++ very well. The two pieces of code are not even equivalent. The second loop is traversed backwards in the C++ version while it is not in the Java version. Don't ask me why.
Re:Um, it's online (Score:5, Informative)
int c = 0;
for (int i=n; i>0; i--) {
sprintf(buf, "%d", i);
if (X[strdup(buf)]) c++;
}
When this would have worked just fine:
int c = 0;
for (int i=n; i>0; i--) {
if (X[atoi(i)]) c++;
}
The code is dumb, yes, but you are wrong, nonetheless. That code won't even compile. I think you meant itoa(), which would be about the same as sprintf in terms of functionality.
That for() loop is not equivalent to the Java code's for loop, either. In the java code, he used
if (ht.containsKey(Integer.toString(i, 10))) c++;
which means that he should have used
if (X.count(somestringrepofi)) c++;
X[somestringrepofi] will create an entry for the key if it is not found, making it very different from containsKey().
Re:Um, it's online (Score:4, Insightful)
A fun one:
Java:
C++:
The C++ version could have been written IDENTICALLY (except for the 'public' modifier on the definition) to the Java version, but it was not. I'm not sure what the compiled difference might be, but there is a difference between these two bits of code, notably that in the C++ version there is a tertiary operator evaluated as an argument to a call to Ack, where this is not the case in the Java version. I would guess that this would be a more difficult thing for a compiler to figure out.
The differences in the methcall sources are even worse; in the C++ version of NthToggle, there are unnecessary dereferences of the this pointer that will kill performance, as well as in the call to new NthToggle(val, 3) in the C++ version is written with the coded constant new NthToggle(true,3) in the java version! It's hardly fair to compare things of this nature.
The trouble with benchmarking different languages is hard enough due to inherent differences between languages; it's not really enlightening to introduce artificial differences such as these.
Re:Um, it's online (Score:4, Informative)
Re:Um, it's online (Score:5, Informative)
As typically observed, I'm seeing the benchmarks take serious advantage of java's GC mechanism, whereby, they never pay the piper. With C++, the piper is constantly being paid. All of the benchmarks which allocate objects and then delete them, are therefore, invalid. To be fair, I think, you either need to add a System.gc() line in the java code where C++ is doing its deletes or you need to implement your own new and delete operators to function more in line with what java is doing. Until you do either one of those things, the comparisons where objects are being allocated and deallocated are invalid. And frankly, I'm still not sure adding System.gc() is even fair, on either side. The reason is, calling System.gc() simply hints that it's a good idea to collect. There is nothing which requires the collection to take place. So, technically, the call could still be many times faster. On the other hand, I don't know enough about how they handle their gc-hint logic nor am I aware of exactly how much overhead is involved in the actual collection process. If it occurs too often, the shift in workload may be too unfair. Nonetheless, it's a point of very serious contention.
Just for kicks, I modified objinst.java with, "if( i%(n/1000) == 0 ) System.gc()
So, basically, I'm not nearly as impressed as I first was. Simplistically, it's starting to look like a serious apples and oranges comparison. Elsewhere, you can find other examples of just plain bad code. Where again, with correct C++ code, came in about twice as fast at the Java code, whereby, more optimizations were still possible with the C++ code.
So, it looks like we're seeing a combination of things here. Looks like a combination of bad code, ideal corner cases for java's hot spot, and invalid comparisons with memory allocation.
Sadly, I'm once again seriously disappointed in java.
Re:Um, it's online (Score:5, Informative)
That's not a bug in the tests, it's a feature.
The theory behind garbage collection isn't just that it allows the programmer to avoid the effort of watching when to delete things. It's that garbage collection can actually improve performance on certain workloads.
Forcing a garbage collection for every delete is completely unfair, since it does a full scan of memory, as opposed to just twiddling bits to free a single data value.
There's no memory leak for these benchmarks... both C++ and Java free all memory used when the process exits. Perhaps you'd prefer a longer-running test with lot of garbage generation (forcing gc to run at some point).
Re:Um, it's online (Score:5, Interesting)
Write a java app that does nothing but repeatedly call System.gc(). Run it with the -verbose:gc option, and watch the garbage collector go. Mind you, this is not 100% proof, but the fact that it prints out [Full GC] over and over again makes me lean pretty strongly in the direction of "the garbage collector actually runs in response to a System.gc(), it's not just a hint".
One thing I would like Java to do is to allow me to delete objects manually. There are times when the garbage collector really sucks, but 95% of the time it's sufficient, in my experience. And yes, this experience comes from real-world apps.
Regarding the original topic, I would bet that there are cases where Java really could give C++ a run for its money. However, one liability that Java has compared to C at least is that making everything an object adds a whole lot of object overhead. I had to write a file search routine as part of a Java app, and originally wrote it strictly in Java. The sheer number of File objects that get created by such a routine is ridiculous, and there's really no way to reduce the overhead by reusing the objects -- File objects are immutable. Calling out to JNI resulted in a 3 to 5x performance boost. Does this one example prove anything? No, but it's a heck of a lot more real-world than simply appending a string to itself a few dozen times...
Re:Um, it's online (Score:5, Insightful)
/ took way too long to google
The Great Computer Language Shootout (Score:5, Informative)
Netcraft Confirms: (Score:3, Funny)
Oh hell, I don't have the heart. Nevermind.
Anyone got a match? (Score:5, Funny)
vi is better than emacs
bsd is better than linux
gnome is better than kde
.
.
.
anything else?
oh yeah...
my dad can beat up your dad.
And you smell funny.
One more... (Score:5, Funny)
anything else?
Yeah, Kuro5hin is better than Slashdot.
What are -client and -server? (Score:5, Informative)
different requirements (Score:5, Informative)
You might think that the two are the same, but the two settings actually make a visible impact if you're running on a multi-processor system. Most notably, the garbage collector and locking primitives are implemented differently.
Re:What are -client and -server? (Score:5, Informative)
Am I the only one who noticed the "inlining policy" thing? Considering "method call" was one of the most compelling arguments for his case (by orders of magnitude!), the fact that the methods being "called" are being called *INLINE* should mean something.
If you're allowed to turn on the java inliner, surely you can spare the time to turn on the C++ one as well (he used -O2, not -O3, for compiling the C++ apps).
He used g++ to compare C++ with Java... (Score:5, Insightful)
Re:He used g++ to compare C++ with Java... (Score:5, Informative)
Re:He used g++ to compare C++ with Java... (Score:5, Informative)
Re:He used g++ to compare C++ with Java... (Score:5, Informative)
The windows version has a free trial that runs for 30 days.
Try it. See if it makes a difference. If it doesn't, torch it. If you find it makes your critical code run 2x faster, then... have a look at what a computer that runs 2x faster will cost you, and then decide what to do.
Re:He used g++ to compare C++ with Java... (Score:4, Informative)
Languages vs Compilers (Score:5, Insightful)
Java and C++ are language. Languages aren't "faster" or "slower", but compilers for them might be. I find it somewhat underhanded to put the languages in the header when it's really comparing compilers.
Not to mention, inter-language compiler benchmark[et]ing is notoriously difficult to get 'right'. The programs tested are often stupid (doesn't do anything meaningful), or constructed by a person with more skill/bias for one language than the other.
The language does matter (Score:5, Insightful)
1) Java has bounds checking for arrays, C++ doesn't. This is specified in the language. This affects performance.
2) Java has garbage collection, C++ doesn't. This is specified in the language. This affects performance.
Also, the specification of Java says that it should be compiled to byte code and executed in a JVM.
So the "language" certainly affects performance.
Nice to hear... (Score:4, Insightful)
Re:Nice to hear... (Score:4, Funny)
A few points... (Score:5, Insightful)
- How equivalent were the benchmarks? Where they programmed in an optimum way for their respective compilers and libraries? I'm sure the java ones were.. what about the C++ ones? The author states he doesn't understand G++ very well.
G++ is also known to not produce the best results.
"I rant it with -O2"
My guess is many of the tests were not implemented properly in c++.
The main clue would be this... I can understand java having better than expected performance.. but there is no way I can accept that java is that much FASTER than properly done C++... it doesn't make any sense.
Re:A few points... (Score:5, Insightful)
Maybe it does make sense. But what it proves is that C++ (at least as implemented by GCC, but it's probably a design flaw) is slower than expected, not that Java is blazingly fast.
Re:A few points... (Score:5, Interesting)
A couple points:
- The "Great Shootout" benchmark times are sometimes way off because the run-time was too short to get an accurate reading. In those cases the tests should have been run with higher values to really stress the machine. That doesn't appear to be an issue in this test though (assuming his graph values are in seconds).
- Many of the C++ tests are not optimized. That is, they use C++ features like the iostream stuff (cout, and friends) which is extremely slow. The C versions are available and very fast. C++ is pretty much just an extension of C. You don't need to use C++ features if they slow you down. Another one is the hash stuff. In the C++ hash benchmark there are some goofy mistakes made by using the brackets [] operator where it forces several unnecessary lookups. You can also substitute a better STL hashing function that is faster (like MLton's insanely fast hasher).
- The test could be done by comparing C to Java. Anything in C++ can be made as fast as an equivalent C version but there are not many programmers that know how. Just assume anything in C++ will run as fast as a C version, and if it doesn't then you did something wrong. The hash tests would be easier in C++ though. If they were written properly they would kill the Java version.
With that said, I'm going to try these tests myself because I do not believe the results to be accurate. but who knows...
More info, after some testing (Score:5, Insightful)
Here is the "correct" code for hash2.cpp:
#include <stdio.h>
#include <iostream>
#include <ext/hash_map>
using namespace std;
using namespace __gnu_cxx;
struct eqstr {
bool operator()(const char* s1, const char* s2) const {
return strcmp(s1, s2) == 0;
}
};
struct hashme
{
size_t operator()(const char* s) const
{
size_t i;
for (i = 0; *s; s++)
i = 31 * i + *s;
return i;
}
};
int
main(int argc, char *argv[]) {
int n = ((argc == 2) ? atoi(argv[1]) : 1);
char buf[16];
typedef hash_map<const char*, int, hashme, eqstr> HM;
HM hash1, hash2;
for (int i=0; i<10000; i++) {
sprintf(buf, "foo_%d", i);
hash1[strdup(buf)] = i;
}
for (int i=0; i<n; i++) {
for (HM::iterator k = hash1.begin(); k != hash1.end(); ++k) {
hash2[(*k).first] += k->second;
}
}
cout << hash1["foo_1"] << " " << hash1["foo_9999"] << " "
<< hash2["foo_1"] << " " << hash2["foo_9999"] << endl;
}
Same for hash.cpp (Score:5, Interesting)
This guy is a tool.
Could use a good analysis (Score:5, Interesting)
I looked at his results page quite extensively, but failed to find a good analysis/justification of the results. Just saying that the Server JVM is better than the Client JVM is *not* enough.
I want to know where the C++ overhead comes from, which Java manages to avoid - does the JVM do better optimization because it is given a better intermediate code (bytecode)? Is it better at doing back/front end optimizations (unlikely given gcc's maturity).
I tried to look for possible discrepancies in the results, but the analysis will definitely take more time - and I think it's the job of the experimenter to do a proper analysis of the results. Liked his choice of benchmarks though.
Re:Could use a good analysis (Score:3, Informative)
Magnus.
Re:Could use a good analysis (Score:5, Interesting)
Most of his tests are big loops (primes, string concatenation, etc.) These are cases where (as a sibling poster mentioned) hot path analysis can do you a world of good. A heavily tuned C++ program can do it just as well, or better, but the point of using a high-level language is that you don't have to do those optimizations yourself; you write the code in whatever way seems natural and you let the compiler optimize.
In a long-running Java program, you don't have that extra layer between the program and the CPU. The JIT does a real native compilation and passes control off to it. Once that's started, it runs just as fast as any other assembly code. Potentially faster, given that the JIT can look at the current run and optimize based on the way the code is going: the precise CPU it's running on, where things are in memory, how far it can afford to unroll a loop, what loop invariants it can lift, etc. It can even replace code as it runs.
The question then is, does the one-time (albeit run-time) optimization do more good than it costs?
That's especially easy on a hyperthreaded system. In a C++ program, these loops will run in a single thread on a single CPU, so if the JIT compiler runs on the other (virtual) CPU, you get its effort for free. Even the garbage collector can run on the other CPU, so you get the convenience of memory management with no total performance cost. (You do burn more CPU cycles, but you use up no extra wall-clock time.)
GCC is very mature, but it doesn't have the option of changing the code at run time. Especially on modern CPUs with their incredibly deep pipelines, arranging your code to avoid pipeline stalls will depend a lot on runtime considerations.
Also, Java has a few advantages over C++ in optimization. It's very easy to analyze Java programs to be certain that certain memory locations absolutely will not be modified. That's much harder in languages with native pointers. Those invariants allow you to compile out certain calculations that would have to be done at runtime in a C/C++ program. You can even start spreading loop cycles over multiple CPUs, but I'm pretty certain that the present JVMs aren't that smart.
These results are toy benchmarks, and not really indicative of real performance, even on purely non-GUI code. But I wanted to outline the reasons why the results aren't just silly, and they do have a theoretical basis.
Now you're talking Profiling (Score:5, Interesting)
So, if the JIT computes Hot/Cold Paths, and optimizes the Hot paths, then it should work better and better on successive runs (as more and more profiling information is gathered). On the other hand, there will be cases where it performs worse, as profiles are gathered for specific inputs.
That means that if an average of say 5 runs (on the same input) is taken, it will have an unfair advantage (since gcc did NOT have the advantage of profiling information (see man gprof or similar)). Using Profiling as an optimization tool is *always* unfair unless both tools are provided with the advantage of the same profiling information. This is a valid question for the author then: if the JIT/javac/JVM uses profiling information, gcc should too, for fair comparison.
PS: I have seen this argument being made by my Professor and audiences at compiler conferences.
On the flip side (Score:5, Insightful)
With any JIT system you have the opertunity to use the profiling information from a given "window" of the execution so there is the possibility of having more than one compilation for a function.
Now, I do not know how sophisticated JAVA JIT compilers have become but this is one area where JIT will have an upper hand over a static compiler.
OTOH, these tests do not look like there is enough significant variation in the execution path for profiling to make a large difference.
Expert results (Score:5, Insightful)
That's Great! I can't figure out GCC's error messages, but I offer definitive proof that Java is faster than C++. Nice.
Re:Expert results (Score:5, Interesting)
"I was sick of hearing people say Java was slow, when I know it's pretty fast"
Nice, unbiased viewpoint there...
I don't actually care hugely about performance (Score:5, Interesting)
I care that Java is an inconvenient pain to develop in and use. I care that I have to start a mini-OS just to run a Java program. I care that the language is under the control of one vendor. I care that the 'intialization == resource allocation' model doesn't work in Java. I care that the type system is too anemic to support some of the more powerful generic programming constructs. I care that I don't get a choice about garbage collection. I care that I don't get to fiddle bits in particular memory locations, even if I want to.
I think Java is highly overrated. I would prefer that a better C++ (a C-like memory model, powerful generic programming, inheritance, and polymorphism) that lacked C++'s current nightmare of strangely interacting features and syntax.
I use Python when I don't need C++s speed or low-level memory model, and I'm happier for it. It's more flexible than Java, much quicker to develop in, and faster for running small programs. Java doesn't play well with others, and it was seemingly designed not to.
Besides, I suspect that someone who knew and like C++ really well could tweak his benchmarks to make C++ come out faster again anyway. That's something I've noticed about several benchmarks that compare languages in various ways.
Re:I don't actually care hugely about performance (Score:4, Interesting)
Have you looked at Objective-C? I'm not an expert, but it sounds just like what you describe. As a downside though, I'm not sure how well supported it is on non-OS-X platforms.
Java is not under one vendor!!!! (Score:5, Insightful)
It's a standards body just like any other, just more open.
P.S. - Aside from that gripe being wrong, I agree with the other poster that you should look into Objective-C to address other issues. Look for "GnuSTEP" for cross-platform objective C GUI work. It's just nicer to use on a Mac as they have very good tools (though in fairness I have never looked at what GnuSTEP tools might be around, I just can't imagine them being quite as good as the tools Apple has sunk so much effort into!).
Flawed Test (Score:3, Insightful)
One example of why the tests are BS (Score:5, Insightful)
int
main(int argc, char *argv[]) {
int n = ((argc == 2) ? atoi(argv[1]) : 1);
bool val = true;
>> Toggle *toggle = new Toggle(val);
for (int i=0; i<n; i++) {
val = toggle->activate().value();
}
cout << ((val) ? "true" : "false") << endl;
delete toggle;
val = true;
NthToggle *ntoggle = new NthToggle(val, 3);
for (int i=0; i<n; i++) {
val = ntoggle->activate().value();
}
cout << ((val) ? "true" : "false") << endl;
>> delete ntoggle;
return 0;
}
Why allocate and deallocate an object within the scope of a function? Well, in C++, there's no reason, so this is bad code. You can just declare it as a non-pointer and it lives in stack space. But guess what? You can't do that in Java: all objects are allocated on the heap.
That, and using cout instead of printf, are probably why this is slower than the "equivalent" Java.
-_-_-
Re:One example of why the tests are BS (Score:4, Informative)
The problem is that g++ probably does not optimise it all inline, whereas the particular java VM he has chosen to use probably does.
Although defining the Toggle variables with auto storage class may give g++ the hint it needs to realise this.
Additionally, the activate method is declared to be virtual, this shouldn't be a problem, except that it may further hide the optimisation opportunity from g++. Note that the description of the test does not stipulate that it is testing virtual methods.
Some performance myths (Score:5, Interesting)
Now, regarding java performance ... Java isn't slow per se, JVMs and some apis (most notably swing) are. Furthermore, JVMs usually have a slow startup, which gave java a bad name (for desktop apps startup matters a lot, for servers it's hardly a big deal). Java can be interpreted, but it doesn't have to be so (all "modern" JVMs compile to binary code on the fly)
Bytecode-based environments will, IMNSHO, eventually lead to faster execution than with pre-compilation. The reason is profiling and specialized code generation. With today's processors, profiling can lead sometimes to spectacular improvements - as much as 30% performance improvements on Itanium for instance. Although Itanium is arguably dead, other future architectures will likely rely on profiling as well. If you don't believe me, check the research in processor architecture and compiling.
The big issue with profiling is that the developper has to do it, and on a dataset that's not necessarily similar to the user's input data. Bytecode environments can do this on-the-fly, and with very accurate data.
C++ hash code is hobbled? (Score:3)
Why did he use the strdup function when he already has the char array from the previous sprintf?? That step incurs a huge and unnecessary penalty w/an allocation, just pass the pointer!
Also, in the second 'for' loop in hash2, he does extra work beacuse he already looked up (*k).second.
shouldv'e done hash2[k->first] = k->second;
Tell me I'm not crazy.
What about gcj? (Score:5, Interesting)
-josh
java *can* be fast... (Score:5, Interesting)
I am starting on a new standalone server now doing something different, but I am going to stick with Java, and will be happy to see what 1.5 does for me.
But I have seen Java run slow before, and I will tell you this: in every instance it is due to someone writing some needlessly complicated J2EE application with layer upon bloaty layer of indirection. All the wishing in the world won't make one of those behemoths run fast, but it's not fair to blame Java. Maybe blame Sun for EJB's and their best practices, or blame BEA for selling such a pig.
Stuff I like in the Java world:
Slow C++ compiler (Score:4, Informative)
A lot of the test results are close, and I think a different compiler would change the outcome.
Can I have an infinite budget to write the code? (Score:5, Interesting)
We knew java in theory should be worse than C++ at manipulating large blocks of raw data, so we spent some time architecting, prototyping, and profiling java. We quickly learned the limitations and strengths.
The result? After 4 engineers worked for 6 months, we had a program that was rock solid, had more features, had a modern UI, and was WAY faster. Night and day; the old program felt like a hog, and the new program was zippy as anything. And the new code is fewer lines, and (in our opinion) way more maintainable. Since the original release, we've added severeal new features after day or two of work; the same features never would have happened on the old version, because they would have been too risky.
So the question is this? Could we have re-written or refactored the C++ program and gotten the same speed benefits? No doubt, such a thing is possible. But we are all convinced there is NO WAY we could have done it with as little effort. The C++ version would have taken longer to write and debug.
Re:Can I have an infinite budget to write the code (Score:4, Insightful)
Unix GUIs are far easier to implement with Java than with C++. Athena/Xlib are a huge fargin' hassle and no-one ever gets the widgets right. Motif is too expensive to license.
You really need to look into Qt. It's much easier to use than Swing.
O3? Equivalent programs? (Score:5, Insightful)
-O3 adds function inlining and register renaming [gnu.org].
Also, some of the code doesn't look too much of a test of the language, but more of a test of the libraries. Both versions of hash rely on the library implementations, and it looks like hash.cpp [kano.net] does an extra strdup that the java version doesn't. I don't know either of the hash libraries well enough, but I don't see why this significant slowdown would be necessary in the gcc version.
Troll (Score:5, Insightful)
Gcc is designed for compatibility with a wide range of architectures, and is not optimized for a single one. He also (apparantly) used stock glibc from Red Hat. And only one "test", the method call test, showed java to be a real winner. And even then, it's server-side Java, which is meaning less when you talk about it as a day-to-day dev language (ie; creating standalone client-side apps).
Intel's (heavily optimized) C++ compiler should be a damn sight faster, and so should VC++.
This "comparison" is so limited in scope and meaning, that this writeup should be considered a troll.
Hell, read his lead-in:
Ie; I set out to prove Java is teh awesome and c++ is teh suck!
If anything it proves something I've known intuitively for a long time. gcc does not produce x86 code that's as fast as it could be. That's a trade-off for it being able to compile for every friggin cpu under the sun.
I can't wait till RMS takes personal offense and goes on the attack.
Java is not faster than optimized c++ (Score:4, Insightful)
Okay, so how could I make a blanket statement like that? In this case, the author of the paper merely used a compiler switch in gcc (-o2). That doesn't mean his c++ was highly optimized. It just means he told the compiler to do its best. If you really wanted to highly optimize c++, you would study the compiler and how it works, and you would profile the actual assembly that the compiler generates to make sure that it didn't do anything unexpected. Given *any* algorithm, I can come up with a c++ implementation that is faster than a Java implementation. Period.
The java compiler actually compiles to a virtual opcode format, which is then interpreted by the java virtual machine at runtime. Imagine if you needed to talk to someone on the phone, but instead of talking to them, you had to talk through an intermediary. Is there any possible way that it could be faster than talking to the person directly?
Now, I'll be the first to point out that a badly implemented c++ algorithm could be much slower than a well implemented Java algorithm, but I'll take the pepsi challenge with well written code any time, and win.
Relying on benchmarks and code somebody else wrote doesn't prove anything. Did he get down and dirty with the compiler and look at the generated assembly code? No, he did not.
Move along, there's nothing to see here.
Really? Try this one. (Score:4, Informative)
Oh, wait, you can't do that because nobody can write Halting.
I guess that means there are some algorithms for which you can't write a faster C++ version. Next time, try less rhetoric and more facts. "There exist lots of algorithms for which I can code a C++ implementation that's faster than a Java implementation" is good. The instant you make a unilateral statement like the one you just made, though, it shows that you don't know as much about computer science as you think you know.
Fact: there exist cases where Java is faster due to its ability to optimize on the fly. And if you know C++ as well as you think you do, this shouldn't surprise you. C++ beats C so handily for many tasks because C++ is able to do much better compile-time optimization largely on account of the C++ compiler having access to much more type information than a C compiler. When Java beats C++, it's on account of Java having access to much more information about runtime paths than a C++ compiler. ("Much more" may be an understatement; C++ doesn't even try!)
In other words, the JVM (sometimes) beats C++ for the exact same reason that C++ almost always spanks C; the faster implementation has access to more information and uses that information to make more efficient use of cycles.
I don't think these situations will appear all that often, and I am deeply skeptical of this guy's "in the general case, Java is faster" conclusion. But my skepticism isn't leading me to make rash statements which cannot be backed up.
The methodology used here sucks (Score:4, Interesting)
This didn't exactly fill me with optimism either:
This would seem to imply that the author does not know much about either shell scripting or Makefiles. I'm not sure I'm willing to trust benchmarks from somebody who can't figure out an automated way to build and run them.Explanation (Score:5, Interesting)
Reviewing the console log, we find that when java programs were tested with a large number of iterations, Java only performed better on one test.
I know that Java has many strengths, but speed isn't one of them. Looking at the results, we see the g++ runtimes are much more consistent than those of Java - on some tests, the Java Server is faster than the client by a factor of 20!? How could a programmer code without having any realistic expectation of the speed of his code. How embarrassed would you be to find that your "blazingly fast" app ran slower than molasses on the client machine, for reasons yet unknown?
When it comes to speed, compiled languages will always run faster than interpreted ones, especially in real-world applications.
But discussions of language speed are a moot point. What this really tested was the implementation, not the language. Speed is never a criteria upon which languages are judged - a "slow" language can always be brought up to speed with compiler optimizations (with a few exceptions). I suspect that if C++ was interpreted, and Java compiled, we'd see exactly the opposite results.
In short, the value of a language consists not in how fast it runs, but in what it enables the programmer to do.
Optimization at runtime vs. compile time (Score:5, Insightful)
I think some of you are overlooking the fact that a VM running byte code is capable of doing optimizations that a compiled language just can't possibly do. A compiled language can only be optimized at compile time. Those optimizations may be very sophisticated, but they can never be any better than an educated guess about what's going to happen at runtime.
But a VM is capable of determining exactly what is happening at runtime; it doesn't have to guess. And thus it is able to optimize those sections of code that really are, in true fact, impacting performance most severely. In can do this by compiling those sections to machine code, thus exploiting precisely the advantage that a compiled language is alleged to have by its very nature. And other kinds of optimizations, the kind that a compiler traditionally does, can be performed on those sections as well.
Of course there are scenarios where runtime optimization doesn't win much, for example in a program that is run once on a small amount of data and then stopped, so that the profiler doesn't get much useful info to work with. This is why Java is more likely to have benefits like this in long-running server processes.
And of course a conscientious C++ programmer will run a profiler on his program on a lot of sample data, and go about optimizing the slowest parts. A conscientious Java programmer should do that too. But an interpreted language has the advantage that the VM can do a lot of that work for you, and always does it at runtime, which is when it really counts.
Function calls (Score:5, Interesting)
For example:
[bdr@arthurdent tests]$ time
165580141
real 0m3.709s
user 0m3.608s
sys 0m0.005s
time
165580141
real 0m0.006s
user 0m0.002s
sys 0m0.002s
I think a lot of these benchmarks are showing that the Hotspot optimiser is very good at avoiding function call overheads.
Study Proves Sun Java Compiler Faster than GCC (Score:4, Insightful)
What this shows is that GCC's implementation of C++ is slower than an interpreted language like Java. This does not show that C++ is slower than Java.
----
Notes on Stuff [blogspot.com]
String concat sillyness (Score:5, Informative)
I could not run the test for 10M, but ran it for up to 1M. 541 milliseconds in one case, 280 in the other. Here's the code I used (I had to modify the timing cause I'm running XP):The only difference in the class Strcat besides the class name is the instantiation of StringBuffer.
NB: I'm not accusing the author of bias against Java, nor am I ignorant of the fact a bunch of
Obligatory Bash Quote... (Score:4, Funny)
hash.c uses sprintf which is very slow (Score:4, Insightful)
It must parse the "%x" and determine what it's trying to do. So it decides, at runtime, you want to translate an integer value into a hexidecimal string. Of course if there's an error at runtime in the string "..." it must generate an error. How 'bout using strtol?
Now let's look at the java version:
Integer.toString(i, 16)
Ok, here we have something that is strongly typed so of course it will be faster. At runtime the java compiler _knows_ what it's dealing with and it knows it must invoke the hexadecimal conversion code.
Note that these statements are within loops.
Just one example, that was the first file I looked at. I don't think they have quite optimized the C++ code IMO. Plus the C++ library is notoriously slow, I would recommend rogue wave or your homegrown C++ classes.
I think the lesson here is it's very easy to write slow C++ code while it's very easy to write fast Java code.
Gimme any C++ code here and I'll profile it/speed it up and get it as fast if not faster than java.
Java performance "truths" change over time (Score:5, Informative)
Some very surprising tidbits there. For instance:
"Performance advice often has a short shelf life; while it was once true that allocation was expensive, it is now no longer the case. In fact, it is downright cheap, and with a few very compute-intensive exceptions, performance considerations are generally no longer a good reason to avoid allocation. Sun estimates allocation costs at approximately ten machine instructions. That's pretty much free -- certainly no reason to complicate the structure of your program or incur additional maintenance risks for the sake of eliminating a few object creations."
Read the article for an excellent nuts-and-bolts analysis of many current performance considerations. From the posts in this thread, it's pretty clear a lot of people haven't looked into what's actually done in a server JVM these days.
Looking as the assembly for the C++ code (Score:4, Insightful)
Ackermann.cpp, for example, spends very little time actually calculating anything. Much of it's work includes all the overhead associated with making a function call.
Included in this overhead is management of the frame pointer. By using -fomit-frame-pointer, you avoid pushing the old ebp on the stack and a store of the current esp into ebp.
Ackermann runs about twice as fast with this simple optimization.
Re:If you don't run the JVM... (Score:5, Informative)
Re:Caught up with the speed, but still the ugliest (Score:3, Informative)
Re:Caught up with the speed, but still the ugliest (Score:3, Insightful)
Elaboration:
No model: with swt you get the widget as a UI object with a field of type Object that you may or may not use as a reference to the object dislpayed. You ahve to write the code that updates th
Re:Caught up with the speed, but still the ugliest (Score:5, Informative)
Oh... and as of Java1.5, Swing apps can now be skinned to look however you'd like them to.
Re:Caught up with the speed, but still the ugliest (Score:5, Insightful)
Re:Caught up with the speed, but still the ugliest (Score:4, Informative)
Seeing things like this:is hurting my eyes.
This page [pemberley.com] has more information about this horrible malfeature.
That just means... (Score:3, Interesting)
Re:Caught up with the speed, but still the ugliest (Score:4, Informative)
http://developer.apple.com/documentation/Java/C
Very true, if don't nkow what you are doing (Score:5, Informative)
Now, when you need to change that quickly and without much overload, there are ways. A little known global HashTable called UIDefaults lets you change just about everything on the visual interface without having to write your own LookAndFeel (which you obviously can do too, for very large projects). You can have your scrollbars, menus, etc in any colour, size and shape, using any font. You can easily change all default colours without having to set every control. After a while the ugliness ceases to be a problem.
Re:Caught up with the speed, but still the ugliest (Score:4, Interesting)
Non-graphical Java code can indeed be very competitive with other languages, but it would help if the author bothered to implement the code for his tests intelligently.
The Fibonacci code is recursive, which is about the slowest possible way to implement it, and much of the other code uses high-level features of C++ which are a convenience for the programmer, but are not used when worried about speed.
This fibo code, for example, should be faster:This code was turned in by a student in a lab of mine. This was his first semester in CS, and this code outperforms the Java code quoted on the website considerably. (Try it!).
I am not saying that recursion and high-level C++ features should NOT be used, but I AM saying that if you are comparing the potential speed of languages, you should use tricks that each language provides to optimize speed.
Java will never be faster than properly optimized C++ compiled with an intelligent optimizing compiler except in bizarre corner cases, and tests like this are not terribly convincing demonstrations otherwise. Even the corner cases are removed by a sufficiently talented programmer.
This is also not to say that Java is bad. I think Java is a great language (except for GUI programming with SWING), and definitely makes many programming tasks faster to code and easier to debug than one can do in C++.
Re:Caught up with the speed, but still the ugliest (Score:5, Insightful)
Actually you can do most anything in those languages. Although for performance, and desgin reasons you may wish to use something else depending on the application.
You have no respect for code. Learn assembly and then we'll talk.
I know assembly, and fun as it is, it isn't well suited for high level projects where code reuse and mantainability are important. By the way, I have no respect for someone who knows assembly and thinks it is difficult. It isn't. And it certainly isn't graceful or elegant, but I love it all the same.
My Hero! (Score:5, Insightful)
I'm tired of some programmers expecting to be worshipped because they know assembly.
Assembly isn't all that.
For some uses, it is the right tool. For 99.9%+ it most definitely isn't.
Re:my arse (Score:3, Funny)
I used to be a C hacker and a laughed at Java when it came out because of it's poor performance. Times have changed, but the language bigots haven't.
Re:my arse (Score:5, Informative)
This whole "x is written in y, so x can't be faster than y" rubbish is just that - rubbish.
Re:Sorry, no. (Score:5, Funny)
Re:Sorry, no. (Score:4, Interesting)
Re:Sorry, no. (Score:5, Interesting)
If you have a program that runs for awhile (so the startup time is small compared to the time the program takes to run), and does not do intensive output to the console, then Java is a reasonable choice in my opinion. Combined with SWT, Java applications can be quite snappy (see Eclipse, Azureus), and the end user will probably never know the difference.
- shadowmatter
Re:Sorry, no. (Score:3, Interesting)
Desktop app use cases may be different, in which case your test may be valid. Start-up time is definitely a significant part of the user experience. At one point Java 1.5 was supposed to have shared VMs, so that Java can start at system load time. Other VMs would just then
Re:Sorry, no. (Score:4, Interesting)
While it is entirely possible [in c/c++] to use a profiler to generate compiler hints so as to generate even more efficient code, this is rarely performed, and often is not free. A VM otoh does get this capability for free.
Additionally, the java memory manager has a slight edge over tradditional malloc's for total throughput (though the best throughput configurations have horrible spuradic response times). It is also possible to choose a different memory manager for c/c++, but this too is rarely used.. Moreover, it is much harder to have 3'rd party code integrate well with a garbage-collector model. Java enforces garbage collection, and thus optionally gets the particular performance gains (being free to trade off throughput for responsiveness no matter what 3'rd part code is integrated).
As was pointed out, one of the strenghts of C/C++ are pass-by-value, which allows memory allocations to be avoided all-together, but at the cost of copy-time and robustness of code. If a method call requires instantiation, c/c++ have the option of passing in a local [stack resident] structure to be populated by the method. However, this is fodder for buffer-overflow exploits, and notorious for otherwise bad code (accidently caching the address of a value that lives on the stack). Thus, given that c++ will use "new" and thus generally perform a malloc, the same performance issues above apply, and c/c++ may have the additional overhead of copy-by-value.
The fact that you have to explicity declare a c++ parameter as pass-by-reference suggests that those interested in "good programming practices" (tm) will only make a pass-by-reference if you intend to modify it's contents. Thus "clean" code in c++ will be copy-intensive... For fairness, clean java code should always make immutable wrappers for any non-modifyable code, thus requiring an all together different liability (and thus I can't make any claims as to which would be faster; wrapper object instantiation or deep parameter-copy). Though all primatives are available in java as immutable objects (Strings, Dates, etc). Moreoever, clean OO-code should always use method getters, and make all fields private (not even protected). Both C++ and jit'd java can inline these getters.
I haven't looked at the benchmark code, but the above are common components which make a big difference when scaling to large enterprise applications, or even when merely writing a glue application which integrates many large 3'rd party libraries. In c++ you don't have a lot of control over the 3'rd party libraries (in terms of their design trade-offs), but with a VM, you are largely sheltered and have many configurable alternatives.
Re:Sorry, no. (Score:5, Funny)
Re:This doesn't make any sense... (Score:5, Informative)
Something I've often wondered is whether this caching could be persistent, i.e. be kept between runs of the JVM. Eventually, the entire program would be translated to pure assembler with the cost of translation largely amortised across many sessions. You still keep the safety, cross platform compatibility and ease-of-programming of a bytecode language (i.e. Java, C#) but you get the bonus of the cached object code being just as fast, even during startup and shutdown.
Provide link please! (Score:3, Insightful)
Re:every year this happens... (Score:4, Informative)
been there, done that (Score:5, Informative)
2) While it's not an id game, IL2 Sturmovik [il2sturmovik.com] is a critically-acclaimed fight simulator that was written almost entirely in Java.
Re:every year this happens... (Score:5, Insightful)
_Jikes_, OTOH, is written in C++. But that's not really the official Java compiler by a long shot.
Your second requirement is absolutely bizarre. Does this mean you're not taking languages like Lisp, Prolog, Python, and Perl seriously, too? Those are all very nice languages for doing stuff in, but I'm pretty sure id never wrote a 3D engine in them. In fact, I was under the impression that id has never written a 3D engine in C++, either. Should we not take C++ seriously?
IMHO: The measure of a language is not how easy it is to write an arbitrary application in it. It's how easy it is to write something for which the language was designed to do.
-Erwos
Re:every year this happens... (Score:3, Funny)
Except for the first Java compiler.
Re:Nort really surprising (Score:5, Insightful)
This would be much more meaninful if you had used fputs() instead of write() in the C version.
As for "several orders of magnitude," I call bullshit. There's no way in hell the standard C++ IO functions are hundreds of times slower unless they're extremely badly written. Which leads me to another reason why this example sucks: there can be different implementations of the standard libraries.
In conclusion, this "comparison" is a stinky pile of shit, and should be ignored. And it's not even on topic, since it doesn't have a Java version.
Re:Benchmarks (Score:3, Interesting)
I put it on the web because I thought it would interest others. Even though I put disclaimers on the page, and I try not to make any claims, I see some people say the shootout shows that "language X is faster than language Y".
That claim is probably premature and hence, bogus. I
Re:-O3? (Score:4, Informative)
For example:
methcall.cpp -O2 1.8s -O3 1.8s
fib.cpp -O2 3.7s -O3 3.7s
matrix.cpp -O2 1.8s -O3 1.8s (interestingly, adding -march=athlon-xp for my machine reduces time to 1.5s)
Java to Assembly (Score:4, Insightful)
The rest of the performance improvements are in the compiler optimizations and libraries which are mostly tangential to the language itself. If the compiler is clever enough to take "for (x=0, i=0; i<100; ++i) x+=5;" and substitute this for "x=500;", then great, but it should not be confused with an endorsement of the language itself.
Furthermore, I had no difficulty modifying the C++ code to outperform or at least meet the results of the server-side JVM using G++. In the cases where Java had any lead whatsoever, the code was so trivial that the JVM could virtually precompute the result. I don't see this as being useful because in the real-world, nothing I write is so trivial that this is possible. If it was, I would have done it myself. I believe this largely explains the discrepency between these "tests" and my actual experience.
-Hope