[Top][All Lists]
[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
- What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/19
- Re: What's the current recommendation for speeding up bits of guile code., Marius Vollmer, 2001/03/19
- Re: What's the current recommendation for speeding up bits of guile code.,
Rob Browning <=
- Re: What's the current recommendation for speeding up bits of guile code., Eric Moore, 2001/03/20
- Re: What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/20
- Re: What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/20
- Re: What's the current recommendation for speeding up bits of guile code., Martin Grabmueller, 2001/03/21
- Re: What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/21
- Re: What's the current recommendation for speeding up bits of guile code., Marius Vollmer, 2001/03/23
- Re: What's the current recommendation for speeding up bits of guile code., Rob Browning, 2001/03/23
- guile performance too slow for gnucash?, Neil W. Van Dyke, 2001/03/23
- Re: guile performance too slow for gnucash?, Rob Browning, 2001/03/23
Re: What's the current recommendation for speeding up bits of guile code., Keisuke Nishida, 2001/03/20