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

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> But it would also be a good opportunity to bring the Sparc and PowerPC
> backends of Lightning up to snuff, no?

:>

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

Hmm.  Well, for the near term, if I can get hobbit up and behaving, it
seems like that's probably our best bet over in gnucash-land, and if
hobbit really does work well, it might even be something we want to
maintain as an option for guile proper.

While in general, Lightning, etc. may be sufficient, it might be nice
to have a bigger, though slower, gun (i.e. gcc) lying around for cases
where people are willing to put up with the delay (or "batchness").
Also, having gcc as an option probably also helps on the "new
architectures" front.  It'll probably work well before lightning gets
ported.  The good thing is, that if we have both options (JIT and gcc)
and it's not too hard to maintain them both for a while, then over
time, it should become obvious if Lightning should just wholly
displace gcc by examining performance evaluations, etc.

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