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
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
