|By Java News Desk||
|June 18, 2004 12:00 AM EDT||
On Monday we published an article about Keith Lea's one-man attempt to take the benchmark code for C++ and Java from the now outdated Great Computer Language Shootout conducted by Doug Bagley in Fall 2001 and run the tests himself. Within 12 hours 40,000 people had read the piece and by the end of the day Bagley's "Shootout" had even been revived as an ongoing Debian Alioth project.
But while the team behind that project cheerfully says on its Web site "Contributions are welcomed for revised implementations, bug fixes, or ideas for new benchmarks," not everyone agrees with this kind of activity.
When Bagley did the original shootout, he said it was "To learn and to have fun," adding that he would continue continue "as long as the fun holds out." This notion of enjoyment has been revived by the Debian Alioth update:
"The project goals have not changed substantially since Doug's original project. This work is continuing so that we all can learn about new languages, compare them in various (possibly meaningless) ways, and most importantly, have some fun!"But many of those who troubled to record their views in the course of the past few days did not recognize benchmarking/microbenchmarking as anything worth doing at all.
Some took issue with Lea's choice of performance speed as the parameter to compare Java and C++. One, Lachlan Stuart, wrote:
"What you must realize is that C++ and Java have much different targets, it's rare that you will encounter a situation where both are equally suitable. No matter what, unless you forget to turn debug compile off, C++ will beat Java in real world situations on the performance front..."
"Try praising something else about Java...like its security, or ease of programming," Stuart continued.
GooberToo concurred. "The more I read the code, it sure is starting to look more and more like an apples and oranges comparison; which is usually what happens when people do Java benchmarks." And Iain too was unhappy: "Aside from perhaps demonstrating that you know Java far better than you know C++, I don't think these tests were a particularly useful exercise."
Others too felt that Lea's relative unfamiliarity with C++ compromised the exercise. "This article is completely useless and only shows the lack of understanding of C++ by the author," wrote Dr Valentin Samko. "This reminds me of a person who clamed that qbasic is faster than C++ because his program which outputs a few million blank lines works faster in qbasic than in C++."
Glen Low queried the shootout's methodology on a number of counts. Here is one:
"The small size of the programs are a definite advantage for Java's runtime optimizer. A run-time optimizer can't spend forever optimizing, but it has access to actual run-time data, AND can specialize its optimization for the specific processor. (G++, and most other C++ compilers, have flags to allow this as well.) Given the small size, a complete analysis of the program is possible in the limited time available, and given the other additional data, I would find it rather worrisome if Java didn't do better. I'm more sceptical with regards to real programs, however. If there really is one small critical loop, Java should win; that's not the case for most of my programs, however."Scott Ellsworth disagreed with those who dismissed Lea's shootout, though. "The point is that many C++ users feel that Java is too slow and uses too much memory. Microbenchmarks like this show that this off the cuff response is as silly as claiming that exceptions cost too much just because cfront compilers had that cost," he wrote.
"I spent seven years doing C++ in a shrink wrap environment, and five doing Java. In my experience with real world apps, Java code gets done faster, works better out of the box, and is easier to maintain. Tricks like custom memory allocators and carefully crafted templates can make faster C++ code, but I reserve those for time critical parts of the program. Where I do not spend some programmer cycles profiling and optimizing, the two environments are pretty close.Patrik Beno issued a challenge. "I suggest that now it's time for C++ experts to optimize C++ code and compilation, run the very same tests again and post the results."
Thus - if Java is producing code reasonably close or ahead in fairly straightforward usage, and the code gets written faster and more portably, then Java is a win for my work. I can always choose to use C++, assembly, or FORTRAN for the time critical routines, and then link in."
"Don't blame Lea, he did his best, now it's your turn, C++ experts," he added.
Perhaps SWagner would be someone who will rise to the challenge in due course. S/he wasn't at all happy with Lea, writing:
"As an experienced C++ developer (and Java as well) I only see that the C++ code is optimized for minimum performance. Especially the methodcall where the class has virtual constructors or destructors which is seldom useful and significantly hurts performance. Just because you can't turn this off in Java does not mean that you have to make it slow in C++.""In my practical experience," continued Wagner, "normal Java code is 1000 times slower [compared] to OPTIMIZED C++. However if you make severe design flaws you can make any program slow. And if you base on a bad benchmark and make it even worse you should better stop any benchmarking you planned for the future."
Somewhat less disgruntled was m, who wrote: "The benchmarks are interesting, but frankly with real applications, I have never experienced Java performance equal to or better than that of C++."
"I have done a number of home-grown benchmarks for XML parsing, and C/C++ (think expat) are 3-9 times faster," m continued. "The difference there is that the server JVM does indeed optimize over a series of many runs. Java certainly allows us to develop faster, and quite often time to market performance is more important than the performance differences in these two (great in my opinion) platforms. They each have specific advantages."
This, not surprisingly, was the essence of quite a few of the comments. "Java is faster for some applications than C++, and for others C++ is faster. It depends on what you want to do with it," said RebelCool.
But Iain's objection was to the choice of tools to compare, to the entire premise of the shootout in other words:
"The comparison [Lea is] trying to make between C++ and Java is not particularly meaningful. At the end of the day, if a VM is faster, then there is nothing to stop you implementing a VM in C++ and running the 'C++ program' within that framework. What times would then be valid? The tools you are comparing are very different.
In addition, the C++ code is seriously sub-optimal. To take one example, the 'matrix.cpp' is definitely not written for speed. A general purpose C function is being used to repeatedly allocate rows, when a single large block of size 'mn' could have been used. For that matter, why is malloc( ) being used at all? (A custom memory manager optimised for small blocks could have been used instead - malloc( ) is slow.)
If you insist on writing simple C, then at least use memset( ) for the zeromatrix( ) function. Fast template matrix libraries exist for C++ - these could have been used instead - the result would have been shorter, clearer and considerably faster. Aside from perhaps demonstrating that you know Java far better than you know C++, I don't think these tests were a particularly useful exercise."
NotZed disagreed with the premise too, writing: "Java works well as a COBOL replacement, a backend application language for boring buisiness apps. That's what it should be benchmarked against. Comparing it to C is like comparing apples and oranges."
Chris countered: "Surely the benchmark is no less meaningful than when it was originally used to show C++ was faster than Java."
And Christopher White commented:
"Thanks for the comparison Keith. I enjoyed reading your commentary.
Many people have stated in response to this article that Java, as everyone knows, is slow... This is certainly not the case. I am team leader of a Java development team. We have six applications in production on a certain open source application server. We have 1200 users of these applications. The applications are load-balanced over two machines (each machine : HP DL380 2*2.8GHz 2Gb RAM). We have on average 2% Cpu utilisation. Whilst this is of course just a subjective view of Java performance, I can say that we certainly do not have the impression that Java is at all slow.
I accept that for memory deallocation C++ can be tailored to the needs of the application at hand so it will be difficult to beat on this score, however one must remember that the just in time compiler compiles code into native machine language and that this compiler is very much optimized on a per platform basis so I don't see why C++ should produce naturally faster compiled code.
Whichever is faster, Java is easily fast enough for most applications and I strongly believe that the overhead in development time incurred by using C++ is rarely justified except in specialized applications such as driver or game coding."
For the moment let's give the last word to SB:
"Java and C++ are different languages, with different advantages/drawbacks, and different philosophies. My experience, from a large company that produces tons of software, is that performance always comes down to the quality of the developers, not the language itself. And we also found out that in today's world, most developers are only average, and this class of developers yields better results with Java than C++."The debate, as they say, will doubtless continue...
|icube 06/29/04 05:47:18 AM EDT|
shootout has a great interest but not between C++ and java but between ocaml and java .... :-))))
be aware & wake up !!!
|microbenchmarks 06/21/04 06:47:50 AM EDT|
Doug Bagley''s original Great Computer Language Shootout was a neat idea: a collection of little benchmarks written in several dozen languages for the purposes of comparing speed, memory usage, and lines of code. He used to say that his favorites of all the languages were those in the ML family, and in particular Ocaml.
|Robert McGovern 06/20/04 04:33:36 PM EDT|
comp.lang.c++.moderated list at Google Groups. At least be accurate and say on the newsgroup comp.lang.c++.moderated, rather than push the notion that the group is only available via Google groups.