From: Bora Ertung Newsgroups: comp.os.msdos.djgpp Subject: Re: Optimization Date: Wed, 27 Nov 1996 13:25:33 -0600 Organization: University of North Texas Lines: 80 Message-ID: <329C95AD.C3E@silo.csci.unt.edu> References: <57hg9b$or5 AT kannews DOT ca DOT newbridge DOT com> NNTP-Posting-Host: gab335pc.gab330.unt.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp 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. Read the gcc reference manual. > > 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? How did you notice the data conversions? There shouldnt be any problem running 16 bit data in 32 bit form. I dont understand what is your problem here??? How did you get the feeling that your program would actually get slower if you use 32 bit data instead of 16 bit data. Did you make a running time comparasion experiment in milliseconds resolution :)? BTW read the gcc reference for the usable switches for any floating point optimization if you really use them. Of course if you concern about memory usage stuff, you should consider short ints for specific locations.But hey, we have tons of memory to use with djgpp :). > > I may end up doing the heavily used functions in assembler, but I'd like For what? int stuff; -> 16 bit in borlandc int stuff1; -> 32 bit in djgpp , lets say what possibly would cause your program for slowing down? I dont see any difference between stuff and stuff1 for any integer calculation. > to make sure that the c code is as optimal as it can be first. Any Djgpp will heavly optimize your code for max speed :) if you put the correct optimization switches. > comments, suggestions or pointers are welcomed. > > Peace Peace! Where? P.S. I wonder what are you porting though because it is not clear in your post. Bora > -- > ===[ 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