Re: srfi-18 and the vm

[Andy Wingo <wingo@pobox.com>]

Hi Neil,

On Mon 25 May 2009 23:57, Neil Jerram <neil@ossau.uklinux.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@pobox.com> writes:
>>
>>> For loading uncompiled scripts, things will be slower, unless your
>>> modules #:use-syntax some other transformer. I don't know where the
>>> tradeoff is between the increased expansion speed due to compilation and
>>> slowdown due to a complete codewalk, but it's certainly there.
>>
>> Yes.  Likewise, it may be reasonable to assume from now on that most of
>> the code will be compiled.  For instance, an uncompiled script may just
>> be a small code snipped that uses mostly compiled code.
>
> It seems to me that once we have a completely working compiler, we
> need to ask if there are any circumstances left where it is better to
> use the current interpreter instead.

In the short term (within the next year or so), I would imagine that
ceval/deval would be faster than an eval written in Scheme -- though I
do not know.

On the other hand, an eval written in Scheme would allow for
tail-recursive calls between the evaluator and the VM.

Another option, besides an eval in Scheme, is replacing the evaluator
with the compiler. One could compile on the fly and run the compiled
code from memory, or cache to the filesystem, either alongside the .scm
files or in a ~/.guile-comp-cache/ or something. But compilation does
take some time.

It seems clear we still need an eval in C, at least to bootstrap Guile.

WRT replacing ceval, I guess my conclusion is that I don't know yet.

> If the answer to that is yes, the details of those remaining
> circumstances will (probably) make it obvious whether the
> pre-memoization idea is worthwhile.

Yes, perhaps. We probably need some timings.

> Do we already have performance measurements, and are those recorded /
> summarized somewhere?

We don't have very systematic ones. I was just running some of the
feeley benchmarks again, and it looked to me that the VM's speed is
about 3 or 4 times the speed of ceval in 1.9, but I should test with
benchmarks that run for only 1s or so, and measure compilation time, and
test against 1.8 too.

>>> OTOH I would suspect that we can implement some kind of just-in-time
>>> compilation -- essentially for each use-modules we can check to see if
>>> the module is compiled, and if not just compile it then and there. It
>>> would be a little slow the first time, but after that it would load much
>>> faster, even faster than before. Python does this. We could add a guile
>>> --no-comp option to disable it.
>>
>> I don't like this idea because it implies implicitly letting Guile
>> fiddle with the user's file system.
>
> I don't see why that should be.  Isn't it possible to read a .scm
> file, compile its contents, and hold the compiled programs in memory?

Yes, compile-and-load, from (system base compile). But you have to redo
the compilation the next time the file is loaded, of course.

Incidentally, ikarus had a similar discussion recently:

  http://thread.gmane.org/gmane.lisp.scheme.ikarus.user/723
  http://thread.gmane.org/gmane.lisp.scheme.ikarus.user/745

Cheers,

Andy
-- 
http://wingolog.org/