🚀 go-pugleaf

In article <Bz0J8F.4IC@cantua.canterbury.ac.nz> deanaj@elec.canterbury.ac.nz (A. J. Dean) writes:
>For example I was able to speed up an 80x86 FIR filtering routine over 15*
>over the original hand optimised _assembly_ (ie we're not talking about the
>usual assembly vs C argument here) just buy taking advantage of the needs of
>the application and assembly's freedom. Things like unrolling the right
>loops the right number of times, using the most cunning addressing modes,
>lookup tables etc. Until I see this sort of 'cunning' built into a compiler
>(or assembler) I will never believe that assembly has lost it. To each their
>own opinions...
>
>Antony.

While it's true that most C optimizers don't do these "cunning" things,
one can just as easily use the same tricks to hand-optimize C code (write
the code using unrolled loops and lookup tables in the first place).  You
can't exploit handy addressing modes, but IMHO you rarely save much by
doing so anyway, since the addressing modes which compilers tend to not use
are hardly ever useful in real applications (now and then doesn't count for
much).

So you lose the elegance of the original "un-optimized" C code, but I'd
rather maintain a messy C routine than a messy assembler routine.

Yet another $0.02  (must have about a buck by now)

Bob Wildfong
University of Waterloo