james@bigtex.cactus.org (James Van Artsdalen) (01/21/91)
In <3189@naucse.cse.nau.edu>, sbw@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@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789