Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)

[David L. Andre <DLA@DIAMOND.S4CC.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
hash table.

(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
important.

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?