Mail Archives: djgpp/1996/11/27/10:28:39
From: | gminer AT Newbridge DOT COM (Glen Miner)
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | Optimization
|
Date: | 27 Nov 1996 13:38:51 GMT
|
Organization: | Newbridge Networks Corporation
|
Lines: | 30
|
Message-ID: | <57hg9b$or5@kannews.ca.newbridge.com>
|
NNTP-Posting-Host: | 138.120.136.238
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
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.
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 -