guile-devel
[Top][All Lists]
Advanced

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

Re: guile bar mitzvah


From: Andy Wingo
Subject: Re: guile bar mitzvah
Date: Thu, 16 Jul 2009 21:04:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

Hi Martin,

[copying guile-devel, as it's an interesting bug]

On Thu 16 Jul 2009 15:32, Martin Ward <address@hidden> writes:

> The code I was running was the commercial version of the FermaT
> Migration Engine. The core of FermaT (the FermaT Transformation
> System) is released under the GPL and can be downloaded here:
>
> http://www.cse.dmu.ac.uk/~mward/fermat.html
>
> FermaT is implemented in WSL (a language I invented),
> which is translated into Scheme and then compiled into C
> using the Hobbit compiler. I have attached a copy of the Scheme
> code (4.7MB of source) plus a couple of test files.
>
> Here are the results of my test runs on these files:

Thanks for giving Guile 1.9.1 a try. I can forward those files to anyone
who's interested.

> Testing semantic_slice_TEST.scx:
>
> Guile 1.9.1:    1587 secs.
> Guile 1.8.7:     924 secs.
> Gambit v4.4.4:   558 secs.
> SCM version 5e5: 184 secs.
> Hobbit compiled: 9.7 secs.

> As you can see, Guile 1.9.1 is the slowest of the lot,
> and a lot slower than Guile 1.8.7.

So, unfortunately it's expected that guile's 1.9.1 interpreter is slower
than 1.8.7, because the expander expands more thoroughly, so we miss out
on some optimizations the "native" expander does. Also there is a
penalty when calling out to compiled code from interpreted code, because
the interpreter is written in C and not Scheme.

On the other hand, it's obvious you didn't take advantage of the new
compiler either :) Compiling ALL.scm bombs out when it hits a function
with ~600 heap-allocated lexical variables in its scope, whereas our
current limit is one byte (255).

There are basically two problems here, on Guile's side: we make too many
closures instead of inlining loops, which forces heap allocation; and we
capture all heap-allocated lexicals instead of just the ones that are
referenced in a given function. But still, our default limits are too
low, probably. I'll be thinking on how to fix this.

> Just loading ALL.scm takes over 30 seconds on 1.9.1,
> but only 0.6 seconds on 1.8.7!

That's expansion time :) 1.8.7 expands lazily at runtime.

> For comparison, my overnight regression tests take about 5 hours
> to run (on the Hobbit compiled code, of course!)

I think Guile could get to within 2-4x this speed, with the VM and
obviously with the compiler.

Andy
-- 
http://wingolog.org/




reply via email to

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