PerformanceCounterFrequency fix

[Michael Ost]

On Tue, 2005-01-25 at 14:05, wine-devel-request at winehq.org wrote:
> Message: 1
> Date: Tue, 25 Jan 2005 19:30:04 +0100
> From: Andreas Mohr <andi at rhlx01.fht-esslingen.de>
> To: Rein Klazes <wijn at wanadoo.nl>
> Cc: Lionel Ulmer <lionel.ulmer at free.fr>, wine-patches at winehq.com,
>    wine-devel at winehq.org
> Subject: Re: PerformanceCounterFrequency fix.
> 
> Hi,
> 
> On Tue, Jan 25, 2005 at 06:44:04PM +0100, Rein Klazes wrote:
> > On Mon, 24 Jan 2005 15:08:56 +0100, you wrote:
> > 
> > > > How bad is it to use the gettimeofday() method?
> > > 
> > > In my opinion, the RTDSC method should be suppressed from the code and we
> > > should always use the 'gettimeofday' method (despite the penalty hit of a
> > > syscall).
> > 
> > I was more concerned about the accuracy of gettimeofday (not
> > incrementing in usec's). So I did a small test and I find it behaves
> > very nicely.
> > 
> > That was the only reason I could see to justify the rdtsc method, so
> > here it goes. As the cpuHz variable is not used anymore, we might as
> > well move it to ntdll.
> (sorry for not replying earlier - no time :-\)
> I'm not sure why you'd want to base it on gettimeofday().
> This is a terrible idea IMHO.
> 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...
mo

===================================
Michael Ost, Software Architect
Muse Research, Inc.
most at museresearch.com