I encountered an unexpected behaviour of the 'mach_absolute_time()'
function -- maybe it's just undocumented, but Google didn't provide
any clues.
It's not crucial, though, but it took me some time to figure out
what's going on, so maybe somebody has a technical explenation.
Here's the issue...
to measure execution time of my code, I use following function:
-----snip-----
#include <mach/mach_time.h>
static const int64_t kOneMillion = 1000 * 1000;
int getTimeInMilliseconds()
{
static mach_timebase_info_data_t s_timebase_info;
if (s_timebase_info.denom == 0) {
(void) mach_timebase_info(&s_timebase_info);
}
// mach_absolute_time() returns billionth of seconds,
// so devide by one million to get milliseconds
return (int)(mach_absolute_time() / kOneMillion);
}
-----snip-----
This works perfectly fine; as soon as the app launches, the values
returned by 'getTimeInMilliseconds()' are very low (starting at
zero), increasing during runtime of the app.
But on an Intel-Mac, the time stamps are increased differently than
on a PPC Mac:
On Intel hardware, the time is increased constantly, independently
from the programs current cpu usage.
On PPC hardware, the time is increased only when the cpu is used.
That is, when calling 'sleep()' or 'usleep()' on PPC hardware, the
timer which is queried by 'mach_absolute_time()' appearently is
stopped, whereas it continues to run on a Intel hardware.
Is there an explanation what is causing this difference in behaviour?
Best regards,
Dirk Stegemann
_______________________________________________
Do not post admin requests to the list. They will be ignored.
PerfOptimization-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
