[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PCL benchmark
- To: larus@GINGER.Berkeley.EDU
- Subject: Re: PCL benchmark
- From: kanderso@PEBBLES.BBN.COM
- Date: Wed, 12 Oct 88 13:38:25 -0400
- Cc: Chris Burdorf <burdorf@RAND-UNIX.ARPA>, CommonLoops.PA@Xerox.COM
- In-reply-to: Your message of Tue, 11 Oct 88 09:47:27 -0700. <8810111647.AA00534@paris.Berkeley.EDU>
- Redistributed: CommonLoops.PA
Received: from paris.Berkeley.EDU ([126.96.36.199]) 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 <firstname.lastname@example.org>
To: Chris Burdorf <email@example.com>
Subject: Re: PCL benchmark
In-Reply-To: Your message of Mon, 10 Oct 88 15:07:58 PDT.
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
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.