Re: High Level Language vs Assembly

francis.doyle@donovandata.com wrote:


> Hi,
> 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).


There have been a couple such studies, mostly performed by companies
trying to evalate the two different types of programming. The book
(naturally out of print) "phycology of programming" cites a number of
these. The problem is so much depends on the quality of the particular
programmers used for the study.


I give it to you that axiomatically a human can always outperform a
compiler. Reason being that a human programmed the compiler, and
therefore thought up and probally even tried out the various
optimizations used in the compiler.


Let's take two cases, which I'll call the multiply and address boundary
problems.


The multiply problem is that it may be more efficient, in time and
perhaps code size, to perform multiplies by short integers as
sequences of copies and adds:


X * 10 becomes Y = X; X += X; X += X; X += Y; X += X


or 2, 4, 5, 10.


These sequences are hard to find, but a human programmer could do it
with a chart. By what I have seen, nobody does, so score for the
compiler.


The boundary problem goes like this. Lets say you are making a 256
byte queue. You could do this by comparing the "wrap" pointers to the
end of the queue area, or you could just mask your pointers and locate
the queue area at a fixed address. ie., X = (X+1) & 0xff+base.


Now there is certainly nothing preventing a compiler from trying to
implement such a solution, but the mechanics of recognizing that such
a solution is possible from "normal" programmer code, plus moving
around the address areas to make it happen are pretty ridiculous. But
just try to tell a programmer who is attempting to make a 8051
processor buffer real time data that this is bad programming.


In my personal opinion, the decision to use HLL is rarely one of
efficentcy. Mostly it is about creating code that will be
maintainable and last. Most of those HLL vs. assembly comparisions
were done by folks attempting to prove that HLL was not as costly as
the assembly language freaks thought. The problem went away when the
assembly folks retired. The bottom line is that assembly is just to
much work.


--
Scott A. Moore is samiam@cisco.com

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