Date: Thu, 28 Nov 1996 08:16:13 +0200 (IST) From: Eli Zaretskii To: Glen Miner Cc: djgpp AT delorie DOT com Subject: Re: Optimization In-Reply-To: <57hg9b$or5@kannews.ca.newbridge.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 27 Nov 1996, Glen Miner wrote: > I am currently using the -O3 compile option; is there any other switches I > should be enabling or disabling? I never need to debug the code, so symbol > information is not an issue. Symbol information is not an issue anyway: GCC can optimize *and* have the symbols (i.e. -O3 and -g don't contradict). There's a whole chapter on optimization options in the GCC on-line docs. There are some optimization options which could make your program faster or slower (depending on how the code is layed out) and therefore they are disabled by default. I suggest you try them all and profile your code after using every switch, so you'd see the differences. (I saw some real-world programs where even -O3 made them slower than -O2.) If the program is deeply recursive, then -fomit-frame-pointer might make it quite a bit faster (and will disable debugging and crash traceback). Another option that might help with many function calls is the one that makes GCC pass parameters in registers (however, it has its caveats, which see in the docs). > int is no longer 16 bits long. Since I don't really need a 32 bit int in > the core code would it help at all for me to change things to "short > unsigned int"s? Mixing 16-bit and 32-bit code will usually *slow down* your program by about a factor of 2, due to the override prefixes which eat up a cycle. > I may end up doing the heavily used functions in assembler, but I'd like > to make sure that the c code is as optimal as it can be first. Any > comments, suggestions or pointers are welcomed. If you need a speedup of more than a factor of 2-3, you should (IMHO) consider changing the algorithms in the hot spots before going to assembly.