Re: What's the current recommendation for speeding up bits of guile code.

[Marius Vollmer]

Rob Browning <address@hidden> writes:

>   * Lightning seems like it's a fairly long-term solution.  Any idea
>     how long it might take to get something useful working, and is
>     there a way it could be phased in, with useful results more
>     immediately?

It's a lot of work, but hopefully fun enough.  Most of the work should
have already been done, in the compilers for the byte code VMs, and in
other Scheme compilers.  The Lightning specific work consists (as far
as I can see) mostly of having a tail-callable calling sequence (yes,
I insist on this ;-) and having a way of relocating machine code
(after loading it from disk).  This will probably require changes to
Lighnting itself, but not major ones.

>   * Since lighting is only really ready for x86 right now it's
>     probably not a strong option for gnucash at the moment.  I suppose
>     we could just consider it a performance enhancer that didn't work
>     everywhere, but I'd rather not do that to our powerpc/sparc/etc
>     users (even if few) if we don't have to.

But it would also be a good opportunity to bring the Sparc and PowerPC
backends of Lightning up to snuff, no?
 
>   * Finally, ightning doesn't address the issue of more agressive
>     (static) compilation a-la gcc or stalin since it doesn't do (and
>     doesn't plan to do) broader code analysis[1].  Is there any
>     interest in that down the road i.e. perhaps a (compile-file foo)
>     or (compile-function foo) call that hands the code over to a
>     stalin-like compiler or generates C directly for gcc?

They way I would want to use Lightning is not strictly as a JIT, but
as a `portable assembler'.  The compiler that would generate Lightning
code can still do a lot of analysis.  For example, we might be able to
hack Stalin to generate Lightning code instead of C (and be able to
compile in a non-closed world).

Of course, we can't beat the architecture specific knowledge in GCC
that way, and it is wrong to not use GCC, in a way, but I for my part
want to explore the road of a `real', interactive Lisp compiler.  GCC
is too much batch oriented for that, in my feeling.