Re: optimizing compiler against average assembly programmer.

Daniel Glastonbury <dglaston@asc.corp.mot.com>
24 Jun 1997 23:39:02 -0400

          From comp.compilers

Related articles
optimizing compiler against iaverage assembly programmer. gclind01@starbase.spd.louisville.edu (1997-06-15)
Re: optimizing compiler against average assembly programmer. cef@geodseic.com (Charles Fiterman) (1997-06-19)
Re: optimizing compiler against average assembly programmer. tgl@netcom.com (1997-06-20)
Re: optimizing compiler against average assembly programmer. rboland@csi.uottawa.ca (Ralph Boland) (1997-06-24)
Re: optimizing compiler against average assembly programmer. dglaston@asc.corp.mot.com (Daniel Glastonbury) (1997-06-24)
Re: optimizing compiler against average assembly programmer. walter@bytecraft.com (Walter Banks) (1997-06-30)
Re: optimizing compiler against average assembly programmer. gclind01@starbase.spd.louisville.edu (1997-06-30)
Re: optimizing compiler against average assembly programmer. norman@kbss.bt.co.uk (Norman Hilton) (1997-06-30)
Re: optimizing compiler against average assembly programmer. debray@cs.arizona.edu (1997-06-30)
Re: optimizing compiler against average assembly programmer. cef@geodesic.com (Charles Fiterman) (1997-07-04)
Re: optimizing compiler against average assembly programmer. vkarvone@raita.oulu.fi (1997-07-04)
[12 later articles]
| List of all articles for this month |
From: Daniel Glastonbury <dglaston@asc.corp.mot.com>
Newsgroups: comp.compilers,comp.lang.asm.x86
Date: 24 Jun 1997 23:39:02 -0400
Organization: Motorola Australia Software Centre
References: 97-06-071 97-06-074
Keywords: assembler, performance

Charles Fiterman <cef@geodseic.com> writes:
This is my first time posting to this news group but I felt I had to
respond to this thread, so here goes.


> Third he has the compiler produce assembly for those small
> sections of code.
>
> Fourth he hand tunes them looking for tiny improvements over
> the machine generated code.


This can lead to fast slow code, as opposed to fast fast code. When
optimizing a human optimizer should not think like a compiler. i.e.,
There is little gain in tweaking a few instructions. If the algorithm
is slow, the tweaked assembly code is still probably going to be slow.


> The human wins because he can use the machine.


The human wins because s/he knows what the code is supposed to be
doing. S/he can change the algorithm, knows how the system works to
remove i/o related slow down etc.


cheers
Dan
--


Post a followup to this message

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