This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: EGCS performance ?


>  RL> # GCC = egcs 1.1b                              781860.8
>  RL> # This is EGCS as of this morning.             829875.5
>  RL> # This is the SVR5 compiler from SCO.         1086956.5
>  RL> # This is Intel's Optimizing Compiler 2.1.4.  1582278.5
>  RL> # Same compiler without the i/p analysis.     1088139.2
> 
> ...I was surprised to see a large performance gulf (?) in such a
> simple test among EGCS and other "proprietary" compilers, and I'm
> wondering what is causing these gaps:

That "gulf" is actually closing in recent months.  I don't think that
anyone has reasonably claimed EGCS/GCC to generate the best code in the
industry for ia32 systems.

> - better intermediate optimizations (see the 50% improvement due
>   only to i/p analysis)
> ...
> - dedicated x86 schedulers
> - embedded-auto-recognition of Drystone benchmark code... :-)

Yes, the -ip stuff is a little tacky and not at all representative of
how people use compilers.  Personally, I suspect option #2 is the right
one.  The others you cite all have p6 optimizations and are highly
optimized for a single target instead of being a portable compiler
primarily and secondarily generating highly target-specific optimized
code.  After all, we're only now starting to really see P5 and P6
pipeline optimizations in EGCS, right?

These were also compilers produced by groups that had access to
"Appendix H", simulators, logic analyzers, vtune-like substances, and
other things that were long out of reach of the average GCC developer.

> If someone could test with a better benchmark EGCS vs. other
> compilers on different (RISC) architectures we could determine this
> performance gap still exists, and how much is due to x86 scheduling
> arcana (if they come on par) vs to machine-independent optimizations
> (if the 30-200% performance gulf stays).

I'll extend the offer that if someone feels "shorted" by these results
and has a benchmark that they'd like run on the entire suite for ia32,
I'll do it.  (It has to be written in a standard language.  I'm not
going to untangle a bunch of asms or __extension stuff.)

Dhrystone aside, I've run them against larger programs (xv, imagemagic,
etc.) and while they all have some strengths and some weaknesses the
relative ranking cited above (icc, udk/svr5 cc, osr5 cc, egcs/gcc)
pretty well matches my experiences.

RJL



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]