Java Faster Than C++? No Way!
Ever since 1995, the Java world has been fascinated with talks and benchmarks which shows why Java should be/could be/would be/is faster than C++.
At first it was the JIT:
When Java gets a JIT, it would be faster than C++.
Then it was the HotSpot:
When the HotSpot is done, Java would be faster than C++.
Now it is the benchmarks:
Professor So-and-so did a benchmark, and guess what, Java is faster than C++.
And the well-argued theories:
The garbage collector is faster than hand collection for the same amount of garbage.
But my experience tells me that Java is slower than C++:
- My Java based "Hello, World." program is slower than my C++ "Hello, World." program.
- My Java based Java compiler is slower than my C++ based Java compiler.
- My Java based IDE (wonderful as it is) is slower than my C++ based IDE.
- My Java based JavaScript interpreter is slower than my C++ based JavaScript interpreter.
Java has many advantages over C++. Performance is not one of them.
The good news is that the Moore's Law and cheaper memories has done a lot more to boost Java's performance than anything else. Java is the appropriate technology in more and more applications.
Re: Java Faster Than C++? No Way!
Do your own benchmarks and see for yourself. Write a program in C++ and write the equivalent program in Java and see which one wins (of course, turning on full optimizations in both; you do know how to turn on the "make Java run fast" flag, don't you?). I've found that C++ is only assured a win when the program runs for a very short period of time or when compiled with the Intel C++ compiler (that thing is amazing). If you have long-running programs and compile with either MSVC or GCC, theres a good chance that Java will beat the pants off the C++ program (where beat the pants off is interpreted as running 1-5% faster :) ).
On your existing experience, it is hard to do such comparisons and make a decision on the language when the implementations are so different. Is Jikes doing all the proper checks that Javac is doing. Do C++ IDEs have 1/10th the features of Java IDEs? Have you even looked at IDEA?
Again, take nobody's word for it. Test yourself. But a valid test must vary only in language and the comparisons you made vary vastly in implementation, not just language.
On your existing experience, it is hard to do such comparisons and make a decision on the language when the implementations are so different. Is Jikes doing all the proper checks that Javac is doing. Do C++ IDEs have 1/10th the features of Java IDEs? Have you even looked at IDEA?
Again, take nobody's word for it. Test yourself. But a valid test must vary only in language and the comparisons you made vary vastly in implementation, not just language.
Re: Java Faster Than C++? No Way!
Indeed. The problem you're leaving out is common: what does "faster" mean? For that matter, what does "run" mean? If it's all about "generate a.out and run it" then... well, since C doesn't load a massive runtime and then finally execute a programmer-supplied set of instructions, it "runs faster."
IDEs have the same problem: Java IDEs are portable (provided you're not talking about Eclipse) so there's a price to be paid for that portability. Eclipse, which has to be ported for each graphics environment, is "faster" in terms of user response (i.e., drawing things, getting keystrokes) because it doesn't use Java's event construction for those things.
That goes back to an old problem, as mentioned. Remember, people think Windows is "faster" than UNIX, because Windows moves the mouse faster! Of course, moving the mouse about slows down every other process in Windows, but that doesn't count - because it moves the mouse faster.
Re: Java Faster Than C++? No Way!
Well, as a programmer, I can reason both sides of the argument. I can see the points both Anonymous and Joseph made.
But then there is reality. As a user, Java programs have that unmistakable feel of slowness associated with them. The kind of slowness that prompts you to tell the person watching it with you, "I'm sorry. This program is kind of slow. It's written in Java."
I don't know how to square the reality (or my perception of it) with the theory. It's one of those "in theory theory is the same as practice, but in practice theory is not the same as practice" monents.
So why don't we settle everything with a Google Fight. :)
Re: Java Faster Than C++? No Way!
Weiqi, your still avoiding anonymous's valid suggestion of speaking to real benchmarks.
This time what I think your guilty of is the overused excuse that any slow running application written in Java can be blamed on Java. Everytime an application that is written in Java runs slowly, Java always is given the blame. When a C/C++ program is running slower, the network usually takes the blame. Never is the design or implementation blamed.
I think the line "its slow because its a Java app..." is overused and no longer accurate in most cases.
Tim
Re: Java Faster Than C++? No Way!
Sadly, what I think weiqi is getting around to saying is that "perceived" perception is in the end, the deciding factor. I almost agree with that. I too have seen that Java is faster than C/C++ in many areas, and especially on the server side where it reigns supreme, we all know that the JIT kicks in after a little while which is most often seen on the server side. Even so, the Java client side desktop world is making a come back. There are a few reasons why.
First, as someone told me the other day and it made good sense, web/html is kind of out. When it came in strong, computers were too slow and desktop interaction was limited. HTML fit the bill because you could deploy quickly, and limited user interaction was all that was needed. To be honest, a lot of apps are still better written as web apps than client side applications.
That said, the sophistication of todays applications are much more difficult to develop on the web. While MS hasn't had an update in years and Mozilla/firefox is coming on strong, a few years back there were so many browser issues it made it difficult to develop solid thick-client like apps without a lot of extra code to handle all the versions and nuances. Today its a bit better, and Flash and other tools make it more capable to support. Even so, a site that has to handle 1000s of users means a LOT of hardware is needed. By moving the user interactive GUI rich application to the client with a decent instaler that allows installation via the web as well as updates, and putting the bulk of the functionality there, you offload the performance needs of server-side only applications to the client. Sure, they have to log in, wait for DB transfers, but the majority of the functionality can be done in the thick client.
This all comes about to perceived perception. It is a well known fact that users are impatient, often after 5 seconds or less of no activity. If you work in an IDE written in Java and scroll a large source file and it lags, most anyone would think "Man, this sucks..its written in Java? Java must suck, its slow STILL!". Sad truth is, a lot of people don't consider the design of the app, how its written, etc. It could very well be a bad 3rd party library that is killing the entire app. It could be a very badly written app. But like someone else said (I think Tim), Java is almost never the culprit. If people would STOP blaming Java itself and look around at some very robust Java built applications, they might think again and realize it very well could be the app they are using is badly written. I have worked with projects that are badly written, they DO slow down significantly. I've also worked with smooth well written products and they are just as bit as fast (to the eye) as any other app I have used.
Another myth, Java has no pointers so memory leaks dont occur is a BIG LIE! In fact, it is VERY easy to cause a memory leak in Java. While some think setting a variable to null is ugly code, shouldn't have to be done, etc, infact they are wrong in most cases. Just gotta learn when to do it. Method scope variables dont need it, but class instance variables are a culprit that hang on to object references even when not needed. Anyway, don't say Java is slow cause hello world runs fast, etc. Like Joseph said, Java DOES have a runtime loading issue that is being partially resolved in Java 5.0 using a shared library or something that will keep parts of the library easily loaded so the startup should be faster. I have heard JDK 1.5 is showing 20 to 30% performance gains on Swing apps with no change in hardware, just a recompile (or maybe even just redeploying).
Like other said, do some testing. Also, testing has to be done in a number of ways. You can't write a couple simple small apps and that shows it all. Test in different areas, and in different ways. Also, test small and large data sets. Like many have shown, Java takes a few seconds or more to really get going. And, unless you are completely stupid, it is very easy to see how a JIT at runtime that knows the hardware it's on can easily optimize and native compile chunks of code at runtime and make them faster than any c/++ compiler can do, not to mention optimize by watching/noticing slow areas and reworking that bit of code to make it faster.
First, as someone told me the other day and it made good sense, web/html is kind of out. When it came in strong, computers were too slow and desktop interaction was limited. HTML fit the bill because you could deploy quickly, and limited user interaction was all that was needed. To be honest, a lot of apps are still better written as web apps than client side applications.
That said, the sophistication of todays applications are much more difficult to develop on the web. While MS hasn't had an update in years and Mozilla/firefox is coming on strong, a few years back there were so many browser issues it made it difficult to develop solid thick-client like apps without a lot of extra code to handle all the versions and nuances. Today its a bit better, and Flash and other tools make it more capable to support. Even so, a site that has to handle 1000s of users means a LOT of hardware is needed. By moving the user interactive GUI rich application to the client with a decent instaler that allows installation via the web as well as updates, and putting the bulk of the functionality there, you offload the performance needs of server-side only applications to the client. Sure, they have to log in, wait for DB transfers, but the majority of the functionality can be done in the thick client.
This all comes about to perceived perception. It is a well known fact that users are impatient, often after 5 seconds or less of no activity. If you work in an IDE written in Java and scroll a large source file and it lags, most anyone would think "Man, this sucks..its written in Java? Java must suck, its slow STILL!". Sad truth is, a lot of people don't consider the design of the app, how its written, etc. It could very well be a bad 3rd party library that is killing the entire app. It could be a very badly written app. But like someone else said (I think Tim), Java is almost never the culprit. If people would STOP blaming Java itself and look around at some very robust Java built applications, they might think again and realize it very well could be the app they are using is badly written. I have worked with projects that are badly written, they DO slow down significantly. I've also worked with smooth well written products and they are just as bit as fast (to the eye) as any other app I have used.
Another myth, Java has no pointers so memory leaks dont occur is a BIG LIE! In fact, it is VERY easy to cause a memory leak in Java. While some think setting a variable to null is ugly code, shouldn't have to be done, etc, infact they are wrong in most cases. Just gotta learn when to do it. Method scope variables dont need it, but class instance variables are a culprit that hang on to object references even when not needed. Anyway, don't say Java is slow cause hello world runs fast, etc. Like Joseph said, Java DOES have a runtime loading issue that is being partially resolved in Java 5.0 using a shared library or something that will keep parts of the library easily loaded so the startup should be faster. I have heard JDK 1.5 is showing 20 to 30% performance gains on Swing apps with no change in hardware, just a recompile (or maybe even just redeploying).
Like other said, do some testing. Also, testing has to be done in a number of ways. You can't write a couple simple small apps and that shows it all. Test in different areas, and in different ways. Also, test small and large data sets. Like many have shown, Java takes a few seconds or more to really get going. And, unless you are completely stupid, it is very easy to see how a JIT at runtime that knows the hardware it's on can easily optimize and native compile chunks of code at runtime and make them faster than any c/++ compiler can do, not to mention optimize by watching/noticing slow areas and reworking that bit of code to make it faster.
Re: Java Faster Than C++? No Way!
You are wrong!
Actually, nobody said JIT was going to make Java faster than C++. But it is correct that some people have said this about Hotspot..... And actually it is sometimes true. If you disregard the VM-startup time, I have personally measured examples of single-threaded java code to be a few procent faster than compiled C-code (using JDK1.4.2+, Visual Studio C++ and defaults compiler settings).
More importantly I belive that heavily multi-threaded JDK1.5 code will be MUCH easier to write efficiently - hence making the app way more performing than comparable c++ apps.
Re: Java Faster Than C++? No Way!
The latest comments illustrate my frustration.
Kevin is rught on when he pointed out that my worries is about the end result.
The paper cited by Somebdy was what prompted me to write this rant (the third item). I did not link to it out of respect for the professors.
Anonymous II's comment about my C++ brain is purely speculative and wrong, bordering on personal attack and he/she/it knows it.
Tim suggested that I should blame the architect/designer/programmer rather than the language. I agree that most of the time performance problems are the result of a wrong design or a wrong implementation. But that should happen equally likely in both C++ and Java and can't explain why Java programs are slower than C++ programs.
I love Java and c++ user's suggestion---"If you disregard the VM-startup time." And I can add a few things to the list: object creation on the heap, all methods are virtual, object references are indirect, no inline methods, every array access has to be bounds checked, the JIT has to count every method invocation, the HotSpot engine has to take time away to do its optimization work, managed (wrapped) access to system/foreign APIs.
I'm not claiming that one cannot write performing Java applications that's adquate for its purpose. I'm just pointing out that the Java programs that I use everyday are not as fast as their C++ counterparts.
Re: Java Faster Than C++? No Way!
I think you misunderstood my comment "If you disregard the VM-startup time". What I really meant was "with the only exception of VM-start up time (mostly a few seconds initially)". All the other issues you mentioned are not disregarded. F.x. the issue you mention: "no inline method" (i.e. compile-time) is not a real performance issue (Actually javac used to do it but now hotspot does it at runtime).
It may be that some of your apps perform slower (probably because they are short-lived - i.e. because of VM startup issues) but that does not mean that Java is slower than C++. In fact in my personal experience it is not.
Re: Java Faster Than C++? No Way!
Weiqi,
Regarding your comment
"Tim suggested that I should blame the architect/designer/programmer rather than the language. I agree that most of the time performance problems are the result of a wrong design or a wrong implementation. But that should happen equally likely in both C++ and Java and can't explain why Java programs are slower than C++ programs."
My point is that I think you are WRONG in stating that Java programs are slower than C++ programs. Like I said, when a program is slow and its Java, Java takes the blame. Slow C++ programs are not blamed on C++.
You are continuing to make generalizations and vague unwarranted assumptions rather than looking at real statistics that people are pointing out to you showing that in reality Java programs are not slower than C++ programs, and in many cases faster.
Tim
Re: Java Faster Than C++? No Way!
Could somebody explain the following fact: I made 2 "Hello world!" programs. One in java and the other in C++.
Java took 10 secs!
C++ took 40 secs!
Java:
class HelloWorld
{
public static void main (String [] args)
{
for(int woei = 0; woei < 200000; woei++)
{
System.out.print("Hello world!");
}
}
}
C++:
#include <iostream>
using namespace std;
int main() {
for(int woei = 1; woei < 200000; woei++)
{
cout << "Hello world!";
}
return 0;
}
Java took 10 secs!
C++ took 40 secs!
Java:
class HelloWorld
{
public static void main (String [] args)
{
for(int woei = 0; woei < 200000; woei++)
{
System.out.print("Hello world!");
}
}
}
C++:
#include <iostream>
using namespace std;
int main() {
for(int woei = 1; woei < 200000; woei++)
{
cout << "Hello world!";
}
return 0;
}
Re: Java Faster Than C++? No Way!
Not really, i test java 20k helloworld and C++ 20k helloworld, and this is the result:
[kiswono@it ~]$ time java -cp . HelloWorld > test-java.txt
real 0m1.479s
user 0m0.569s
sys 0m0.909s
[kiswono@it ~]$ vim HelloWorld.cpp
[kiswono@it ~]$ g++ HelloWorld.cpp
[kiswono@it ~]$ time ./a.out > test-C++.txt
real 0m0.049s
user 0m0.036s
sys 0m0.013s
Re: Java Faster Than C++? No Way!
std::cout has to share buffers with C stdio, so its default buffering really sux, it may be sending the output in every iteration which is horribly slow
to disable the shared buffering, write this line of code before any use of std::cout
std::ios_base::sync_with_stdio(false);
this will speed up std::cout dramatically, but you can no longer use stdio
Re: Java Faster Than C++? No Way!
Can we categorize the question further more?..
a) Java Faster Than C++? -- with respect to small applications/code.
b) Java Faster Than C++? -- with respect to medium applications/code.
c) Java Faster Than C++? -- with respect to large applications/code.
So can i know the answer for the above?
a) Java Faster Than C++? -- with respect to small applications/code.
b) Java Faster Than C++? -- with respect to medium applications/code.
c) Java Faster Than C++? -- with respect to large applications/code.
So can i know the answer for the above?
Re: Java Faster Than C++? No Way!
asm(non-portable, wastes most time, dangerous, system compromise in 1 month)
C/C++(semi-portable, wastes lots of time, extremely dangerous, system compromise in 3 days)
Java(99.9% portable, faster than C/C++/assembler in theory, almost as fast or faster in real life, fast to code, no risk of system compromise, even has proper sandbox security)