Re: Scripting

[Katie Lauren Lucas <katie@fysh.org>]

Quoting Jorrit Tyberghein <Jorrit.Tyberghein@uz.kuleuven.ac.be>:

> I also don't agree with this completely... With Java there is now
> technology
> that does compilation at runtime (JIT and HotSpot technologies). This
> allows
> 'interpreted' languages to become FASTER than C++ in theory (see the
> word 'in theory') because at run time you have information about the
> program
> that at compile time simply isn't present. For example, HotSpot
> optimizes
> code at run time if it sees that code is used a lot. There is still a
> lot of research
> going on in these areas but in theory the potential is there so that
> interpreted
> languages could (in future) run faster than compiled languages just
> because
> a compiler doesn't have sufficient information to optimize without the
> program running.

I've always felt this claim a little dubious: even assuming your optimiser 
takes near-zero time, time is consumed taken detecting the "hotspots", and I 
don't quite see how any code optimisation could be produced at run-time that 
couldn't be produced at execution time, apart from (possibly) unrolling loops 
based on run-time data...

I don't see how having informayion about which bits of code are used a lot is 
any help - a compile time optimiser optimises the entire thing.

The claim appears to be akin to "I can produce faster code in less time than 
any optimiser you can write". I can't see how any body of executable code a hot-
spot optimiser could insert into a program could in itself be faster than the 
same optimised code produced by a pre-execution optimiser based purely on know 
how often it's executed.


{Actually, having thuoght about it, unless you can actually solve the halting 
problem you CAN'T do things like unroll loops knowing they're always called 
with the same count - you only know that that's the case at program 
termination. (You could /guess/ but that's not the same). If you can solve the 
halting problem hot-spot and traditional optimisers will give you the same 
results.}

_______________________________________________________________________________
      Katie Lauren Lucas, Consultant Software Engineer, Parasol Solutions
katie@fysh.org katie.lucas@parasolsolutions.com http://www.parasolsolutions.com