Re: Assembly verses a high-level language.

john_reiser@MENTORG.COM (John Reiser)
9 Dec 1995 19:43:14 -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: john_reiser@MENTORG.COM (John Reiser)
Newsgroups: comp.compilers
Date: 9 Dec 1995 19:43:14 -0500
Organization: Mentor Graphics Corporation
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.
: > [snip]


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


And it is still true that humans can and do produce better code than
compilers do. When it _really_ matters, I can still produce code that
has a much lower time*space product for execution (sometimes by a
factor of 2 or more) than available compilers for x86, SPARC, HP-PA,
Alpha, or MIPS. [That list is roughly in order of increasing
difficulty.] I audit, instrument, allocate registers, unroll, unify,
pipeline, schedule (instructions and data,
registers/cache/memory/disk/network), and transform algorithms. But
programming is an economic art, I charge high prices for such work,
and many times employers want me to do other things [produce new
products] instead.


: 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.


For the case of virtual function calls in C++ as implemented in cfront
and compiled by common compilers for workstation RISC architectures, I
disagree. As commonly compiled, such a dispatch takes ~7 words and
~12 cycles due to dependency stalls (almost no superscalar). With
better register usage, recognition of global tail merging, etc., it
can be done in 2 words and 7 cycles (5 cycles if 2-way superscalar).
I know of a piece of "OO" code that is just under 6MB of instructions
and has multiple tens of thousands of C++ virtual function calls. The
savings would run to more than half a megabyte in space, and several
percent in time.


: graham


---
John Reiser john_reiser@MentorG.com
Mentor Graphics Corp.
8005 SW Boeckman Rd
Wilsonville, OR 97070 USA
+1 503 685 7000 x3548
--


Post a followup to this message

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