[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Lucid 3.0.2 Optimization botch
- To: Gregor.pa@Xerox.COM
- Subject: Lucid 3.0.2 Optimization botch
- From: Jon L White <firstname.lastname@example.org>
- Date: Tue, 23 May 89 00:00:14 PDT
- Cc: egdorf%zaphod@LANL.GOV, CommonLoops.pa@Xerox.COM
- In-reply-to: Gregor.pa@Xerox.COM's message of Mon, 22 May 89 09:52 PDT <19890522165243.3.GREGOR@SPIFF.parc.xerox.com>
- Redistributed: CommonLoops.pa
- Reply-to: <Owners-CommonLoops.pa@Xerox.COM>
re: If you rewrite the Lucid part of FIN to do this mattress-pad stuff then
I can install it in PCL and fix this longstanding problem.
Just doing the tail-recursive exit will probably make the matter
essentially moot for all practical purposes.
The problem crops up all the time here for people using PCL in Lucid
The problem with the "mattress pad" is that it has to be presented as
a "binary patch" -- that is, a small segment of machine code presented
as hex digits -- for each and every hardware platform. I can easily do
this for the 68K and SPARC if you so wish, but note that numerous Lucid
users are on other platforms. Do you wanna try to do the tail-recursive
cache-miss code yourself? I can show you my version, although it may have
Lucid-specific parts in it; it will take a little thought to see how to
retro-fit it (but not much).
The reason why not doing a tail-recursive call is such a big lose is
in the relative period of time in which dcode (procedure) consistency
(1) non-tail: over the interval of open-coded cache lookup, *** as
well as over the call to 'dcode-cache-miss' *** which can take
not only an arbitrarily long period of time, but will ocasionally
directly overwrite the dcode itself, due to cache growth.
(2) tail: only over the interval of the open-coded cache lookup [which
we all know to be very small, right, or else PCL wouldn't be viable
at all]; the liklihood of a multiprocessing collision here is about
the same as the liklihood of a multiprocessing collision revealing
one of the few unprotected "critical sections" in the Lucid 3.0
system -- not zero, but epsilonically small. Also, there is no
problem with cache growth or other updates than can occur in the
Of course, all other implementations would benefit from the fix to dcodes
to be tail recursive when "miss"'ing. I'm pretty sure that VaxLisp has
compiler OPTIMIZE settings that can produce morphologically different code;
and there ought to be other such compilers around.
-- JonL --
P.S. I've been advised privately that the credits for the "mattress pad"
idea (and name) really belong to another Franz person -- that jkf
simply wrote the first version of Franz's "fin". My apologies.