Re: [xml-dev] Speed in Languages and Browser Architectures

[Elliotte Harold <elharo@metalab.unc.edu>]

Rick Marshall wrote:

> The implication is that Java can create a sequence of instructions that 
> C can't.

Essentially it can. Runtime (JIT) optimizers know things static 
optimizers don't. They can sometimes tell that a particular code path 
will not be taken or that an object has a certain type or other useful 
information that is simply not known to the static, compile-time 
optimizer. They can sometimes use such information to run even more quickly.

The nature of the languages also plays a part. Pointer aliasing is a big 
problem for C and C++ optimizers. It's a reason Fortran outperforms C, 
even with the same compiler. Java doesn't have C-style pointers so it's 
more like Fortran in that regard.

And of course manual memory allocation is almost always slower and less 
reliable than a good garbage collection library. You can use a garbage 
collection library for C/C++, but few programmers do in practice.

Together these are enough to push Java a couple of percentage points 
ahead of C on some problems. Not all problems, certainly, but enough of 
them that you can't just naively assert that C must be faster than Java. 
  That may have been true in 1997. Today it demonstrably isn't.


-- 
Elliotte Rusty Harold  elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/