Mail Archives: djgpp/1996/11/28/08:14:15
> There's a whole chapter on optimization options in the GCC on-line docs.
Hmm, I was skimming through the info directory and couldn't find exactly
what I was looking for. I'll look closer.
> 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).
Hmm, I'll look into this. I'm not so sure that I can do without a frame
pointer, though. How would it use local variables then?
> 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.
This is quite odd. I'm going to have to re-read the old pmode optimizing
doc I have lying around somewhere. Until now, all my work has been in
real mode...
> 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.
I've been optimizing the algorithms for the better part of 6 months.. :)
If I can't suck much more performance out of the compiler, I'll have to
move to asm.
Peace
===[ Gabo / [ABC] : gaminer AT undergrad DOT math DOT uwaterloo DOT ca ]===================
Latest ABC Shogi: http://www.undergrad.math.uwaterloo.ca/~gaminer/shogi.html
"What Greenpeace spends in a year General Motors spends in four hours" -Moby
- Raw text -