OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Speed in Languages and Browser Architectures

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!

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS