Re: High Level Language vs Assembly

<francis.doyle@donovandata.com> wrote in message
> When I took a compiler class in Grad School, my professor was
> adamant about the efficiency of code produced by new high level
> language compilers. He stated that a human assembly language writer
> was no longer able to compete with these compilers (unless, of course
> you consider something like Microsoft VB...Ha Ha). His arguments were
> convincing, but I was looking for some actual numbers to back this up
> (ie; RECENT performance comparisons). Any help would be greatly
> appreciated (as I work in an IBM Mainframe assembly shop and this sort
> of talk gets me treated like a heretic).
>
> -Frank Doyle


No matter how good the compiler is, it cannot overcome sloppy code
written in the HLL. If someone knows how the compiler generates code,
they can write HLL source that compiles to some amazing machine code.
However, in every large project I've seen (those involving multiple
programmers at once and over time), the code is not written in this
fashion (laziness, need for portability, lack of skill, whatever). A
good compiler is no match for a poor programmer.


There are two reasons *good* assembly language programmers still
write better code than compilers:


(1) They get to look at the code the compiler emits (whereas the compiler
doesn't get to look at the code the programmer writes).


(2) Good assembly programmers are not "wetware" compilers.
They don't think in the HLL and simply translate the code line-by-line
into assembly language. A compiler will beat such an "assembly"
programmer nearly every time. Instead, good assembly programmers
devise low-level solutions involving different data types and algorithms
that are more efficient at the machine level. True, good HLL programmers
can do this too (if they study the output of their compilers and have
a good idea about what's going on), but this rarely gets done.


Some of the best examples of efficient HLL code I've seen (definitely
non-portable) was the Berkeley String package for C. It was written
for a 32-bit machine and would do double-word comparisons and other
such stuff. I was only able to get about 25% better performance out
of some of the better routines by rewriting them in 32532 assembly
language (performance overall ranged from 25% to 200% better; a very
low payoff for hard core assembly optimization).


I don't have any numbers for you, because they would be meaningless
(the numbers vary for each (programmer,compiler) tuple). However, it
is safe to say that a *good* assembly programmer will never do any
worse than a compiler and sometimes significantly better.


Of course, the real question is "Is it worth the effort?" That, alas,
has to be answered on a case by case basis.


Randy Hyde


(p.s. Check out "The High Level Assembler" at http://webster.cs.ucr.
This is a tool that makes it a whole lot easier to write x86 assembly
code, so it enables the use of assembly language in some projects that
might not have been appropriate prior to HLA's development.)
[I believe that you can hand-code small routines and beat a compiler,
but not that you can hand-code large programs and do so. -John]

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