From: "D. Hibbs" Newsgroups: comp.os.msdos.djgpp Subject: Re: Optimization Date: Wed, 27 Nov 1996 19:27:07 +0000 Organization: Coventry University Lines: 34 Message-ID: References: <57hg9b$or5 AT kannews DOT ca DOT newbridge DOT com> NNTP-Posting-Host: rowan-fddi.coventry.ac.uk Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <57hg9b$or5@kannews.ca.newbridge.com> To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp On 27 Nov 1996, Glen Miner wrote: > I am currently working on a program that grinds away in a recursive > algorithm tens of thousands of times over a small group of local data. It > doesn't do _any_ io, and only calls a select few functions. Due to the > immense number of calculations required, this is painfully slow. I've > optimized the algorithm a fair amount, and plan to improve it more, but > that is only one part of the optimization process. > > 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. > > Can anyone suggest any hard and fast rules for c code optimization under > djgpp? I mean, right now I have a 9x9 array of bytes, and try to index all > of the data in it with pointers. Is this necessary, or is x=MyArray[4][6] > just as good? > > Since this code _is_ a port, I have noticed some data conversion too. An > 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? > > 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 stop the compilation at the assembler stage and look at the code you may see how to improve the efficiency. Try various methods and look at the code produced. The way to stop at the assembler stage is gcc -S progname.cc -o progname.s Dominic