[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: SEB1525@draper.com
- Subject: EQ
- From: Jon L White <email@example.com>
- Date: Sat, 17 Dec 88 01:17:22 PST
- Cc: cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: "Steve Bacher (Batchman)"'s message of Fri, 16 Dec 88 07:59 EST <8812161638.AA01151@lucid.com>
re: If neither operand is a constant or a type-declared variable or function
call, it is not known whether the EQL call may be optimized into an EQ
call. (This is probably not a problem for your implementation, JonL, or
for many others', but it may be for others - it is for mine.)
I think that's a universal problem, but not a particularly serious one.
Of course, Lucid's Production-Quality compiler makes all the obvious type
optimizations; but for EQL, it also does an in-line check for EQ success
before calling EQL out-of-line. (Vax/NIL used to do a bit more on EQUAL,
based on monitoring some MACSYMA code; but that was before EQL came about).
I have often referred to these kinds of tricks as "beating out the function
call" -- namely, a fast, in-line, fail-safe, but not complete test which is
performed just before taking the time to go out-of-line. I think Richard
Fateman of UCB independently discovered "beating out the function call" on
EQUAL -- for exactly the same reason (tuning the performance of Vaxima).
Internally, Lucid code ocasionally makes use of (optimizable) functions
named EQ-FOR-EQL-P and EQ-FOR-EQUAL-P; typically they are used to select
one of two alternative methods; e.g., ASSOC can dynamically turn into
ASSQ. These checks "open compile". So the time to make the determination
pays off immensely in the one case by reducing out-of-line calls, and in
the other case, the out-of-line calls are so costly that the check time
is negligible. It wouldn't matter whether or not EQ were part of the
portable standard -- these tricks would still be applicable to the way in
which the system internals and compiler output work.
A good point to make for retention of EQ is that even though portable
code may not be able to utilize the difference between EQ and EQL, it
will still be the case that every implementation will have *some*
function that does address/pointer identity comparison; so we might as
well all call it the same thing, so as to minimize the culture shock when
moving from one implementation to another.
-- JonL --