Re: optimizing compiler against iaverage assembly programmer.

"Graham C. Hughes" <graham.hughes@resnet.ucsb.edu>
30 Jun 1997 22:56:45 -0400

          From comp.compilers

Related articles
[4 earlier articles]
Re: optimizing compiler against iaverage assembly programmer. lehotsky@tiac.net (1997-06-20)
Re: optimizing compiler against iaverage assembly programmer. rnordier@iafrica.com (Robert Nordier) (1997-06-24)
Re: optimizing compiler against iaverage assembly programmer. jim-neil@digital.net (1997-06-24)
Re: optimizing compiler against iaverage assembly programmer. jbuck@synopsys.com (1997-06-24)
Re: optimizing compiler against iaverage assembly programmer. bromage@cs.mu.oz.au (1997-06-30)
Re: optimizing compiler against iaverage assembly programmer. charles.marslett@tempe.vlsi.com (1997-06-30)
Re: optimizing compiler against iaverage assembly programmer. graham.hughes@resnet.ucsb.edu (Graham C. Hughes) (1997-06-30)
Re: optimizing compiler against iaverage assembly programmer. WStreett@shell.monmouth.com (1997-06-30)
Re: optimizing compiler against iaverage assembly programmer. creedy@mitretek.org (1997-06-30)
Re: optimizing compiler against iaverage assembly programmer. als@tusc.com.au (1997-07-04)
Re: optimizing compiler against iaverage assembly programmer. conway@mundook.cs.mu.OZ.AU (1997-07-04)
Re: optimizing compiler against iaverage assembly programmer. als@tusc.com.au (1997-07-04)
Re: optimizing compiler against iaverage assembly programmer. dietz@interaccess.com (1997-07-04)
[3 later articles]
| List of all articles for this month |

From: "Graham C. Hughes" <graham.hughes@resnet.ucsb.edu>
Newsgroups: comp.compilers,comp.lang.asm.x86
Date: 30 Jun 1997 22:56:45 -0400
Organization: Fishnet Internet Services
References: 97-06-071 97-06-081 97-06-101
Keywords: assembler, optimize

jim-neil@digital.net (Jim Neil) writes:


> I think the millions of users that must sit and wait for bloated
> compiler generated code to execute time after time, day after day,
> week after week, month after month, year after year, is MUCH more
> valuable than a few extra months of effort spent by a few well trained
> programmers.


I don't believe this at all. Why? Because unless the routine in
question is executed extremely often, the difference between the
assembler version and the HLL version will be on the order of
milliseconds. Worse, both will be bounded by I/O time, which is
simply immense compared to CPU time.


I can't actually slow this machine down at all unless I do some wicked
thrashing of the disk. Even at 100% CPU time used, I don't see any
slow down. And this from an OS written (mostly) in C, running a
windowing system written in C and communicating through extensive
network traffic, running a window manager written in C, running an
editor written largely in LISP, running a newsreader written in LISP!


The slowdown users get from something bloated like WinNT is the fault
of the coder, not the language; Linux proves this.


Put another way, there's no way your immensely optimized bubble sort
is going to beat out my simple merge sort for reasonable data sizes.


I'm expected to write software that works on x86, SPARC, MIPS, and
occasionally PA-RISC architectures; I can't afford to spend the time
writing and rewriting the software for each of these. A HLL + a
pretty good compiler (gcc comes to mind; O'Caml is pretty good for ML,
gnat does some good things for Ada) means I write the code once, and
debug it once. The user-years you complain about are irrelevant when
you realize that my users actually get to use my program during the
extra months you're coding yours.


> The *reason* there arn't that many good machine level
> programmers around is part of this self-fulfilling prophecy that is
> perpetuated by all the HLL pushers.


Are all assembler programmers conspiracy theorists? People don't
write large scale editors, OSes, compilers, and other things in
assembler because it's too hard, not because there's some mythical
organization devoted to pushing MFTLs.


You should look up Scott Nudds in comp.lang.c; he seems to have a
similar world view.


> The other reason that people find
> machine-level coding objectionable is because of the archaic tools
> they are using.


I find machine level coding objectionable because it forces me to
concentrate on irrelevant detail. Why do I need to worry about branch
delay slots on a SPARC to do a merge sort?


Now, there are certainly a few very important applications for
assembler. One of them is (obviously) compiler backends. Certain
embedded systems demand to be coded in machine language (not even
ASM). And I can't think of a more appropriate tool to bootstrap a
machine with. For each of these, branch delay slots, registers, and
intimate machine level details are immensely important.


For writing ls or xemacs, I'll stick with C.


<snip>
- --
Graham Hughes <ghughes@cs.ucsb.edu> MIME OK, PGP preferred


--


Post a followup to this message

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