LEVITT@MIT-OZ (05/23/85)
From: LEVITT%MIT-OZ@MIT-MC.ARPA I have been quietly enjoying Doug Pardee's defense of assembly language. I've hacked Lisp Machine lisp quite alot, and I've hacked assembler, and in some ways I've found assembler more satisfying. Doing real-time music applications, I've generated some gorgeous polyphony easily in real time in assembler -- whereas in Zetalisp I'd almost HAVE to pre-compute it, or strenuously cache it, or give it up. In general (or at least until recently) system sources were always available for lispms, so IN PRINCIPLE I could make code perform, even if it meant microcoding; but the programming style most ENCOURAGED by the lisp machine system always meant low performance. (My main experience is with MIT's old CADR/LM-2 design, but comments about the programming environment and style apply to today's systems, too.) Between mediocre compilers, huge operating system kernels, and demand paged systems, this is typical of HLL environments: you get some good tools but you lose control of the performance of the machine. So I think a relevant question is: how much can we improve assembly code design, maintenance, and debugging tools? Could we make them so wonderful that most of the HLLers' objections go away? (I once heard a rumor this was being done for the Mac.) Of course, many assembly systems already have better source level debuggers than the C and other compiled HLLs on the same machine. And, two advanced systems come to mind: (1) Jim Dunion's amazing debugger for the Atari (circa 81 -- I forget its name) was window-based, had an animated stack trace, break window, etc. It preceded the Lisp Machine window debugger, and ran faster. (2) MacNosy by a fellow named Jarmusche (sp?) should have been an AI degree, if he doesn't already have one. It "decompiles" 68000 code, doing a recursive tree walk through apparent code segments, and allowing the user to intervene. So you can study and (by entering macros as you discover structure) grok jump tables and other weird programming habits of your favorite compilers or assembly code authors. Roger Duffey did some interesting work on assembler expertise at MIT's AI lab a few years ago, but in general it seems to be a vastly underexplored field. I think indirectly, the commitment here to microcoded Lispms killed interest in it. (Except I hear Richard Greenblatt did a very smart microcompiler for his Lispms.) --David Levitt
VERACSD@USC-ISI.ARPA (05/24/85)
From: VERACSD@USC-ISI.ARPA Dave ==> Please stop sending us the W"Works". Thank you.
RWK@SCRC-STONY-BROOK.ARPA (06/11/85)
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
From: doug@terak.UUCP (Doug Pardee)
Subject: Re: Ackermania
Date: 13 May 85 18:52:35 GMT
But now I see news postings and get mail insisting that it was
"unfair" to multiply this effect by comparing a VAX against a Z-80A,
because the VAX is crippled by having an excruciatingly slow "call"
instruction.
Sigh. I wish people would can all the off-the-cuff conclusions from
off-the-cuff benchmarks.
Now, I personally think that save-everything-in-the-
machine-because-we-don't-know-what-the-subroutine's-gonna-do type
"call" instructions are a direct result of HLL-mania and thus are
fair game, but I'll give the VAX the benefit of the doubt.
Actually, the VAX CALL instructions do NOT save everything in the
machine, because they DO know what the subroutine's going to do.
(That's what the entry mask on the subroutine is all about). The VAX
calling sequence is essentially CALLEE SAVES, not CALLER SAVES. DEC
chose this architecture after a fair bit of benchmarking and comparison,
and a lot more thought about the matter than is reflected in your
remarks.
This entire discussion has been meaningless, because nobody has
taken the time to compare apples with apples, and even when
comparing fruit with fruit, the facts have been so piecemeal to
be impede comparisons.
Just to give you an idea of what a responsible benchmark might
include:
* Always showing the comparison on all CPU's
* Presentation and analysis of the actual instruction sequences
involved
* Statement of exactly which compiler (and which version!) is involved.
* Before making conclusions about HLL's, actually undertaking a
survey of various compilers (like BLISS-32, etc.).
* Limiting your conclusions to what your benchmarks actually indicate.
(ACKERMAN indicates something about the cost of function calls,
but does NOT indicate anything about over-all "typical" performance).
* Including a comparison of the calling sequences used (since function
calls are what's being compared here!).
* Not publishing your results until all the facts are in.
Your original benchmark was so far from being reasonable that
a dozen messages from people trying to fix the flaws haven't
been able to repair the damage. The danger is that people
will believe your conclusions because you've done some tests,
even when what you've done is complete nonsense.
Help Stamp Out Bogus Bencharks In Your Lifetime....Wear Mittens!