Allowing the choice of a VM engine?

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Andy Wingo <wingo@pobox.com> writes:

> On Thu 15 Jul 2010 23:40, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Just to make sure I understand, though: do you mean switching VMs “on
>> the fly” (i.e., changing the VM currently executing the code), or
>> switching VMs statically, before booting?  The latter (which is what I
>> had in mind) seems easy to do–unless I overlook something, that is.  :-)
>
> Switching before booting would indeed be easier, and I grudgingly admit
> perhaps a good idea, especially for small devices (Maemo, for example).
>
> I would prefer not to enshrine a "regular / debug" split again though. I
> guess that's what really bothers me. It's especially egregious if you
> can't switch at runtime.

OK, understood.  I agree that having to trade debugging support for
performance was painful with 1.8 and earlier: you’d run your program
“fast”, i.e., without ‘--debug’, and then it would fail without leaving
a backtrace or anything, so you’d have to run it again, “slowly” this
time.

However, I think the trade-off here (running “fast” vs. having the
ability to use VM hooks) is less acute.

There are several ways we could allow users to make their choice:

  1. Similarly to how DEVAL/CEVAL is chosen in 1.8, as proposed in
     <87sk3nt326.fsf@gnu.org>.

  2. With a new specific command-line option to the ‘guile’ binary:
     ‘--disable-vm-hooks’, ‘--enable-vm-hooks’, ‘--fast’,
     ‘--vm-engine=regular’, etc.

The advantage of (2) is that we can choose the default that we consider
the most convenient for users, whereas (1) is biased towards
“performance” by default.

The downside of (2) is that such an option may become pointless when
JIT/AOT compilation is available.


Another possibility would be to keep only the debug engine but somehow
optimize the way VM hooks are handled.  I’m afraid there’s little room
for optimization, though.

What do you think?

Thanks,
Ludo’.

PS: I’m reviving the thread because I’m consistently seeing a 10%
    performance degradation in the SRFI-1 rewrite in Scheme, which I’m
    not comfortable with (not that “higher-level languages are
    inefficient” song again!).