This is the mail archive of the
mailing list for the GCC project.
Re: [GCC 3.x] Performance testing for QA
- From: Kevin Atkinson <kevina at gnu dot org>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: tjw at omnigroup dot com, <Peter dot Sasi at t-systems dot co dot hu>, <aj at suse dot de>,<gcc at gcc dot gnu dot org>
- Date: Tue, 3 Sep 2002 14:17:04 -0400 (EDT)
- Subject: 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
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.