[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compilation to native

From: Matthew Mundell
Subject: Re: Compilation to native
Date: 16 Apr 2004 15:20:47 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]