Re: Compilation of methods per class.

[Trent Lange <lange@CS.UCLA.EDU>]

>I am unable to reproduce quite the results you show.
>
>At the end of this message is some code which is largely based on your
>example.  It differs only in the timing macro used, and that it
>automates (using PCL internal stuff) the process of restarting from
>scratch to `fill the caches' in the other order.
>
>Using this data, I show that for 10000 calls to SLOW-FOO, the best time
>(in seconds, on a SUN 4/330, in Lucid 3.0.1) is .13.  Whatever variation
>there is doesn't seem to be related to the order in which the `caches
>are filled'.  This, of course, ignores the first run of each test after
>doing a reset to allow time for the caches to fill.
>
>Could you try this code, or look at this code, to see how it differs
>with what you are measuring.
>
>Gregor

The code measured exactly what I was measuring, except for one thing:

>(defun test (x y)
>  (let ((i1 (make-instance 'class1))
>	(i2 (make-instance 'class2)))
>    (setq y (/ y 2))
>    (dotimes (i x)
>      (reset)
>      (dotimes (i y) (slow-foo i1) (slow-foo i2))
>      (time (dotimes (i y) (slow-foo i1) (slow-foo i2)))
>      (time (dotimes (i y) (slow-foo i1) (slow-foo i2)))
>      (reset)
>      (dotimes (i y) (slow-foo i1) (slow-foo i2))
>      (time (dotimes (i y) (slow-foo i2) (slow-foo i1)))
>      (time (dotimes (i y) (slow-foo i2) (slow-foo i1))))))

The 3rd to last line should be:

       (dotimes (i y) (slow-foo i2) (slow-foo i1))

Once I switched it to that (so that the cache is filled first with i2),
my run on a Sun-4 in Lucid 3.0.1 showed the same problem I found earlier.
The first two timings for 10,000 calls took a best of 0.13 seconds (like
yours), but the last two took a best of 0.17 seconds.

So unless there's something screwy with my May Day PCL, the run time
in Lucid definitely seems to be dependent upon the order in which the
caches are filled (and with generic functions having more than two
specializations, sometimes quite adversely affected by that order).
However, they don't seem to be dependent on cache-filling order in
Allegro.  Of course, I don't know what this tells us about the more
important problem, that of the general generic-function call slowdown
in Lucid when they are specialized on a number of different classes.

- Trent Lange