On 26 Jan 2005 09:59:14 -0800, you wrote:
>
> 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, rig
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,
> >
> 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
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
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.
> >
> >
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?
> > &
On Tue, 25 Jan 2005 19:30:04 +0100, 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
On Tue, 25 Jan 2005 19:30:04 +0100, Andreas Mohr wrote:
> and that thus the Windows function is equally highly optimized,
> certainly much less slow than a gettimeofday() call.
These days gettimeofday() is very fast because the kernel vDSO system is
used to optimize the syscall overhead.
thanks -
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' met
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
On Mon, Jan 24, 2005 at 11:58:37AM +0100, Rein Klazes wrote:
> > > + counter->QuadPart = counter->QuadPart / ( cpuHz / 1193182 ) ;
(...)
> FYI, I traced this in windows (2K, XP), that gets the counter through
> some inp's and outp's to 0x40/0x43. That is historically an 8253
> programmable interva
On Sun, 23 Jan 2005 14:29:02 +0100, you wrote:
> > --- wine/dlls/kernel/cpu.c 2004-12-29 12:09:47.0 +0100
> > +++ mywine/dlls/kernel/cpu.c2005-01-19 12:39:15.0 +0100
> > @@ -188,7 +188,8 @@ BOOL WINAPI QueryPerformanceCounter(PLAR
> > /* i586 optimized version */
> >
> --- wine/dlls/kernel/cpu.c2004-12-29 12:09:47.0 +0100
> +++ mywine/dlls/kernel/cpu.c 2005-01-19 12:39:15.0 +0100
> @@ -188,7 +188,8 @@ BOOL WINAPI QueryPerformanceCounter(PLAR
> /* i586 optimized version */
> __asm__ __volatile__ ( "rdtsc"
>
13 matches
Mail list logo
