Re: Scripting

[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.

  - 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.

i.e. there is a lot more than that. In theory there are lots of optimizations that
you can do at runtime which are nearly impossible to do. Counting how many
times a loop occurs is just once example. Note that this is all very hard to
actually implement and they are not there yet. At this moment this is mostly
theoretical although some parts of this already work.

> {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)
==============================================================================