Re: Compilation to native

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

David Kastrup <dak@gnu.org> writes:

> Matthew Mundell <matt@mundell.ukfsn.org> writes:
[...]
>
> > This is for the record, at least.  The speedup is a little better
> > with Fgtr inlined into the native, a few excess memory instructions
> > saved, and, where possible, objects passed between byte operations
> > using registers instead of the stack.
> >
> > Byte compiled:
> >   ("Tue Mar 30 21:54:05 2004" "Tue Mar 30 21:54:21 2004")  16 s
> >   ("Tue Mar 30 21:54:26 2004" "Tue Mar 30 21:54:42 2004")  16 s
> >   ("Tue Mar 30 21:54:45 2004" "Tue Mar 30 21:55:01 2004")  16 s
> >
> > Compiled from byte code to native:
> >   ("Tue Mar 30 21:55:43 2004" "Tue Mar 30 21:55:49 2004")  6 s
> >   ("Tue Mar 30 21:55:51 2004" "Tue Mar 30 21:55:58 2004")  7 s
> >   ("Tue Mar 30 21:56:01 2004" "Tue Mar 30 21:56:07 2004")  6 s
>
> This sounds impressive, but of course in real-life tasks the amount of
> work done by the Lisp interpreter as opposed to C primitives should be
> less.  One would have to see the memory impact as well to find out
> whether the overall gains in processing speed would remain as
> impressive.

Well, compiling to native creates a primitive.  Inlining in the
generated code causes a size increase in the same way as inlining does
in the static code.

The dynamic native example is about 1000 bytes.  An equivalent
primitive runs in under a second and is about 200 bytes.

Some of the differences in speed and size will be due to the way the
Lightning macros immediately write out instructions, compared to the c
compiler's use of an intermediate representation.

I think the rest comes down to how much work the dynamic compiler puts
into the compilation, and the information available at compile time
about the context of the Lisp code.  Perhaps passing variable type and
binding information to the compilers will improve the differences.  I
think Juri's reference to the CL declarations suggests this.