Re: Compilation to native

[Matthew Mundell <matt@mundell.ukfsn.org>]

Stefan Monnier <monnier@iro.umontreal.ca> 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.