Mail Archives: djgpp/1996/11/27/18:16:01
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
- Raw text -