Mail Archives: djgpp/1996/11/28/01:21:36
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.
- Raw text -