Date: Thu, 28 Nov 1996 08:06:20 -0500 (EST) From: Glen Miner To: Eli Zaretskii cc: djgpp AT delorie DOT com Subject: Re: Optimization In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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