🚀 go-pugleaf

Bob Wildfong (bobw@csg.uwaterloo.ca) wrote:
: 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,
: 
: 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).

Depends which way you look at it. I can't agree entirely from where I am
standing - try to be cunning with a PC C compiler and you often end up
making things worse. I agree with the bit about addressing modes, except
that when you (ie someone programming in the 'freedom language' (getting a
bit too biassed there...)) realise that there is a much faster way of doing
something and it works then there isn't much room for argument. Addressing
bytes for example on the wrong PC C compiler can really slow things down,
and in this case I was using 8-bit weights in my filter.

But assembly isn't the machine's language - machine language is (no
kidding!). Assembly is a step 'up' and you lose a bit (eg you don't
automatically know the size and alignment of instructions). Going 'up' a bit
further you get C and lose a bit more of whatever gets lost. And so on. If
you need to know about your code's machine implementation (well, want) you
have to know what sort of mess those unintelligent computer-aided helpers is
going to create either by observing the end product or by experience. That's
my opinion anyway and is the reason I find assembly useful (ie experience is
rare for me!). Something like that anyway...

Antony.

: 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