Common Lisp for SUNS

[Jim McDonald <jlm@lucid.com>]

I'm not the right person to send you benchmark data on Lucid Common
Lisp, but I thought I should mention that Sun Common Lisp is Lucid 
Common Lisp.  (Lucid makes it, Sun sells it.)

Also, I can give some general advice about benchmarks:

(1)  Be sure to note the releases being compared.  For example, LCL
     Version 3.0 is significantly different from LCL Version 2.1.  We
     added a second compiler, an ephemeral garbage collector,
     multi-tasking, better inline floating point code, new interrupts,
     new I/O, etc., etc.  

(2)  Be sure that the person who produced the benchmark values
     understands the benchmarks and the lisp being tested.  Proper use
     of declarations and compiler settings can sometimes produce  
     order-of-magnitude differences.  Also, for example, the use of a
     feature such as ephemeral garbage collection may reflect a
     decision to accept a somewhat increased running time in order to
     avoid detectable pauses for GC.  Turning EGC off may result in
     different (usually faster) benchmark values, and might or might
     not be appropriate for various applications.  You need to
     understand how you're going to use the lisp to know what settings
     are appropriate. 

(3)  Ask for the *precise* techniques used to obtain the benchmarks,
     including processor speed, memory size, load on the machine, etc.
     I know that some of the people at Lucid have produced benchmark
     figures using what we call the "low-mode" -- we run each
     benchmark about 20 times or more, then use some statistics to
     produce a number one could expect to be the low value obtained 
     in a typical set of about 3 runs.  (We didn't want to just
     scrounge for the lowest value, since that's not always
     reproducible, yet did want to give a fair indication of the
     performance possible.)  I'm pretty sure the techniques used are
     distributed with the benchmark numbers. 

(4)  If performance is critical, explain this to the vendor.  For
     example, Lucid is now productizing tools to reorganize your code
     based on an analysis of its dynamic performance, since code and
     data locality can have order-of-magnitude affects on real-life
     applications.  Remember that you are going to be running
     applications day-to-day, and not just benchmarks.  Support in
     this area can be as crucial as the underlying speed of the lisp! 

Happy hunting,

  jlm