Mail Archives: djgpp/1997/11/06/18:47:16
Alistair Bain wrote:
>
> Ok don't want to start a war here but...
> I'm new-ish to C and I am looking for ways to speed up my code.
> I don't care a whit about readability and maitainability of code, or
> the size of code generated (As long as it runs on clean 16Mb system). I
> just want the best performance poss. (for games programming).
Unreadable, unmaintainable code is usually slow, hard to modify and
improve and even harder to debug. Not to mention you will bust a vein
trying to figure out what you wrote a year later :)
> 1) structs - Are they slow? what do they compile to?
structs are blocks of memory; different parts of that block are given
names so that it is easier for the programmer to manipulate parts. They
are slow if you pass large structs in their entirety to functions. Pass
pointers to structs instead, and marvel at the speed increase that that
brings.
> 2) unrolling loops - to what extent does -funroll-loops do this? Does -
> O3 do this? Adding both I get an excecutable of exactly the same size as
> using just -O. Should I just manually unroll the loops?
Your test program was probably so simple that the optimiser did the same
thing on all -O settings. Loop unrolling is not always a Good Thing.
Unrolled loops can frck(*) your cache, if you have one. The cache is a
Good Thing. Frking it is a Bad Thing.
> 3) global variables - I heard, read, dreamt something about them being
> faster. ie declare all variables at top of prog and just be careful
> about accessing wrong ones, etc.
Making every single variable in your program a global variable is asking
for trouble, and is not neccessarily faster. Accessing global variables
lying outside cached memory will frck your cache too. Keep 'em local,
keep 'em in the cache.
> Any help appreciated.
I used to think that the best way to get faster code was to use the best
compiler, and code up time-critical parts in assembler. The longer I
program, the more convinced I have become that to get major speed gains,
you have to *understand* the problem you are trying to solve, and
concentrate primarily on the algorithm used: modify, improve or replace
it by something better. Clear, crisp code, and good development tools
(gnu suite) aid this process tremendously.
> Self-proclaimed gods need not reply.
Gawd, that rules AC out. (Anybody who understands *that* reference is a
demi-god, too :)
------------ Elliott Oti ---------------
------------- http://www.fys.ruu.nl/~oti ---------
( * ) Frck: Overflow or invalidate i.e. cause the contents to be
flushed and refilled. No, there isn't a hidden pun in this one.
- Raw text -