[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
- To: KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
- From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
- Date: Tue, 3 Nov 87 16:00 EST
- Cc: CL-Cleanup@SAIL.Stanford.EDU, Brotsky.PA@Xerox.COM
- In-reply-to: <871103140614.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 3 Nov 87 14:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I think we must say explicitly whether (SETF GET) and (SETF GETF) are
permitted to re-order cells. Secondarily, I also think that we should
say that re-ordering is not permitted.
Ah, yes. I had forgotten about this. Believe it or not, I agree with
you. My reasons are:
(1) I have looked at reordering property lists to optimize programs, and
have determined that for most programs the reordering property lists
will have a negligible effect. Additionally, for those programs where
it may have an effect, usually the first thing a programmer will do is
replace the property list with a more appropriate abstraction such as a
(2) Even if some implementation were to find that they could get a speed
improvement from, say, reordering properties on symbols, your proposal
does not preclude explicit actions, such as the "Optimize World" command
on Symbolics machines, from reordering property lists.
I'm sympathetic to DLA's desire to optimize and I don't want to
trivialize the cost I'm asking him (and others) to pay. But not all of
language design can be based on worry over potentially lost optimizations.
If we thought that, we'd have said it was ok for
(+ (THE FIXNUM X) (THE FIXNUM Y))
to optimize into a fixnum add instruction. The current definition of
the language practically precludes the fixnum add instruction ever being
generated because the user is almost always (in my experience) too lazy
or otherwise unwilling to write
(THE FIXNUM (+ (THE FIXNUM X) (THE FIXNUM Y))).
The stock hardware people had to take a real performance hit on this one.
I haven't looked at the Gabriel benchmarks recently; perhaps it's kind
enough to provide a few benchmarks that suggest that people would really
write this kind of code, so perhaps it gives the impression that the
compiler can generate better code than I bet it typically does, so perhaps
it hasn't hurt the stock hardware people's sales so much. Who knows?
But in any case, the effective performance hit was the price we as a
community paid because we wanted things to port without surprises and
even though you could test your programs at the fixnum boundary points
on one machine with a particular word size, you couldn't easily anticipate
the effect of varying word sizes.
I consider the case of the destructive operations at least as important
as fixnum addition. Perhaps more so because I bet we are on the brink of
places where side-effects will bite us lots more often than we are on the
brink of places where machine word overflow will bite us.
Many CL users maintain code at one site in one or two implementations
and still want to share that code with others at other sites. The ability
to reliably debug portable code in a small number of implementations is
of key importance to those users.
I often feel like vendors want to put such portability issues at an
artificially low level. They mostly seem to want to be able to
(a) optimize the hell out of their implementation
and (b) leave enough vagueness in the spec that people will
find it painful to move out of their implementation into
someone else's. (Always in this an assumption that "the user"
begins in their own implementation and not in someone else's. :-)
An interesting essay. I'm not sure I understand it all after a couple
readings, but I'll take a stab at responding.
As for the specific problems of not being able to optimize into a fixnum
add instruction, I'm hopeful that compiler and metering technology will
improve sufficiently to make it easier to optimize and port CL code. In
thie category of compiler and metering technology I include programs
which assist users in adding declarations to their code which will
improve performance based on code analysis. A more proper parallel in
Symbolics Common Lisp is our violation of CLtL when we cons &REST
arguments on the stack for efficiency. Symbolics should take whatever
performance hit is necessary to correct this, and work to devlop tools
which will make it easy to isolate cases where that performance hit is
I'm also hopeful that stock hardware will, in the not so distant future,
have better instructions for LISP to use. I think there is a trend in
that direction, but I'm biased.
I'll also point out that many of my arguments affected ALL
implementations, not just "Lisp Machines". For instance, REMF removing
pointers to less volatile objects will benefit GC in any implementation,
particularly those with garbage collectors which concentrate their
efforts on recently created objects. I suspect that most CL
implementations will have such a GC in the near future.
The use of declarations naturally will tend to make code less portable,
so I think your use of THE FIXNUM above is contrived.
I've ported programs between CL implementations before, and I've never
come across problems which would have been avoided if
MAKE-EXPLICITLY-DEFINED were adopted. Instead, I find bunches and
bunches of problems where users write something which "is an error", but
is handled differently in two implementations. I therefore find it hard
to believe your position. Why aren't you trying to remove the phrase
"is an error" from the book if your goal is to have a portable language?