This is the mail archive of the 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]
Other format: [Raw text]

Re: [GCC 3.x] Performance testing for QA

On Mon, 2 Sep 2002, Robert Dewar wrote:

> I disagree, gcc is a very interesting benchmark because of its locality
> patterns. It precisely is NOT a collection of tight loops, and unlike
> some of the other tests in SPEC, it is very hard to tune a compiler 
> to do artifically well on the gcc benchmark.
> Of course you want a big collection of benchmarks, and actually we advise
> users of GNAT to always test on their own code rather than benchmarks,
> but GCC is probably one of the better benchmarks around. 
> The trouble with the encoder/decoder examples is that they tend
> to concentrate on specific inner loops. That means that they are
> much more open to subversion (although interestingly, GCC is probably
> the one compiler where there is NOT a lot of effort spent specifically
> on getting benchmarks to work better).

However, encoding/decoding (especially encoding) is one area were speed 
really matters.  Encoding in real time (with out sacrificing quality) is 
still not passable with many codecs except on the newest machines.  
Unfortunately, because video work is so computationally extensive significant
portions of the code are often rewritten is assembly to take advantage of 
MMX etc instructions that many compilers do not produce normally.  This 
means that that pure C versions may not exist or if they do they are not 
coded optimally.

For example my PIII 500 is fast enough for me for most of my work but when 
I need to do video work I use my family P4.


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