[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Compilation of methods per class.
- To: firstname.lastname@example.org
- Subject: Compilation of methods per class.
- From: Jon L White <jonl@lucid.COM>
- Date: Wed, 26 Sep 1990 15:39:24 PDT
- Cc: email@example.com
- In-reply-to: "firstname.lastname@example.org's message of Wed, 26 Sep 90 13:17:17 PDT <9009262017.AA00252@miles>"
re: What do you mean "go out of line"?? What went out line and what did it
do when it was "out if line"??
. . .
By the way, I still don't know what is meant by "cache assumption
You should look at the Victoria Day and prior sources, for the uses of
the function DCODE-CACHE-MISS. Calling it is "out of line"; calling it
when the entry is actually in the cache is the "assumption breakdown".
I say "breakdown", because it is plausible to suffer the order-of-magnitude
loss to go "out of line" if it rarely happens; this is the classic analysis
for caching. But an application can randomly fall into a hole where a
substantial fraction of its lookups are in this case. Trent's symptoms are
quite consistent with this, and less consistent with the other explanations.
re: In Victoria Day PCL, the hashing numbers are assigned sequentially.
. . . However, I seriously doubt that having different hash numbers
would cause the "non-linear" changes Trent discovered.
The "breakdown" problem isn't caused by differing hashing numbers --
rather, those differences can mask the problem at times making it very
hard to reproduce exactly. I hope my previous msg didn't give you
the wrong impression about what part these numbers play.
Furthermore, sequential assignment of the class hashing numbers won't
guarantee repeatablility of the problem across ports -- it is sensitive
to the order in which the classes are assigned, and the order in which
method are called on generic funtions (i.e., the way in which the cache's
are filled up with entries). Just a tiny variation in any of these
between two ports can make one avoid the problem where the other falls
-- JonL --