Questions on X11R4 on ESIX...

James Van Artsdalen james at bigtex.cactus.org
Mon Jan 21 22:16:01 AEST 1991


In <3189 at naucse.cse.nau.edu>, sbw at naucse.cse.nau.edu (Steve Wampler) wrote:

> The recommendation is to use 'gcc' instead of the stock cc when
> building from source because (the claim is) gcc is about 30% faster.
> A benchmark I did on some other software showed gcc (-O
> -fstrength-reduce -fdelayed-branch) to be slightly slower than than
> the stock cc.

Delayed branches don't exist on an i386.

> Does anyone know if this is universally true, or likely a fluke for
> the software I benchmarked (Icon Language interpreter).  (hmmm, I
> don't think I used the -m80387 flag with gcc, but I wasn't testing
> floating point performance...)

I don't think the -m80387 flag does anything.  Gcc emits 387 code by
default.

PCC can still generate better 387 code than gcc in many cases.  Gcc is
only likely to win if there is significant opportunity for
optimization.

For ordinary integer code, I'd be surprised if PCC did as well as gcc.
It would certainly be worth fixing gcc if in fact gcc did worse.  It
is possible though: gcc is designed for load/store architectures with
many (>16) orthogonal flat registers, ie, any modern RISC and *not* an
i386/i387.  I am constantly amazed that anyone managed to graft 387
support into gcc.

Correctness is another reason to consider gcc for X: I believe that
gcc (1.39) now has better "correctness" than PCC.  I build & test X
with gcc with several different sets of options before each gcc
release.  And if something does slip through, you're more likely to
get gcc fixed than PCC...
-- 
James R. Van Artsdalen          james at bigtex.cactus.org   "Live Free or Die"
Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789



More information about the Comp.unix.sysv386 mailing list