This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Contributing tree-ssa to mainline
>
> On Sat, 17 Jan 2004, Steven Bosscher wrote:
> > On Saturday 17 January 2004 03:30, Richard Kenner wrote:
> > > My feeling is that "success" would be in showing at least one class of code
> > > where we see very significantly better code (at least a factor of two) and
> > > we see significant (around 10-20%) performance improvement in a larger
> > > class of test cases.
> >
> > You must be joking. I've added this beautiful quip to bugzilla:
> >
> > Moore's Law: "Advances in hardware double computing power every 18 months".
> > Proebsting's law: "Advances in compiler optimizations double computing
> > power every 18 years".
> >
> > Expecting tree-ssa to produce code better by a factor of two is simply
> > unreasonable.
>
>
> Whilst I agree that expecting a factor of two is asking for miracles,
> there are clearly significant gains to be made without pushing the
> envelope of current compiler theory.
>
> My greatest disappointment working on GCC's optimizations, is that
> try as I might I've only ever been able to push Andreas' SPECcpu2000
> benchmarks perhaps a percentage point or two higher. This on a platform
> where Microsoft's compilers score about 20% higher. Intel similarly
> claims about 20% better performance than GCC on average.
How did you got to this number?
This is definitly not the case of SPECint scpres I saw. My experience
is that we are about 2-3% behind AMD published results in 32bit mode.
On K8 in 64bit mode we get very comparable in between 64bit and 32bit on
slower CPUs. The difference grow as the CPUs get faster because of
higher memory overhead of many benchmarks. The published results are 7%
worse:
http://www.spec.org/cpu2000/results/res2003q4/cpu2000-20030922-02516.asc
http://www.spec.org/cpu2000/results/res2003q4/cpu2000-20030922-02519.asc
but this really suffers from apples to oranges comparsion.
This explains why pushing the scores up is very dificult.
Honza