Re: [Hampshire] [Tech] The 'speed of a language'

On Thu, Oct 30, 2008 at 08:30:02AM -0000, Stephen Rowles wrote:
> > Things like the Hot Spot compiler in Java, which can re-optimise
> > byte code as the program is running depending on how its actually
> > being used can complicate things (ending up with Java performing
> > better than C in *some* circumstances).

That will never happen. Java can approach C's performance in some
circumstances, but Java /always/ carries an overhead. The JVM is simply
not designed to match C's speed. For example, Java arrays are always bounds-
checked.

The hot-spot compiler is not a tool for doing extra super-duper
optimisation of frequently used code but for saving time by avoiding
optimisations on infrequently used code. You can assume that a C compiler
always fully optimises everything.

> That's one of the problems with performance optimisation. You cannot
> optimise everything (for a large software project you never have time) so
> you have to work on the areas you think are important / used the most. Of
> course if you get the wrong areas, then it doesn't help ;).

This is true but it's a completely different type of optimisation, one
that cannot be done automatically. Compilers can fully perform
instruction-level optimisation, but they won't rewrite an O(n²) algorithm
to an O(n log n) algorithm, which is usually the kind of optimisation
programmers usually look for when they are coding.

The circumstances where Java will run faster than C are the latter type
of operation: JFC gives programmers a far better library than the STL,
meaning it's easier to write code with better asymptotic complexity in
Java.

Dan