Re: PCL benchmark

[kanderso@PEBBLES.BBN.COM]

  Return-Path: <larus%paris.Berkeley.EDU@ginger.Berkeley.EDU>
  Redistributed: CommonLoops.PA
  Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 11 OCT
   88 09:48:37 PDT
  Received: by paris.Berkeley.EDU (5.57/1.25)
   	id AA00534; Tue, 11 Oct 88 09:47:30 PDT
  From: James Larus <larus@paris.berkeley.edu>
  Message-Id: <8810111647.AA00534@paris.Berkeley.EDU>
  To: Chris Burdorf <burdorf@rand-unix.arpa>
  Cc: CommonLoops.PA@xerox.com
  Subject: Re: PCL benchmark 
  In-Reply-To: Your message of Mon, 10 Oct 88 15:07:58 PDT.
                <8810102208.AA01749@rand.org> 
  Reply-To: larus@ginger.berkeley.edu
  Date: Tue, 11 Oct 88 09:47:27 PDT
  
  I, and probably everyone else who has written a large, time-intensive
  program with PCL, have noticed the same problems.  The current
  implementation of PCL has a number of serious performance bugs that
  Gregor is aware of.  PCL consumes about 80% of the time in my code.

This does sound awful, but remember that some of this work would
have to be done if you used some other implementation method.
  
  The first bug is that the caches for the discriminator functions have
  32 entries.  While a fixed-size cache works for some generic
  functions, it fails miserably for generic functions with more than 32
  methods (20% of the time spend in one discriminator function).
  Compounding this problem is the slow speed of the cache miss code
  (20-30% of the time).

This is a good point, in the few systems i've studied, there are a few
functions with lots of methods.  Maybe there is an object oriented
version of Zipf's law which might be something like "80 % of the time
is spent in the 20% of the generic functions with the most methods".
Jim, do your statistics support anything like this?  Gregor is talking
about letting the caches grow.
  
  The second bug is that MAKE-INSTANCE is incredibly expensive.  The
  metaobject hair and parsing property list make for nice, general
  systems that are too expensive to use in real programs.  In fact, I'd
  argue that the CLOS standard should be rejected on this grounds!

I think you can argue about the details of the meta level protocol for
MAKE-INSTANCE, but in real programs, the generality of MAKE-INSTANCE
is quite useful.  Automatic GC is also useful, but in real programs
when you need performance, you may need to come up with alternative
methods.

It would probably be a good metaprogramming exercise to write a
FAST-MAKE-INSTANCE-CLASS-MIXIN.  Heres one way to do it: In one
application, Dave Plumber of Symbolics avoided FLAVOR:MAKE-INSTANCE
overhead by allocating enough raw space to fit an instance, smashing
the type bits properly, and copying initial slot values from a
protototype.  His comments indicate he didn't advocate programming
this way, but he sure could make instances fast.

  Gregor has a workaround that involves using another constructor that
  can be precompiled.  This extension is, however, not part of CLOS and
  so will not be portable.
  
  Gregor is aware of these problems and may have fixed them for the next
  release.  I certainly hope so and I doubt that I'm the only one.
  
  /Jim