lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (12/28/89)
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.
jeff@aiai.ed.ac.uk (Jeff Dalton) (01/18/90)
In article <12450@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
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.
I don't know of any. Some Common Lisps always compile rather than
having an interpreter, and some use byte codes. So I wouldn't be
surprised to find one that worked the way you suggest. I do know of
one where you could explicitly say whether to compile to byte codes
or native code.
2) Invisible function inlining.
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.
This is fairly common. Most Common Lisps do it for the sequence
functions, for example.
-- Jeff