Re: Effectiveness of compilers today

andreasa@dhhalden.no (ANDREAS ARFF) writes:
>[Who produces fastest code: compiler or human?]


Depends on what the code is and what it does.


John Levine writes:
>[A human can almost always meet or beat a compiler on small chunks.]


True, but as mentioned elsewhere, for how much speed improvement.


pardo@cs.washington.edu (David Keppel) writes:
>It is usually hard for a human to do *worse* than a compiler because the
>human can simply use the compiler to produce code then examine the code
>for possible improvements. Humans are good enough at pattern matching
>that they can usually find improvements that the compiler missed.


Ok, now this is the entirely _wrong_ way to go about recoding something in
assembly language. If you examine the compiler's code, you will never get
anything more than about 10% speed improvement or so. The only time when
using assembly language is a real bonus, is when the task being peformed
is not very well suited to a compiler.


When recoding something in assembly, you need to take an entirely new look
at the problem and try to solve it using the full power of the machine at
hand, something that compilers are not particularly good at doing (taking
advantage of machine specific optimisations). The 80x86 range of CPU's
have an extensive range of _extremely_ fast instructions for manipulating
string data (well, for manipulating any data). Compiler's generally do not
produce code that takes advantage of these instructions (except for
inlining intrinsic functions like memcpy, strcmp etc and copying blocks of
data internally). If you can re-think your problem in terms of these more
powerful instructions, you can gain massive speed improvements (200-400%
plus). Now this is really worth the effort.


There are many other things that compiler just are _not_ good at doing,
and make perfect candidates for re-coding in assembly. Some of these are
multi-precision arithmetic, and shifts and rotates. High Level languages
like C just do not have the facilities for performing add's with carry,
rotates with carry's or even full precison integer multiplication (a 32
bit by 32 bit multiply produces a 64 bit product, which under C is a 32
bit product). If your code requires any of these things, recoding is
assembly can provide a significant speed improvement (CRC algorithms,
compression routines, you name it).


>In my (limited) experience it is ``easy'' to get a given code fragment to
>go 10-20% faster, but it's rarely worthwhile: if a routine is 10% faster
>and program spends 10% of its time there you've just sped up the program
>by 1%. While there are certainly programs where this is worthwhile, they
>aren't the ones that I usually work on.


We all know the old 80-20 rule (or even 90-10 rule) that most programs
spend 80% of their time in 20% of the code. Optimising the 80% that hardly
ever gets executed is a waste of time, but optmising that other 20%
certainly is.


No-one in their right mind is going to write an entire program in assembly
these days, but by judicious use of assembly in the right areas,
significant speedups can be had.
--
Kendall Bennett | Internet: |
RMIT Advanced Computer Graphics Centre | kjb@citri.edu.au |
CITRI Building, 723 Swanston Street | rcskb@minyos.xx.rmit.oz.au |
Carlton Victoria 3053 AUSTRALIA. | |
--

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