guile-devel
[Top][All Lists]
Advanced

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

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


From: Rob Browning
Subject: Re: What's the current recommendation for speeding up bits of guile code.
Date: 20 Mar 2001 11:21:38 -0600
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Marius Vollmer <address@hidden> writes:

> What I like to do is to have a sort of compiler framework that can
> generate code for a portable byte code machine or for GNU Lightning,
> a JIT compiler.

Wow.  I hadn't heard about lightning, but after reading the info
pages, it's certainly interesting, and having clean integration with
guile would be really pretty stunning.

However, this raises some points:

  * 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?  In other words, I'm wondering if there's some way to
    start small, maybe with a (jlt-compile) function that isn't very
    smart, and often does nothing, and then incrementally improve.
    (Note: I haven't had time to think about the idea much yet, so I
    don't yet have a good grasp on the issues involved.)

  * 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.

  * So are there shorter term possibilities?  For example, I've never
    used hobbit, but does anyone know if it's even close to working
    with guile 1.4, or is there some other more immediate option?

  * 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?  In either
    case, you'd end up with object code that could be used later, or
    dynamically loaded right then -- or is this kind of thing just not
    considered very important?  (Not particularly concerned either
    way, just trying to figure out what the current sentiment is...)

[1] Though I realize there's a different (and powerful) class of
optimizations you can do with a JIT compiler that you can't with a
black-box "big-chunk" compiler :>

Thanks

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930



reply via email to

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