PerformanceCounterFrequency fix

[Michael Ost]

On Tue, 2005-01-25 at 23:58, Rein Klazes wrote:
> On 25 Jan 2005 14:22:40 -0800, you wrote:
> 
> 
> > > I'm quite certain that many programs use that function for extremely time critical code
> > > (games, anyone??), and that thus the Windows function is equally highly optimized,
> > > certainly much less slow than a gettimeofday() call.
> > > 
> > > This should remain based on rdtsc IMHO, or on equally suitable and fast methods
> > > (ACPI counter, ...).
> > > 
> > > Or did you actually test it with programs calling it a large number of times,
> > > or test its performance behaviour on Windows?
> > >
> > > Andreas Mohr
> > 
> > Our system uses the performance counter all the time in extremely time
> > critical code. If the call is anything more than a few cycles with
> > absolutely no chance of blocking, we are hosed!
> > 
> > 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".
> 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. 

OK. Sorry. My ebullience has once again resulted in poor mailing list
style! Not the first time. I'll turn on "serious careful engineer mode".
Let's see how I do... %) 

My concern isn't the number of cycles. It sounds like the function runs
very quickly, even faster than in Windows. That's great news.

But I am concerned about blocking or preemption. I assume that the new
call doesn't hit the wineserver, right? Is there any other thread sync
required (critical sections, etc) for gettimeofday() which might cause
the new implementation to block? I don't know how it is implemented, but
it sounds like a "system call" which makes me suspicious. I know that
Windows developers class QueryPerformanceCounter as a "system call
that's safe to use in real time" so that's why I am trying to keep tabs
on it.  

We don't have control over what APIs our hosted audio plugins use. They
are written by other developers, and given to us in binary form. So we
have to keep a close eye on APIs that plugins commonly use during real
time processing.

Sometimes plugins make calls they shouldn't from a r/t priority thread
--- like InvalidateRect. I guess in Windows such calls work without
blocking almost all the time. But that isn't the case in Wine. 

The Wine Semaphore implementation has caused us problems as well. They
are much more likely to block in Wine than in Windows. One plugin used
it where it shouldn't and its audio processing execution time went
completely erratic as it blocked on the wineserver.
 
Anyway, thanks for your attention to this issue. It sounds like Receptor
(our product) will be fine with this change. ... mo