Nikodemus Siivola <nikodemus@...> writes:
> On Wed, 30 Nov 2005, Christophe Rhodes wrote:
>>> 0.9.7.5: one more bug in the obsolete-instance protocol
>> The attached probably fixes this. Reading Kiczales and Rodruigez,
>> "Efficient Method Dispatch in PCL", 1990 was very revealing: it
>> discusses quite a lot of the implementation strategies that are still
>> current, some of which probably don't make very much sense any more
>> (e.g. having 8 hash slots and dynamically choosing between them to
>> improve cache line performance).
> Yep, and the paper also seems to indicate that methods specializing on
> multiple arguments aren't particularly optimized, nor EQL-specializers --
> both of which are probably more common these days.
The multiple-arguments case is slightly optimized -- or at least, I
don't see immediately how to do much better -- by adding together the
individual hash values of the wrappers and using that as the overall
hash for the method lookup. I suppose it would be possible to do
something clever with multiple tables, doing a simple lookup based on
the first argument first, then trying two arguments, and so on... but
it's not clear that it would be a win. In fact, given the absence of
real world data, it's not clear what is a win at all...
> ...but I'm less sure what to do with the patch: given yesterday's #lisp
> I'd be more then happy to merge this and cook up tests for it, but I
> assume you're less then happy with it since you posted it on the list
> instead of merging it. Are you working on a more complete solution to the
> enumarated issues, of which this patch is a part of?
... which is why I sent a mail describing a bunch of other problems
(as well as a patch demonstrating how clever I am for being able to
read 15-year-old papers :-) rather than merging the patch off the bat.
Absent any other information, I think my patch is the right thing to
do, but I wouldn't be surprised to find moderately significant
performance gains available in this area by, say, deleting seven of
the hash values. Some hard numbers would be extremely useful, though.
If anyone has a CLOS-using application, then collecting statistics on,
say, the occupancy of tables, the distribution of number of arguments,
the number of times single-method gfs are called compared with
multimethods... actual numbers would be very useful.
> Incidentally, I started a "Papers" page on the internals-cliki,
> seeding it with this and the bigsurv paper.
Cool. I'll add some things to that page later.