Reply-To: <arfa AT clara DOT net>
From: "Arthur" <arfa AT clara DOT net>
To: "DJGPP Mailing List" <djgpp AT delorie DOT com>
Subject: RE: djgpp and optimizations
Date: Wed, 16 Sep 1998 15:47:08 +0100
Message-ID: <000301bde180$e0d71f20$bb4d08c3@arthur>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.SUN.3.91.980916121635.5874O-100000@is>
Importance: Normal
Precedence: bulk

> > > > Also when is djgpp going to officially support optimizations
> > > for the pentium?
> > >
> > > When the GCC maintainers include them in the official GCC release.
> >
> > How about gcc 2.8.1 (-mpentium, -march=pentium, -mcpu=pentium etc)?
>
> These mainly change the compiler's decisions about which instructions
> are more/less expensive in certain contexts.  Pentium-specific
> optimizations in PGCC are much more than just that.

So how come I get such a poor performance when using -O7 (and other PGCC
stuff), whilst I get a huge speed boost using -mpentium (the gcc 2.8.1
version, not PGCC)? It's not just one program, either, it's anything
programmed using Allegro and most other programs I've written. For instance
a simple polygon filler may draw 20,000 polygons/second when compiled under
gcc 2.8.1, whereas it drops down to 3,700 when compiles in PGCC. The Allegro
demo game loses about 50fps in 1024x768 using VESA 2 Linear Framebuffer
mode.

I have a P200MMX, 64MB, 4MB ATI RAGE PRO TURBO if it helps.

And why on earth doesn't PGCC cater for the MMX chip?

> > What does -fstrength-reduce do, exactly, and why do some people
> report such
> > a huge speed increase when using it?
>
> -fstrength-reduce replaces expensive instruction by less expensive
> ones.  For example, multiplication is replaced with additions or bit
> shifts, etc.
>
> The problem is that this usually needs extra registers, and x86 has a
> few of them to spare.  If a function doesn't use too many registers,
> then -fstrength-reduce can be a big win; but if they are all used,
> -fstrength-reduce in a loop can mean a significant slowdown, since GCC
> will have to constantly reload some of the regsiters.

So like every other optimisation, it's a case of mix 'n' match.

James Arthur
jaa AT arfa DOT clara DOT net
ICQ#15054819