On (05 Apr 97) Herman Schonfeld wrote to Carey Bloodworth...
[ ... ]
 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. 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.
Optimizing for a Pentium consists of a lot more than using Pentium
opcodes - the majority of changes involve rearranging instructions to
allow parallel execution.  In many cases simply rearranging exactly the
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.
It seems to me that making such judgements based on a single program is
a bit shortsighted.  Just FWIW, I've run a rather large benhmark
consisting of over 200 separate programs with Watcom, gcc, VC++ and
BC++.  In this test, VC++ came first, Watcom and gcc nearly tied for
second, and Borland came in last.  However, even that doesn't tell the
whole story.  In the majority of tests, the compilers were very close to
equal.  However, each compiler produced quite poor code for at least one
test.  Watcom and gcc each produced quite poor code for a couple of
tests, and Borland did quite poorly on about a half dozen.
If you happen to use the kind of code that one of them did poorly at,
you could easily see any one of these compilers as producing code at
least 20% slower than any of the others, and in some cases barely over
half the speed of the others.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------