Mail Archives: djgpp/1997/05/13/06:19:10
jon <quacci AT vera DOT com> wrote
> I'm interested in understanding what can be done to speed up straight
> C code. In the specific thing I am writing, I've already done the
> obvious things, like switched most calcs from FP to integer, using bit
> shifting wherever possible for multiplying and dividing, etc.
Duh.. That must have been from a very old source of information. On the
Pentium (I assume you use one), FP is even faster than integer performance.
For simple mults and divs by powers of 2, use your average
multiplication/division instruction. The code is more readable, and the
compiler (at least most compilers) will optimize this to a shift for you.
> But is
> there a complied source of information on just
> what-is-faster-than-what? Like, does running a "for" loop by
> decrementing rather than incrementing actually save a cycle? or does a
> "case" command actually beat a series of "if"s? Do global variable
> speed things up?
No, there is no such sort of advice. (At least none I know of)
Apart from that, if you're chasing single cycles, I suggest you switch to
assembly coding anyway. If you MUST shave off that last extra cycle, no
compiler in the world will help you.
However, I suggest you code the thing in C firsthand. This will give you a
better feeling for the algorithms involved.
After that: Profile, profile, profile.
90% of a programs runtime are spent in 5%-10% of its code. So there's no
need to optimize the rest.
>
> DJGPP is my compiler of choice, if that makes a difference.
It makes a difference, since every compiler has different problems with
optimizing. And before another flame war starts:
There's no such thing as the best compiler, IMHO.
Bye,
Robert
BTW: If you can read this, please reply via EMail. I'm not sure about the
posting abilities of my news server.
- Raw text -