Hello! Andy Wingo <[email protected]> writes:
> On Thu 15 Jul 2010 23:40, [email protected] (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 <[email protected]>. 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!).
