Re: High Level Language vs Assembly

I recently rewrote in C, a PC routine that had been written in
allegedly tightly coded assembler. It runs about 3 times as fast in C,
and is much smaller and simpler. But the assembler code was a mess.


As an example where a compiler is faster, consider division. GCC
performs a divide by a constant using a multiply by the inverse. This
in turn can often be exexuted a a couple of shifts and adds.


So the binary to decimal routine that in C does a series of divides
gets turned by the compiler into a series of shifts and adds which is
much faster - except on tha Pentium IV where shifts are really
slow. Very few assembler programmers would be capable of that coding.


The mainframe is a different case because the instruction scheduling
is a lot simpler than on other platforms so the compiler can add less
value. Assembler is a lot more competitive on the mainframe for this
reason. Also the compilers on the mainframe do not generate as good
code quality as they do in more competitive markets. As an example a
subroutine call in C or COBOL will burn upwards of 120 instructions.


There is another issue on the mainframe. Most shops until recently
only had assembler and COBOL. A lot of sysprogrs would rather spend a
week writing something in assembler than a day doing it in COBOL. I
think there is some snobbishness going on there. Now that C is widely
available and can even be used to write exits things may change and
people may start using C.


Assembler can be a lot faster when you really want to tune something
to the nth degree. Have a look at the binary to and from decimal
routines in the Athlon tuning guides for some examples. I defy anyone
to write something that fast in C or in any other language. As another
example, a lot of the low level functions in C are done in hand coded
assembler (like memcpy, strcpy, etc) in GCC/glibc because the default
code generation cannot exploit the hardware sufficiently. We once
rewrote a table search routine in assembler on the mainframe and got a
93% reduction in CPU cycles. But it was a lot of effort and would not
be worth the bother most of the time.


The argument is more about productivity than speed. Life is too short
to write in assembler unless you really need to. HLLs are fast enough
most of the time. Anyway most of the cycles go in the database, or the
OS these days. The actual application code is a minor factor most of
the time these days.


I agree that a bad programmer or a bad algorithm will result in bad
code in any language.


Tim Josling


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

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