Notes on the Kernighan and Van Wyk Benchmarks
I used the
source code
as supplied by Kernighan and Van Wyk,
except for a few minor bug fixes in
array1.scm,
assoc.scm, and
tail.scm.
Since these benchmarks were written to test scripting languages,
I generally compiled them using safe compiler options and
unlimited precision generic arithmetic.
C code is inherently unsafe, however, so I also benchmarked the
unsafe code that can be generated by Gambit-C and by Chez Scheme.
Scheme48 supports generic arithmetic, but not unlimited precision
arithmetic.
It does not support floating point arithmetic, either, but uses
rational arithmetic instead.
This benchmark was intended to test looping and arithmetic,
but it performs one million assignments to a global variable.
In Larceny and Chez Scheme this benchmark therefore
becomes a test of the garbage collector's write barrier.
The no-wb line shows the timing for Larceny
with the write barrier turned off.
One of the two recursive calls in the code for the
Ackermann function is tail-recursive, so Scheme ought to perform
much better than C on this benchmark.
This benchmark allocates and destructively initializes two fairly
large one-dimensional arrays.
Larceny allocates both arrays in the youngest generation, but they
do not both fit there, so the garbage collector has to copy the
first into an older generation before allocating the second. This
copying accounts for over half of the faster time shown for Larceny.
A more recent version of Larceny deals with large objects more
efficiently.
This tests nothing but string-append and
substring. If these standard procedures are
implemented efficiently, then interpreted implementations
such as MIT Scheme can perform very well on this benchmark.
I have not been able to get Java to run this benchmark without
overflowing its string space.
This file-copying benchmark is a simple test of character i/o.
Another character i/o benchmark.
This benchmark performs considerable character i/o, but it
also allocates storage very rapidly.
About 95% of the allocated storage becomes garbage almost
immediately, but the other 5% survives to the end of the
benchmark.
With the generational garbage collectors used in Larceny and
Chez Scheme, garbage collection accounts for less than 10%
of the cpu time, so this too is primarily an i/o benchmark.
This benchmark reads and sums 100,000 floating point numbers.
Several implementations of Scheme use my code for reading floating
point numbers with the best possible accuracy. Chez Scheme uses a
more efficient version of that algorithm.
Scheme48 is slow on this benchmark because it uses
rational arithmetic instead of floating point.
Last updated 15 February 1999.