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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.