Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!bionet!ames!pacbell!att!cbnewsc!lgm
From: lgm@cbnewsc.ATT.COM (lawrence.g.mayka)
Newsgroups: comp.lang.lisp
Subject: Application of Smalltalk/Self compilation techniques to Common Lisp?
Keywords: cached compilation, invisible inlining, type customization, speed
Message-ID: <12450@cbnewsc.ATT.COM>
Date: 28 Dec 89 15:54:12 GMT
Organization: AT&T Bell Laboratories
Lines: 47


Have any commercial or research Lisp compilers attempted any of
the optimization techniques published for Smalltalk and Self?  I'm
thinking of techniques like the following:

1) Use of bytecodes throughout the system to save space, but with
on-the-fly, cached compilation of frequently called functions to
improve execution speed.  The current Lisp practice of offering
interpretation and compilation suffers from two handicaps:  (a)
Most Common Lisp interpreters are so slow as to be impractical
except for top-level commands; (b) Typically, the programmer must
explicitly specify which functions or files are to be compiled.

2) Invisible function inlining.  Calls to small, simple functions
are automatically inlined, but the compilation dependency is
recorded so that the system can recompile as necessary if the
inlined function is modified.

3) Type customization of compiled functions.  A single function
may compile into more than one sequence of machine instructions:
one version for the most common case and one version for the
general case.  For example, a function with a predominance of
numerical operations might compile into a version that assumes
that all numbers are fixnums, plus a more general version that
makes no such assumption.  The customized version would check all
assumptions before proceeding, and jump to the general version if
any are false.

In "old" Common Lisp, the two main categories of polymorphism I
see which could benefit from type customization are numeric
operations and (to a lesser extent) sequence operations.  In ANSI
Common Lisp, CLOS might find such a technique useful as well.

I understand, of course, that all these optimizations have
disadvantages, too.  Nevertheless, it would be interesting to know
whether such techniques are as helpful to Common Lisp as they seem
to be for Smalltalk and Self.  CL's greater opportunities for
optimization *should* permit it to execute significantly faster
than Smalltalk.  I would not want to see Lisp blow its speed
advantage through inferior compiler technology.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@ihlpf.att.com

Standard disclaimer.