[XviD-devel] Re: Automatic benchmark / compile

Christoph Lampert xvid-devel@xvid.org
Sun, 19 Jan 2003 11:37:50 +0100 (CET)


On Sun, 19 Jan 2003, Felix von Leitner wrote:

> Thus spake Christoph Lampert (chl@math.uni-bonn.de):
> > Since it's very well 20% or more of a difference between "defaults" and
> > "optimal", I wanted to include a small shell-script into XviD
> > build/generic that could do some kind of automatic benchmarking and set
> > compiler option accordingly (or at least output the values, so everyone
> > can create his own CFLAGS ).
> 
> No, don't do that!  I want to compile my xvid on my fast Athlon but use
> the binary on my slow C3, for example!

Calm down, this is not supposed to become a _mandatory_ feature. We don't
force anyone to do anything... 

Having the same compiler flags for every CPU isn't optimal. Agreed? 
How to find the best flags for _any_ given CPU? Editing the flags by hand 
is fine if you know what to do. But who knows the best optimizaton flags
without testing? I guess noone. So you sit down and test for a couple of
hours? No. You just try two or three combinations that seems reasonable
and leave it like that. Might work. But also might not. Surely suboptimal! 

So if we have a script (_not_ the Makefile itself, of course), then run
the test. Copy/Paste the "best" CFLAGS to the Makefile and finshed. 

Looking for best flags on C3? Run the test on C3, copy the CFLAGS to your
Athlon machine's Makefile and compile. Or let it be and write the flags by
hand... it's your choice. 

Where exactly is the bad idea in this? 


> The best way to do this is to have different versions in the binary, run
> them all five times on a warmed cache, and take the lowest cycle count
> of the five.  Then choose the function with the lowest count.

And exactly that's why I want the script to do. 
 
> > * Does anyone else of you with knowledge in /bin/sh programming volunteer
> > for that?
> 
> I know how to do it, but it really is a bad idea.
> 
> > * Is there a similar method for Windows?
> 
> Who cares? ;)

no further comment.

gruel