Re: JACAL, scm

[Aubrey Jaffer]

Guile 1.4 (ftp://rpmfind.net/linux/contrib/libc6/i386/guile-1.4-2.i386.rpm)
*fails* the R4RS Scheme conformance test
http://swissnet.ai.mit.edu/ftpdir/scm/r4rstest.scm.

Successfully running this file should be a requirement before release.
The SCM makefile runs it every time it creates an executable:

check:  r4rstest.scm
        $(SCMEXE) -fr4rstest.scm \
         -e'(test-sc4)(test-cont)(test-delay)(gc)(if (pair? errs) (quit 1))'

                               -=-=-=-=-

 | Date: Thu, 20 Sep 2001 18:26:06 -0600 (MDT)
 | From: Richard Stallman <address@hidden>
 | 
 |     I haven't tested it lately, but for years SCM was at least twice
 |     the speed of Guile.
 | 
 | Could you try it now, and talk with the Guile maintainers about it?

Computing the digits of pi with INUMs (30-bit integers), SCM is still
twice the speed of Guile:

 address@hidden testing scm 5d4
 on Thu Aug 23 20:42:29 EDT 2001
 -rwxr-xr-x    1 jaffer   users      843741 Aug 23 20:42 scm
    text    data     bss     dec     hex filename
  188043  311380       0  499423   79edf scm
 Linux aubrey.jaffer 2.2.16-3 #1 Mon Jun 19 18:10:14 EDT 2000 i686 unknown
 1600 digits took 11.1875e3 mSec +/- 73 mSec.
  That is about 4.3701171875e3 mSec/k-digit^2 +/- 651.8861294218914e-3%.

 address@hidden testing Guile 1.4
 on Thu Sep 20 21:41:48 EDT 2001
 -rwxr-xr-x    1 root     root         4748 Jun 22  2000 /usr/bin/guile
 Linux aubrey.jaffer 2.2.16-3 #1 Mon Jun 19 18:10:14 EDT 2000 i686 unknown
    text    data     bss     dec     hex filename
    2341     320      44    2705     a91 /usr/bin/guile
 800 digits took 5275 mSec +/- 54 mSec.
  That is about 8242.1875 mSec/k-digit^2 +/- 1.01941648056251%.

 |     Through a series of experiments, I learned that the interpreter
 |     speed is inversely proportional to the size of ceval(); and
 |     largely insensitive to everything else.
 | 
 | Why is that?  I am surprised that the size of the function has that
 | big an effect on the speed.  If you can determine why the size has
 | this effect, maybe we can find a solution.  That would be very
 | useful.

Remembering that this is an empirical result, my theory assumes the
processor can execute many instructions in the time it takes to read one
cache-line.

If the whole program could fit entirely in the cache and the processor
were much faster than the cache, then the only limitation on speed of
interpretation would be the movement of data through the cache.  Of
course, there are some paths through the interpreter which are executed
more than others; and many subroutines which are executed much less
frequently than the interpreter.  So the size of the interpreter is more
like a probability distribution than a hard number.

But filling the cache is a bottleneck.  Data movement will consume as
much bandwidth as is available.  The smaller the interpreter, the
smaller its footprint in the cache, and the less time wasted re-fetching
its code.