[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.
- Re: Compilation to native, (continued)
- Re: Compilation to native, Stefan Monnier, 2004/04/13
- Re: Compilation to native, Matthew Mundell, 2004/04/13
- Re: Compilation to native, Miles Bader, 2004/04/13
- Re: Compilation to native, Miles Bader, 2004/04/13
- Re: Compilation to native, Matthew Mundell, 2004/04/14
- Re: Compilation to native, Matthew Mundell, 2004/04/16
- Re: Compilation to native, Miles Bader, 2004/04/13
- Re: Compilation to native, Matthew Mundell, 2004/04/16
- Re: Compilation to native, Stefan Monnier, 2004/04/16
- Re: Compilation to native, Matthew Mundell, 2004/04/16
- Re: Compilation to native,
Matthew Mundell <=