Newsgroups: comp.os.msdos.djgpp From: Elliott Oti Subject: Re: Code optimisations Sender: usenet AT fys DOT ruu DOT nl (News system Tijgertje) Message-ID: <34612B8C.6463@stud.warande.ruu.nl> Date: Thu, 6 Nov 1997 02:29:32 GMT Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii References: Mime-Version: 1.0 Organization: Bipolar Widgets International Lines: 58 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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.