JC>On (05 Apr 97) Herman Schonfeld wrote to Carey Bloodworth...
JC>[ ... ]
 CB>GCC is not the best at optimization.  Plus, it only generates 486
 CB> code, not 586+ code.  Plus, the 486 code tweaking it does is for a
 CB> _generic_ 486.  What that means is that it aims roughly down the
 CB> middle of the field.  But there are a lot of different 486s, and
 CB> for some of them, the code GCC generates with -m486 can be less
 CB> than optimal.
 HS> I don't see how using pentium opcodes would improve performance.
JC>There
 HS> aren't that many of them, and I for sure have never used one. They
 HS> perform rare tasks, I doubt a compiler would ever need them.
JC>Optimizing for a Pentium consists of a lot more than using Pentium
JC>opcodes - the majority of changes involve rearranging instructions to
JC>allow parallel execution.  In many cases simply rearranging exactly the
JC>same instructions can be good for a 30% speed increase.
 HS> -------------------------------------------------------------------
 HS>    OPTIMIZATIONS                     |  Average Frames Per Second |
 HS> ------------------------------------------------------------------|
 HS> none                                 |           130              |
 HS> -O3                                  |           220              |
 HS> -O3 -fexpensive-optimizations        |                            |
 HS> -fthread-loops -funroll-all-loops    |           321              |
 HS>                                      |                            |
 HS> -O3 -fexpensive-optimizations        |                            |
 HS> -fthread-loops -funroll-all-loops    |                            |
 HS> -m486 -fomit-frame-pointer           |           402              |
 HS> -------------------------------------------------------------------
 HS> Maximum FPS I could get with watcom was around the 380's.
 HS> If you ask me, djgpp is good at optimizing.
JC>It seems to me that making such judgements based on a single program is
JC>a bit shortsighted.  Just FWIW, I've run a rather large benhmark
JC>consisting of over 200 separate programs with Watcom, gcc, VC++ and
JC>BC++.  In this test, VC++ came first, Watcom and gcc nearly tied for
JC>second, and Borland came in last.  However, even that doesn't tell the
JC>whole story.  In the majority of tests, the compilers were very close to
JC>equal.  However, each compiler produced quite poor code for at least one
JC>test.  Watcom and gcc each produced quite poor code for a couple of
JC>tests, and Borland did quite poorly on about a half dozen.
JC>If you happen to use the kind of code that one of them did poorly at,
JC>you could easily see any one of these compilers as producing code at
JC>least 20% slower than any of the others, and in some cases barely over
JC>half the speed of the others.
JC>    Later,
JC>    Jerry.
I'm pretty sure you haven't configured DJGPP properly.
Yes, I know it doesn't bring a friendly, easy-to-use GUI but that doesn't 
make the compiler slow.
Configure DJGPP for your machine properly then re-compile your programs, as 
seen in my reports table i was quite surprised. Watcom produced a whoppingly 
slow 230 fps. (djgpp nearly twice as fast)
... Error 941 -  CPU not found...
--- Ezycom V1.48g0 01fd016b
---------------