[Guile-commits] 01/12: Minor VM documentation updates

[Andy Wingo]

wingo pushed a commit to branch master
in repository guile.

commit a0a8741608a4094cbd0f4d25d6bfdec1ff9e48eb
Author: Andy Wingo <address@hidden>
Date:   Fri Sep 18 10:43:06 2015 +0200

    Minor VM documentation updates
    
    * doc/ref/vm.texi (Why a VM?, Variables and the VM): Minor updates.
---
 doc/ref/vm.texi |   16 +++++++++-------
 1 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/doc/ref/vm.texi b/doc/ref/vm.texi
index 6616af4..ba31d7c 100644
--- a/doc/ref/vm.texi
+++ b/doc/ref/vm.texi
@@ -80,11 +80,12 @@ but it is not normally used at runtime.)
 
 The upside of implementing the interpreter in Scheme is that we preserve
 tail calls and multiple-value handling between interpreted and compiled
-code. The downside is that the interpreter in Guile 2.2 is still slower
-than the interpreter in 1.8. We hope the that the compiler's speed makes
-up for the loss.  In any case, once we have native compilation for
-Scheme code, we expect the new self-hosted interpreter to beat the old
-hand-tuned C implementation.
+code. The downside is that the interpreter in Guile 2.2 is still about
+twice as slow as the interpreter in 1.8.  Since Scheme users are mostly
+running compiled code, the compiler's speed more than makes up for the
+loss.  In any case, once we have native compilation for Scheme code, we
+expect the self-hosted interpreter to handily beat the old hand-tuned C
+implementation.
 
 Also note that this decision to implement a bytecode compiler does not
 preclude native compilation. We can compile from bytecode to native
@@ -213,8 +214,9 @@ variables are allocated in ``boxes''---actually, in 
variable cells.
 variables are indirected through the boxes.
 
 Thus perhaps counterintuitively, what would seem ``closer to the
-metal'', viz @code{set!}, actually forces an extra memory allocation
-and indirection.
+metal'', viz @code{set!}, actually forces an extra memory allocation and
+indirection.  Sometimes Guile's optimizer can remove this allocation,
+but not always.
 
 Going back to our example, @code{b} may be allocated on the stack, as
 it is never mutated.