Re: Tools

[Pierre Phaneuf <pp@ludusdesign.com>]

Mithras wrote:

> I can understand that.  I suppose the divider would be just how important
> runtime performance is to you, versus other fair considerations like
> portability, natch.

Also of note is the value of your time. Spending ten times as much
effort on a piece of code for 1% increase in performance isn't worth it,
maybe put in a comment about possible optimisation opportunity and leave
it for later (with open source, sometimes people see that comment and
will spend the time on it and send you a patch, which is cool).

Personnally, I think the comment by Michael Abrash had more truth in it
at the time it was written. Now, compilers are *much* better than they
were, and processors are so much more complicated, with tens or hundreds
of rules interacting together where you're bound to miss something.
Think of CPUs like the Itanium (eek!) where it was a conscious design
choice to put a *lot* of work in the hands of the compiler.

Me, I consider doing assembler only in cases where very obvious gains
are obtainable, like in my audio mixer example, where a branch on carry
right after the add would be much better than a separate test like is
done by the compiler for the 'if' (it doesn't get that I'm looking for
overflow, and *I* know). Also, using MMX or 3Dnow! instructions in some
tight loops can make things significantly faster (and the SSE
instructions too I guess, but I never looked much at them, I don't have
a Pentium III to try them out).

> > gcc -S something.c    <-- will produce something.s which is the assembly
> > for the C program
> 
> I do appreciate the tip for producing assembly code from gcc.

Very useful to compare how two higher-level language constructs compares
in assembly output, or see the effects of optimization options.

-- 
Pierre Phaneuf
http://ludusdesign.com/