Performance Benchmarks of Nine Languages
ikewillis writes "OSnews compares the relative performance of nine languages and variants on Windows: Java 1.3.1, Java 1.4.2, C compiled with gcc 3.3.1, Python 2.3.2, Python compiled with Psyco 1.1.1, Visual Basic, Visual C#, Visual C++, and Visual J#. His conclusion was that Visual C++ was the winner, but in most of the benchmarks Java 1.4 performed on par with native code, even surpassing gcc 3.3.1's performance. I conducted my own tests pitting Java 1.4 against gcc 3.3 and icc 8.0 using his benchmark code, and found Java to perform significantly worse than C on Linux/Athlon."
Visual C++ (an MS compiler/IDE) comes out on top.
Java1.4.2 works as good as native code.
Benchmarked on the Microsoft operating system!?!?!
Lemmie go ahead and tell you the responses:
They cheated on the benchmark!
I ran my own benchmark and gcc rocked the casbah!
Java is just slow starting and takes up too much memory.
This article, itself, is flamebait.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Also
I can write a c#.net app in 1/4th the code of a java one. Go take a look at Microsoft's petshop program if you do not believe me.
ALso WIndows2k3 is as stable as Linux now. NT4 is old. The situation has improved dramatically. I have never even seen a blue screen on windows2k yet!
http://saveie6.com/
The real puzzlement in this test is that all their tests (except IO) is independant code that is trivial to compile with a JIT. One area all these languages lags behind a native GCC code is memory allocation.
The garbage collector, while adding programming comfort, is also adding a huge overhead. Of course, that was conveniently left out. I guess the author wanted to make a point rather than get a real-life test. I mean, in the real life, unless you are talking scientific application, you will deal with a great amount of memory allocation, not a 1000000 loop iteration to compute some kind of meaningless number.
Write boring code, not shiny code!
This comment alone marks you as a troll, but I'm bored so I'll reply to you anyway.
Java isn't and never will be as fast as C/C++
This is pure nonsense. JIT compiling is one of the most exciting research areas in practical computer science at the moment. With a pre-compiled program, written in a static language such as C or C++ the compiler has only one shot at optimising it and has to do so with no knowledge of the data on which the program will be executing.. With a JIT compiled program, it is possible to continue to optimise the code as it runs. This means that the code will be slower the first time it runs, but (theoretically at least) will get gradually faster over time. An analogy for this would be the difference between defragmenting your hard drive once at boot time, which will give you a one-shot performance boost, and dynamically re-allocating files so that the most used ones are on the fastest parts of the disk, which gives you a performance hit at first but then a gradual performance over time as the system optimises your disk.
I am TheRaven on Soylent News
If safety is critical, don't use any C variant. Really, 99% of security problems can be attributed to stuff the java virtual machine prevents from ever happening (e.g. buffer overflows). This type of error is routinely discovered even in C programs that have been subjected to multiple code reviews (e.g. some of the server software that is shipped with BSD). In a C/C++ program, discovering an error at run-time is usually fatal whereas in Java you simply handle the exception (and of course you build in some stuff to recover nicely from such unfortunate events).
As others have pointed out, templates are planned for the next Java release (in addition to a number of other nice language features). Compared to C++, the Java version of templates is particularly strong on typesafety (which in Java was a hard requirement whereas in C++ it is just convenient to have). If you go to javalobby.org, you can sign up for an alpha release of the jdk1.5. Alternatively, you can download some extensions that will work with existing versions of java.
Anyway, there are real-time variants of Java if you need hard real time and for soft real time stuff you can configure the garbage collector to be less of a pain in the ass (with a few percents performance penalty). Garbage collection used to be a problem when SUN still used a very naive garbage collecting algorithm, that was fixed long ago.
Jilles