Compiling byte code to native

Compiling byte code to native

[Matthew Mundell]

The native compilation effort introduced earlier this year is archived
at http://www.mundell.ukfsn.org/native.  It can now compile all the
byte codes.


Here are three speed comparisons.  The commas in the middle column
separate runs.

               microseconds                    size in bytes
copy-tree
   Byte       21, 21, 20, 21, 18                    100
   Native     28, 14, 14, 16, 17                   2332

last
   Byte       15, 15, 16, 14, 15, 14                 65
   Native     12, 12, 12, 13, 19, 9                1605

native-test-info-eg-loop-small [1]
   Byte       187, 231, 233, 235, 235, 237, 485      13
   Native     113, 158, 164, 172, 173, 186, 225     302

So the speedup over byte code is available, but it seems that in most
cases it will be over-shadowed by the time spent in primitives.


It may be good to update the TODO entry:

** Investigate using GNU Lightning or similar system for incremental
   compilation of selected bytecode functions to subrs.  [There is an
   effort archived at http://www.mundell.ukfsn.org/native that can
   compile byte-code functions to native.]

In the future perhaps this work could be a base or reference for
adding compilation of functions to primitives.


Thanks.


[1] Passing 1000 to:

(defun native-test-info-eg-small (n)
  "Return time before and after N iterations of a loop.
This is the info manual's byte code speed example."
  (let ((t1 (current-time-string)))
    (while (> (setq n (1- n))
	      0))
    (list t1 (current-time-string))))

Re: Compiling byte code to native

[Stefan Monnier]

> The native compilation effort introduced earlier this year is archived
> at http://www.mundell.ukfsn.org/native.  It can now compile all the
> byte codes.

The speedups are disappointing, but I'm not surprised: most byte-code
operations end up calling non-trivial C functions.

Maybe the results would be a bit more encouraging if you tried to compile
lexbind byte-code (where local variables are kept on the byte-code stack
rather than being varbound&varref'd).


        Stefan

Re: Compiling byte code to native

[Matthew Mundell]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > The native compilation effort introduced earlier this year is archived
> > at http://www.mundell.ukfsn.org/native.  It can now compile all the
> > byte codes.
> 
> The speedups are disappointing, but I'm not surprised: most byte-code
> operations end up calling non-trivial C functions.
> 
> Maybe the results would be a bit more encouraging if you tried to compile
> lexbind byte-code (where local variables are kept on the byte-code stack
> rather than being varbound&varref'd).

This would be quite similar to compiling to a primitive, where the
arguments will have to be lexically scoped.  It may show an
improvement over the standard byte-code, but the lexbind byte-code may
show a similar improvement.

Re: Compiling byte code to native

[Stefan Monnier]

>> Maybe the results would be a bit more encouraging if you tried to compile
>> lexbind byte-code (where local variables are kept on the byte-code stack
>> rather than being varbound&varref'd).

> This would be quite similar to compiling to a primitive, where the
> arguments will have to be lexically scoped.  It may show an
> improvement over the standard byte-code, but the lexbind byte-code may
> show a similar improvement.

I do expect lexbind byte-code to be slightly faster than dynbind byte-code,
but I also expect that the speed up you get from compilation to native code
will be even larger with lexbind byte-code than with dynbind byte-code.

This is because lexbind byte-code uses more stack-access operations which
are very simple and thus quick to execute and because such quick byte-code
operations have a relatively larger interpretive overhead (because the
overhead is constant per operations, so it's relatively higher for simple
operations).


        Stefan

Re: Compiling byte code to native

[Matthew Mundell]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> Maybe the results would be a bit more encouraging if you tried to compile
> >> lexbind byte-code (where local variables are kept on the byte-code stack
> >> rather than being varbound&varref'd).
> 
> > This would be quite similar to compiling to a primitive, where the
> > arguments will have to be lexically scoped.  It may show an
> > improvement over the standard byte-code, but the lexbind byte-code may
> > show a similar improvement.
> 
> I do expect lexbind byte-code to be slightly faster than dynbind byte-code,
> but I also expect that the speed up you get from compilation to native code
> will be even larger with lexbind byte-code than with dynbind byte-code.
> 
> This is because lexbind byte-code uses more stack-access operations which
> are very simple and thus quick to execute and because such quick byte-code
> operations have a relatively larger interpretive overhead (because the
> overhead is constant per operations, so it's relatively higher for simple
> operations).

Right, I get what you're saying: the smaller lexbind variable ops will
reduce the time spent in primitives, which favours the native
functions.  And the frequent use of the variable operations may make
the improvement substantial.

It's a bit much for me to try now, so I'll consider it again in a few
weeks time.

Re: Compiling byte code to native

[Richard Stallman]

I simply deleted that TODO entry, since it looks like this optimization
isn't worth a big effort.  Computers are so fast nowadays that Emacs
Lisp code hardly needs speeding up.

I only regret that you had to spend time on an optimization that turns
out not to be fruitful.  Thank you for working on it.

Re: Compiling byte code to native

[Matthew Mundell]

Richard Stallman <rms@gnu.org> writes:

> I simply deleted that TODO entry, since it looks like this optimization
> isn't worth a big effort.  Computers are so fast nowadays that Emacs
> Lisp code hardly needs speeding up.

The goal of the entry may also have been to ease the development of
Emacs' internals by introducing Elisp primitives.  Dave Love added the
entry.

> I only regret that you had to spend time on an optimization that turns
> out not to be fruitful.  Thank you for working on it.

Pleasure.  It was by choice, and well worth it for the experience.