begin quote On Tue, 18 Nov 2003 17:47:03 +0200 Sami N��t�nen <[EMAIL PROTECTED]> wrote:
> On Tuesday 18 November 2003 05:44, Jason Stubbs wrote: > > On Tuesday 18 November 2003 09:57, Chris Graves wrote: > > > interesting article about selecting gcc optimizations (found on > > > OSNews.com). > > > > > > http://www.coyotegulch.com/acovea/index.html > > > > Quite a good article! Shame it doesn't apply to us. I can't remember > > where I read it, but the gcc crew were talking about doing an > > overhaul (or at least an investigation) into -O1 -O2 and -O3. As > > previous informal benchmarks done by Gentooists show, with the > > current GCC compilers (including 3.3) -O2 can often produce faster > > code than -O3. This is meant to have been addressed in 3.4. > > > The most distracting point in his teest was the fact that all tests > were running in isolated environment ie no other running processes. > This lets the whole 11k instruction cache of P4 for the one process, > so that the penalty of unrolling and inlining raises quite a bit from > normal desktop systems. > This is a very good point, and ties well in with the question of the size of the chosen benchmark algorithms. Since smaller, tighter algorithms (thats very popular in benchmarks. gzip, bzip2 and so on) fit nicely in the cache, whearas a "large" benchmark (mp3 encoding for example) has many algorithms and suffer penalties due to their size not fitting in cache, making O3 in many cases an adverse optimization. Do note though, Lame is not a good benchmark due to cpu detection and assembler code. You'd need a straight-C or C++ code to do good benchmarking on gcc. //Spider -- begin .signature This is a .signature virus! Please copy me into your .signature! See Microsoft KB Article Q265230 for more information. end
pgp00000.pgp
Description: PGP signature
