Re: Assembly verses a high-level language.

albaugh@agames.com (Mike Albaugh)
9 Dec 1995 19:57:59 -0500

          From comp.compilers

Related articles
Assembly verses a high-level language. tomviper@ix.netcom.com (1995-11-20)
Re: Assembly verses a high-level language. macrakis@osf.org (1995-11-22)
Re: Assembly verses a high-level language. bobduff@world.std.com (1995-11-28)
Re: Assembly verses a high-level language. marcus@illusion.magicno.com (1995-11-29)
Re: Assembly verses a high-level language. Graham.Matthews@pell.anu.edu.au (Graham Matthews) (1995-11-29)
Re: Assembly verses a high-level language. john_reiser@MENTORG.COM (1995-12-09)
Re: Assembly verses a high-level language. albaugh@agames.com (1995-12-09)
| List of all articles for this month |

From: albaugh@agames.com (Mike Albaugh)
Newsgroups: comp.compilers
Date: 9 Dec 1995 19:57:59 -0500
Organization: Time-Warner Interactive
References: 95-11-166 95-11-247
Keywords: assembler, performance

Graham Matthews (Graham.Matthews@pell.anu.edu.au) wrote:
: Tom Powell wrote:
: > How come programs written in assembly are so much faster than any
: > other high-level language.


: There are two answers to this. The first answer is that compilers can
: and do produce better code than humans do.


Yup, sometimes, probably often.


: The second answer is that high level languages often include
: convenient but expensive constructs that are not in assembly
: language, and that if you were to program in assembly language would
: be just as slow as in the high level language. Functional closures
: comes to mind. OO dispatch is another.


IMHO, the principle reason that assembly-language programs
_can_ be faster than, say, C, is that any language has its own
"algorithmic blind spots", things that are just very difficult or
convoluted to express in that language. Things like, say, coroutines
and bit-fields overlapping a machine word in C :-) If you were to code
an algorithm in C, then "hand compile" it to assembly, you would
probably have to be a pretty experienced assembly programmer to do
much better than the oft-quoted "10%" improvement. You might very well
do worse. If, on the other hand, you took advantage of the expanded
algorithm space to re-cast your solution at the algorithmic level, you
could get some impressive advantages. Just by avoiding the two "C
blind-spots" mentioned above, I was able to get an 8x improvement on
some de-compression code one time :-) Of course, YMMV.


A _possible_ cause of the remaining 10% is that compilers
regularly, as an "emergent behavior" from badly interacting
optimizations, do _incredibly_ silly things. Like moving the
same value back and forth between a pair of registers, then
discarding it (GreenHills), re-loading the absolute address of
a structure for every member reference (GCC, at least up to 2.6),
etc. For every academic that tells you these are "solved problems"
in research compilers, there are probably 100 programmers who have been
recently bitten by them in current, commercially available compilers.


BTW: I used something perilously close to functional closures
in assembly-language network code 15 years ago, and the first OO-dispatch
I ever saw was for the SmallTalk byte-code interpreter, in Nova Assembly,
earlier than that :-)


Mike


| Mike Albaugh (albaugh@agames.com) Time Warner Interactive
| (The entertainment company formerly known as Atari Games (_NOT_ Tramiel's))
| 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.