Native code no longer any faster than Java?
by Michael(tm) Smith
Tony Coates relates an incident in which he found a Java-based implementation to be at least ten times faster than a native-code implementation. He concludes that native code solutions "can no longer claim an automatic performance advantage".
He states in a little more detail:
What does this all mean? Well, I'm not suggesting that Java programs are always faster now than their native code equivalents. That isn't the case. What I am suggesting is that it is no longer valid to assume that native code solutions are faster than Java (or other virtual machine) solutions. Some solutions will be faster than others, but you won't know if native code is faster or slower than virtual machine code now without actually testing it. That is a significant change, which impacts the way architectural technology choices are made for projects.
I think he might probably have chosen a bit of a better example to illustrate his point. What he actually compared was a XSLT 2.0 test case, and the implementations he tested were XML Spy (C or C++ code, I assume) and Mike Kay's Saxon 8.
First off, given that Mike Kay was the editor for the XSLT 2.0 spec and that he literally "wrote the book" (his XSLT Programmers Reference) on both XSLT 2.0 and XSLT 1.0 and that Saxon 8 can basically be considered the reference implemenation for the XSLT 2.0 spec, it ain't too surprising to find out that it significantly outperforms a native-code implementation in another application.
And I would suspect that another possible factor is that the XSLT 2.0 implementation in XML Spy may just not be particularly well written. Hard to check though, since it's proprietary code. And we lack an open-source C or C++ implementation of XSLT 2.0 to do any comparing with. If we did -- if, say, Daniel Veillard (the principal developer of libxml2 and libxslt) were to decide to write an XSLT 2.0 implementation -- I reckon that implementation might also end up being a helluva lot faster than the XML Spy implementation.
I don't know how many smart people were ever given to
just "assuming" that native code solutions are always faster than Java-based (or other VM-based) solutions. But I think most have seen from experience that a well-written natively compiled application, especially one written in C, is likely to be measurably faster than an equally well-written implementation in Java.
Time to finally give up and write everything in Java?
In java you can generate bytecode
I mostly agree with your statement that well written C++ code would probably as fast. But you in Java you could ( and maybe Saxon does it) generate specialized bytecode at runtime, which could potentially outperform C++. You cannot normally do that in C++ (unless your are running on .NET).
In light of JIT compilation, that statement doesnít make much sense. And Iíve seen significantly more apples-to-apples comparisons that conclude that JIT+HotSpot can make bytecode run faster than native machine code; hardly surprising, too.
Clearly an XML/XSLT ide is not going to run as fast as a pure XSLT processor.
A decent amount of skepticism is needed
So, if I can run a program faster on a mainframe, I should switch to using a mainframe?
The example that Mr. Coates provides is so wrong in so many ways that it cannot be expressed. Here's just a few of the problems:
Another thing to remember is the purpose of the applications. XMLSpy is an editor, a development tool, if you will, for XML. While it is likely good for that purpose, a high performance XSLT engine is probably a lower priority than usability. Saxon, however, is an XSLT engine designed and tuned for that purpose alone. Stating that Java is faster than native code based on his observations is rather reckless and unfounded. This is another case where a healthy dose of skepticism goes a long way.
Practically a tautology
So, the discussion of this basically goes:
1. Here's a crazy outlying data point
2. It really shouldn't count
3. Because we all know C is faster than Java
4. Therefore C is faster than Java.
I don't usually go in for lightin' people up for posting silly log entries - but when faced with possibly the most inane argument in the sea of dumb@ssitude that is the "blogsphere", I just can't help myself.
And I will post it here because apparently 1000 other people got to Tony's site before me and brought the mother down.
Now I've lost interest, there is nothing I can do to poor ole Tony that he hasn't already done to himself ...
No intrinsics in Java
Java can certainly be as fast (and slow) as C++ programs, but that is for portable C++ programs as written 5 years ago.