Date:	Mon, 21 Nov 94 19:48:25 -0500
From:	dj AT stealth DOT ctron DOT com (DJ Delorie)
To:	eliz AT is DOT elta DOT co DOT il
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: Program fast w/BC++, slow w/DJGPP

> I tried different combinations of other optimization-related switches, but
> none produced any significant effect.  I can't say I've tested all the
> switches which might be relevant, so if you have a list of such switches
> to test, go ahead and tell me, even if the list is long.

There are only a few optimizations that -O3 doesn't turn on, and the increase
isn't significant enough to make up for your numbers.

> I also thought that the GCC-compiled program might be a little larger, so
> it just happens to not fit in the CPU (L1) or secondary (L2) cache, so
> I've compiled the GCC version with all int's #define'd to be shorts
> (that's what BCC does)--nothing happened.

Few programs fit in the 8K L1 cache.  Paging might be the culprit, so
set "GO32=topline" to watch the activity.  The R/P in the upper left
tells you if the CPU is in real or protected mode (non-dpmi only).  In
your case, it should stay at "P".  You can also see paging activity in
the upper right corner.

Also, try disabling interrupts during the computes.  Although this
messes up the clock, interrupts are more expensive in protected mode
than in real mode (well, slightly, and there aren't that many of
them).  Also, kbhit() might be more expensive than you think.  Check
the call profile for functions that take up little CPU but get called
a lot.

Also, short math is slower than long math due to the operand override
prefix codes.  However, long constants are lower than short constants
if they're not aligned.  GCC should automatically align them.

Also, check the gcc info pages for the -f* options to gcc; there may
be some that -O3 misses that are useful.  The -fomit-frame-pointer
should speed things up, but makes for interesting code problems in
DPMI mode.

- Raw text -