Related link: http://kontrawize.blogs.com/kontrawize/2006/01/i_can_still_rem.html
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
Hi,
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).
Microsoft for example generates in some cases specialized XML Parsers.
Regards,
Markus
Re:
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.
Not that any of this means much, because in either case a lot depends on the application.
what drivel
Clearly an XML/XSLT ide is not going to run as fast as a pure XSLT processor.
Shall we start comparing eclipse and vi?
And the nonsense about byte code generation is not true either... a native application could implement it's own byte code interpreter and compile XSLT (or whatever) to that.
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:
He provides no statistics or benchmarks to back up his assertions
He doesn't use the same computer for the time comparisons. Yes, CPU, operating system, and memory can be important factors.
No version information is provided. For example, the version of XMLSpy is very important as its support for XSLT 2.0 seemed broken.
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.
Sigh.
Two things. First, static compilation is not a magical process. Java and C eventually become processor-specific bytecode; they just do it at different times. C does it at compile time, Java does it all at application startup (JIT) or in bits and pieces at runtime (Hotspot). It may also be possible for Hotspot to make decisions at runtime about how to use registers and memory that are better than what can be known at compile-time. Maybe. At any rate, when I see people running their Java code through GCJ and then complaining it's not any faster, it serves to make my point that all they're doing is moving the compile time.
Second: context. If C is arguably faster than Java, it's definitely harder to write and less productive. Each language chooses its own sweet spot. Assembly is clearly faster and harder than C. Ruby is (probably) slower but arguably easier (more productive) than Java. What matters for your application?
noob
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.
Since then, C++ performance has been revolutionized by the provision of "Intrinsic" functions, which allow access to processor specific parallel/pipelined instructions without resorting to assembler. Java basically doesn't/cannot use these, because it completely goes against the WORA theme.
There absolutely no way that Java can compete with the new C++ with intrinsics, at least for tasks that suit intrinsics (e.g. FP intensive, parallelizable). As the non-SSE generation of x86 processors joins the scrap heap, more libraries will be written using them, and the Java vs C++ performance differential will become significant again.
Rick Jelliffe