CODEWITHSUNDEEP
ios
leremjs
leremjs

Reputation: 1069

Erratic timing results from mach_absolute_time()

I'm trying to optimize a function (an FFT) on iOS, and I've set up a test program to time its execution over several hundred calls. I'm using mach_absolute_time() before and after the function call to time it. I'm doing the tests on an iPod touch 4th generation running iOS 6.

Most of the timing results are roughly consistent with each other, but occasionally one run will take much longer than the others (as much as 100x longer).

I'm pretty certain this has nothing to do with my actual function. Each run has the same input data, and is a purely numerical calculation (i.e. there are no system calls or memory allocations). I can also reproduce this if I replace the FFT with an otherwise empty for loop.

Has anyone else noticed anything like this?

My current guess is that my app's thread is somehow being interrupted by the OS. If so, is there any way to prevent this from happening? (This is not an app that will be released on the App Store, so non-public APIs would be OK for this.)

I no longer have an iOS 5.x device, but I'm pretty sure this was not happening prior to the update to iOS 6.

EDIT: Here's a simpler way to reproduce:

for (int i = 0; i < 1000; ++i)
{                                         
    uint64_t start = mach_absolute_time();
    for (int j = 0; j < 1000000; ++j);   
    uint64_t stop = mach_absolute_time(); 
    printf("%llu\n", stop-start);         
}

Compile this in debug (so the for loop is not optimized away) and run; most of the values are around 220000, but occasionally a value is 10 times larger or more.

Upvotes: 2

Views: 803

Answers (3)

Maxim Kholyavkin
Maxim Kholyavkin

Reputation: 4573

It happens while app spend some time in another threads.

Upvotes: 1

sup
sup

Reputation: 807

mach_absolute_time() is actually very low level and reliable. It runs at a steady 24MHz on all iOS devices, from the 3GS to the iPad 4th gen. It's also the fastest way to get timing information, taking between 0.5µs and 2µs depending on CPU. But if you get interrupted by another thread, of course you're going to get spurious results.

SCHED_FIFO with maximum priority will allow you to hog the CPU, but only for a few seconds at most, then the OS decides you're being too greedy. You might want to try sleep( 5 ) before running your timing test, as this will build up some "credit".

You don't actually need to start a new thread, you can temporarily change the priority of the current thread with this:

struct sched_param sched;
sched.sched_priority = 62;
pthread_setschedparam( pthread_self(), SCHED_FIFO, &sched );

Note that sched_get_priority_min & max return a conservative 15 & 47, but this only corresponds to an absolute priority of about 0.25 to 0.75. The actual usable range is 0 to 62, which corresponds to 0.0 to 1.0.

Upvotes: 1

Arnaud SmartFun
Arnaud SmartFun

Reputation: 1593

In my experience, mach_absolute_time is not reliable. Now I use CFAbsoluteTime instead. It returns the current time in seconds with a much better precision than the second.

const CFAbsoluteTime newTime = CFAbsoluteTimeGetCurrent();

Upvotes: 1

Related Questions