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