PerformanceCounterFrequency fix

[Andreas Mohr]

Hi,

On Wed, Jan 26, 2005 at 08:58:13AM +0100, Rein Klazes wrote:
> On 25 Jan 2005 14:22:40 -0800, you wrote:
> > The application is an embedded audio plugin player. The audio is
> > processed with SCHED_FIFO and needs to be as deterministic and fast as
> > possible.
> > 
> > I hope this fix/change doesn't jeopardize our product's use of Wine...
> 
> You are of course in an excellent position to quantify better then
> "extremely time critical" and "few cycles". Just try the patch and tell
> us when you are "hosed".
Whoa, seems like I started an avalanche with my posting ;-)

> I have done a few further tests. A loop like:
> 
> 	for(i=0;i<10000000;i++)
> 		QueryPerformanceCounter( &count);
> 
> takes under Windows 2k, on some hardware 45 seconds. Under Wine on the
> exact same hardware it takes (with the patch) 13 seconds. 
Wow!! I'd never have expected that. So it seems the optimized Linux syscall
is just that: optimized, highly :)

> If you do a series of QueryPerformanceCounter:
> 
> 		QueryPerformanceCounter( carr[0]);
> 		QueryPerformanceCounter( carr[1]);
> 		QueryPerformanceCounter( carr[2]);
> 		QueryPerformanceCounter( carr[3]);
>     	        QueryPerformanceCounter( carr[4]);
> 		...
> 
> and print the results, I see on Windows that the counter increments 4 or
> 5 steps between the calls. Under Wine it is 1 or 2.
Which is obvious as well since the execution time under Wine is lower,
so the deltas should be lower as well.

> So in these simple benchmarks, Wine beats Windows by a factor of three.
> I call that satisfactory, wishing Wine would do that in other areas as
> well.
Damn right!

> Also note that QueryPerformanceCounter Timer takes hundreds of cycles.
> In an extremely time critical application that would be hosed if it
> takes more then a few cycles, I would not recommend the use of this call
> at all.
Yup. I'd say that the goal is not necessarily to be terribly faster than
Windows; the goal is to have comparable behaviour (being much faster than
Windows here can easily be a problem on its own, you bet!).

As such the new implementation should be perfect.

Sorry for that wonderful false alarm! ;-)
(but I'd say the ensuing discussion certainly was useful)

Andreas Mohr