On Tue, 2005-01-25 at 14:05, [EMAIL PROTECTED] wrote: > Message: 1 > Date: Tue, 25 Jan 2005 19:30:04 +0100 > From: Andreas Mohr <[EMAIL PROTECTED]> > To: Rein Klazes <[EMAIL PROTECTED]> > Cc: Lionel Ulmer <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > wine-devel@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. [EMAIL PROTECTED]
