Re: Scripting

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

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

> Katie Lauren Lucas wrote:
> 
> > 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.
> 
> It is not only execution time. That was only an example. There are
> several
> (theoritical) things a HotSpot compiler can do:
> 
>   - For an 'if' branch you can at runtime know how much chance there
> is
>     that the 'if' will be positive or negative. Based on that
> information you can
>     choose to optimize differently. At compile time this is often
> nearly
>     impossible to know.

No you can't. Well, not unless you're willing to accept being wrong: you only 
know the count of routes through that if statement at program termination. 
Before that, you're going to get it wrong some of the time.

If you're willing to have it wrong, I don't quite see how you're going to get a 
better hit than a general optimiser.

Note also that program execution behaviour evolves over a program run: what's 
true at 20s in won't be true at 100s in...

>   - If you have a function that takes some 'int' parameter (just an
> example)
>     you can detect at runtime that the int parameter is usually between
> 1 to 10.
>     In general a compiler cannot know that. If there is a switch in that
> routine
>     you can then optimize/compile that switch based on the information
> that
>     the number is usually between 1 and 10.

How can you know that? Knowing that before program termination is akin to 
solving the halting problem. Again.

> > {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.}
> >
> 
> First, note that the halting problem applies only to infinite computers
> (turing
> machines). In practice computers are finite (finite memory states) so
> the
> halting problem is solveable (but inpractical) in practice.
> 
> Second, I don't think the halting problem has anything to do with
> this.
> If you predict that some loop is called 10 times usually then you can
> optimize to that. But that doesn't mean the loop will not work when
> called
> 20 times. Also loop unrolling is only ONE small aspect of what a
> HotSpot
> capable technology can do. See above for two other examples.
> 
> Greetings,
> 
> --
> ==============================================================================
> Jorrit.Tyberghein@uz.kuleuven.ac.be, University Hospitals KU Leuven
> BELGIUM
> 
> The labyrinth of Ephebe is ancient and full of one hundred and one
> amazing
> things you can do with hidden springs, razor-sharp knives, and falling
> rocks.
>         -- (Terry Pratchett, Small Gods)
> ==============================================================================
> 
> 
> 
> 



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