[uae] Re: Some Progress With the Cocoa GUI
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: uae@xxxxxxxxxxxxx
- Date: Sat, 16 Apr 2005 15:56:00 +0200 CEST
Hi Richard,
Richard Drummond <evilrich@xxxxxxxxxxxxxx> wrote:
> On Friday 15 April 2005 08:49 pm, Axel Dörfler wrote:
> > That sounds interesting. How are you going to do this?
> Well, I'm really looking at other timer APIs and even trying to guage
> whether
> using a plain old gettimeofday() has much of an in impact on
> performance on
> the various host platforms.
I would guess it's pretty low overhead on most platforms, at least it
would be worth a try.
> OS X is easy to improve, though. The Mach kernel provides functions
> to get the
> PPC timebase counter and query its tick rate (thus no calibration is
> required
> and Mach's calibration should be more accurate anyway). I don't know
> if
> frequency scaling has an effect on the timebase register, however
> (since
> AFAIK it's not directly tied to CPU frequency, it might not).
I'm pretty sure it's not tied to the CPU frequency, so it should be a
good candidate.
> > Under BeOS, BTW you can easily read out the frequency of CPU, but
> > that
> > would probably help you only if you knew how fast the CPU in
> > question
> > is, right?
> How accurate is the frequency read-out - that is, is it actually
> measured by
> BeOS? If it is accurate then that should be enough, since (AFAIK) the
> TSC
> frequency is always the same as the clock frequency (knowing the CPU
> type
> might help to determine the situations where it's not).
It's measured by BeOS on startup; BeOS depends its timing on the TSC
itself (that's why it has numerous problems on CPUs that change their
frequency). So it's as exact as BeOS' timing.
> > At least, one could remember the CPU model, and its speed, so that
> > you
> > would only need to recalibrate if the model has changed.
> True.
>
> I'd actually like to find other high-resolution/low-overhead timers
> on x86
> platforms because of the problem that frequency-scaling has on the
> TSC. This
> means finding appropriate OS-specific high-resolution timer APIs.
There is probably just not that much choice in userland.
> Linux is a bit of a pain. Unfortunately I would suspect that very few
> people
> have a kernel built with high-resolution timer suppport. ;-)
Probably not :-)
> > (And some day, I promise, I will do the GUI integration :-))
> That's okay. I haven't had as much spare time as would like at the
> moment,
> either. ;-)
It's a pity :-)
Bye,
Axel.
Other related posts:
