benchmarking

[Bill Schelter <wfs@CLI.COM>]

    Well, that's an interesting quirk of KCL.  It's good that there is an
    automatic tool for generating declarations, though it doesn't help much if
    people don't use it.

That is true.   Although it is also true that people who spend the time
to write a large lisp system, are ususually willing to spend the 5
minutes it takes to learn to use a tool which improves their code's
performance.

AKCL has a facility for analyzing large sets of files, to determine
the callers and proclamation information.  This is done at the same
time as the users system is compiled, by turning a flag on.  This is
the normal way that people build proclamation files for AKCL.  For
example scratchpad (ibm's large object oriented algebra system) has at
least 800 source files, and new proclaims are generated each time the
entire system is recompiled.  Similarly for macsyma which contains 150
files.  This is particularly important for AKCL since there are two
ways of passing arguments to functions: via the C stack and via a
`lisp value stack'.

Unfortunately AKCL still uses the lisp value stack for functions
returning multiple values and for closures.  There is no real reason
for this, other than the fact that I have not spent the time to change
things.  If this were done then calls to these functions would be much
closer in speed to those of functions proclaimed to return one value,
which now pass their args on the C stack.  Also you would not see
the strange behaviour Bob Boyer exhibited, in showing how funcall
differed in speed between proclaimed and unproclaimed.  In KCL there
was an extremely limited class of functions which could pass arguments
on the C stack, and calls via this stack were limited to a single
file--thus KCL is closer to AKCL in speed on the gabriel bench marks
than in real systems such as macsyma.  For AKCL it makes no difference
whether functions are in the same file or different files.   All user
functions may be traced and redefined.

Bill