on 1/16/07 5:22 AM, Mike Kluev at <email@hidden> wrote:
> On Mon, 15 Jan 2007 10:46:37 George Warner <email@hidden> wrote:
>
>> Just for the record UpTime (and CFAbsoluteTimeGetCurrent and
>> mach_absolute_time) is still the lowest-overhead and highest precision clock
>> on PPC or Intel. (IIRC UpTime & CFAbsoluteTimeGetCurrent both call directly
>> thru to mach_absolute_time now.)
>>
>> #import <mach/mach_time.h>
>>
>> uint64_t t0 = mach_absolute_time();
>>
>> // do your timed stuff here!
>>
>> uint64_t t1 = mach_absolute_time();
>>
>> // compute the delta
>> uint64_t t = t1 - t0;
>>
>> // this is the timebase info
>> mach_timebase_info_data_t info;
>> mach_timebase_info(&info);
>> double nano = 1e-9 * ( (double) info.numer) / ((double) info.denom);
>
> For the record, how aggressively may we cache the result of
> mach_timebase_info? Is it guaranteed to be a constant for a
> program run or could it change with e.g. the change of
> processor speed?
I don't have an official answer for you on this one. In theory it seems like
power cycling would be changing that value however the test cases I wrote to
catch those changes (On PPC & Intel desktops and portables) was never
successful. I'm now of the opinion that these value are intentionally kept
constant to allow differential timings to return consistent results even
during power cycling.
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
