Mail Archives: djgpp/1996/11/28/12:39:39
From: | Dominic Hibbs <mtx064 AT coventry DOT ac DOT uk>
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | Re: Optimization
|
Date: | Thu, 28 Nov 1996 14:28:17 +0000
|
Organization: | Coventry University
|
Lines: | 48
|
Message-ID: | <Pine.OSF.3.91.961128134757.5457B-100000@leofric>
|
NNTP-Posting-Host: | leofric-fddi.coventry.ac.uk
|
Mime-Version: | 1.0
|
In-Reply-To: | <Pine.SUN.3.90.961127125213.12832A-100000@coop10>
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
On Wed, 27 Nov 1996, Glen Miner wrote:
>
> > : I am currently working on a program that grinds away in a recursive
> [snip...]
> What I'm concerned about is how well djgpp deals with the various data
> types etc. For example: if I don't really need 32bits worth of int, will
> things be faster if I declare my variables as short ints? It makes sense
> to me, but somebody sent me a mail stating the exact opposite.
On a 386 or better 32 bit arithmetic is exactly as fast as 16 bit
arithmetic but there is the 16 bit prefix which might slow the process
down if the prefetch queue is depleted. This always assumes that the 32
bit operands start on a four byte boundary - g++ will ensure that they
do. The compiler will also ensure that jumps are to four byte aligned
locations so that the instruction fetch from memory or the cache get the
full four bytes at one 'bite'. These machines really are 32 bit and
handling smaller chunks lead to the possibility of misalignment which
will cause delays.
> How well will djgpp deal with two dimentional arrays? Say I'm stepping
> through char MyArray[9][9] like so:
>
> for (x = 0; x < 6; x++)
> for (y = 0; y < 7; y++)
> MyArray [x][y] = SomeValue;
>
> Will it be smart and index it by a pointer so that it doesn't have to
> recalculate the address every time?
>
I don't have an Intel machine with DJGPP here at the moment but I
compiled the above on a MIPS machine using
g++ -S optim.cc -o optim.s
without optimising and
g++ -O3 -S optim.cc -o optim.s
with optimising and the
optimising did some VERY clever tricks and made the code MUCH smaller.
Unfortunately I am not really into MIPS assembly language. When I get
to an Intel machine with DJGPP I will see what it does.
Unfortunately I am not internet connected except on Tue, Wed and Thur
each week.
Dominic Hibbs
- Raw text -