Re: Compilation to native

[Matthew Mundell]

Matthew Mundell <address@hidden> writes:

> Stefan Monnier <address@hidden> writes:
>
> > > This optimisation more than doubles the speed of the generated
> > > function.  The optimisation adds two new byte operations.  As a start
> > > the new operations always take parameters that are four bytes wide.  I
> > > think the loading of these four bytes is the cause of the slower byte
> > > interpretation.
> >
> > I don't understand.  Could you give us more info about what those new byte
> > ops are and what they're used for (and maybe why you think they make things
> > slower in the byte-interpreter, tho I should be able to figure that out on
> > my own at that point).
>
> The optimisation moves variable referencing and setting out of loops.
> The Lisp objects are instead referenced onto the stack before the
> loop, and set from the stack afterwards.  The new operations are used
> inside the loop to access or set an object on the stack.  The
> operations both take a parameter which indicates how far below the top
> of the stack the object is.  The parameter is the four bytes in the
> byte stream which follow the operation byte code.  In the byte
> interpreter this means four more loads for each reference and for each
> set, on every iteration of the optimised example.  I think this is the
> cause of the 3 extra seconds in the interpretation of the optimised
> byte code.
>
> The purpose of doing the optimisation was to speed up the native code
> generated for the test example.  Always using four bytes was the
> quickest way to do it.  Now that it is done I'll try for a better
> parameter mechanism.  A possibility is to do it like the varset and
> varref operations where the operation byte code identifies the number
> of parameter bytes to follow.  I'm guessing that afterwards the byte
> interpretation of the test example will be at most a few seconds
> faster than before the optimisation.  It'll be interesting to see.

Using varset-like op code parameters for the stkset and stkref
operations makes the byte interpretation of the optimised example a
second faster than usual.  So the loading of the four bytes was the
cause of the extra 3 seconds.