Timing issues

Member
Posts: 117
Joined: 2010.09
Post: #1
Hi all,

I thought I would start another thread regarding this as it's starting to go off topic.

If I:

START_nano_timer


for(int k=0;k<100000;k++)
{
int f=1;
}

STOP_nano_timer

The delta between them fluctuates quite wildly as much as double sometimes (on device and simulator).
My question is how is it possible to get a nice silky fullscreen scroll (for example) when just a simple loop can vary *so* much over one frame.
I know there are lots of methods to split render/draw loop; measure frame time; add delta to anim's etc. etc. But this all compensates for the sporadic timings.
I have seen iphone games that appear to run at 60fps with no obvious jerk/compensation to any frame droppage i.e. they don't drop a frame.

But how can that be? when something as simple as the code above can take 0.1f on one frame and then 0.2f on another?

Is it possible that something outside the program is causing the slowdown?, I don't mean other iphone scheduled tasks but like the GPU somehow?; i.e. your own program causes the stall but 'later on' by the fact it actually did something. (hope that makes sense!).

I expected the timings for the above to be fairly consistent bar any 'outside' iphone operation affecting it (like loss of network, incoming call etc. etc. etc.).

Can anyone explain? and also how to combat this??

Cheers

Mark
Quote this message in a reply
Member
Posts: 23
Joined: 2010.08
Post: #2
First of all, for testing your profiling code I'd recommend you measure something that is time demanding. The problem with the above code is that it can be optimised away by the compiler. I am unsure what unit of time you are referring to in your measurements above - but the fluctuations in measurements might simply be that the code is faster than the precision of your timer. Try wrapping your timing code around Sleep/[NSThread sleepForTimeInterval:] to help debug your profiling code.

What timing-function are you calling within your profiling macros?

Below you'll find some general guidelines for achieveing smooth framerate:

CADisplayLink
Use CADisplayLink as suggested by the Opengl ES xcode template - and as long as your code per frame is faster than the FrameInterval you will have a steady frame rate. Unless you are barely completing your execution within the the FrameInterval your should not experience fluctuations in performance. If you can't fit execution within 60 FPS try halving your frame rate - a constant slow frame rate is perceived more fluid than a fluctuating high frame rate.

CACurrentMediaTime
Use CACurrentMediaTime() for animation timing. You will find discussions for why you should use CACurrentMediaTime vs CFAbsoluteTimeGetCurrent for animation timing by searching the net.

The Simulator is a simulator
You should avoid doing performance testing on the Simulator - it is not a measurement of actual performance and results may be either better or worse than on-device performance. Do all you performance testing on your targeted iOS-device!

Hope some the above advice will guide you in the right direction.

The Monkey Hustle - Now available on the App Store!
Quote this message in a reply
Member
Posts: 117
Joined: 2010.09
Post: #3
Hi there,

I am using the standard mach nanosecond timer.
The reason I gave that simple example was just for illustration purposes; if I put something more meaning full in the loop the same thing happens. The same problem occurs on real device aswell.
My timing routine is (borrowed from a previous poster, thanks for that):

mach_timebase_info_data_t base;

if (base.denom==0)
mach_timebase_info(&base);

uint64_t nanos = (uint64_t)(mach_absolute_time()*base.numer)/(uint64_t)base.denom;
return ((double)nanos*1.0e-9);

I simply don't see why it should fluctuate so much; other people can try around any code they like and you will see that the delta time taken varies wildly for no apparent reason.

Cheers
Quote this message in a reply
Member
Posts: 23
Joined: 2010.08
Post: #4
For the above code to work as intended mach_timebase_info_data_t needs to be declared static.
Code:
static mach_timebase_info_data_t base;

... if not your local variable base will contain garbage every time the function is executed.

The following article has a good explanation of how to use mach_absolute_time() for performance timing.

The Monkey Hustle - Now available on the App Store!
Quote this message in a reply
Member
Posts: 117
Joined: 2010.09
Post: #5
OOps yeah, sorry about that it was a cut 'n' paste slip up on my part; I have it as static.

Cheers
Quote this message in a reply
Member
Posts: 117
Joined: 2010.09
Post: #6
Still get well strange results between simulator and device.

My tests indicate the device is faster than simulator!!!!; which of course it can't be!!.
i.e. the delta between reading the timer, doing something, reading the timer again is MUCH less on real iphone.

Ermmmmm, I must be missing something here!
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #7
The simulator uses a software renderer for drawing, so it very well might be slower for many things.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 117
Joined: 2010.09
Post: #8
But my separate frames per second counter indicates it's faster.

I guess this method is tricky to use when using simulator against device comparison.
Quote this message in a reply
Member
Posts: 23
Joined: 2010.08
Post: #9
First of all, make sure you are initialising mach_timebase_info_data_t on the Simulator and the Device. Your computer and iOS device have different timebases. Do not assume that the timebase is constant between devices.

Secondly, the Simulator's goal is to help shorten your build/run-cycles. You can not use the simulator to measure you App's performance. And yes - although your computer has much higher specifications than your iOS device you can still bog down the Simulator with code that runs fast on a iOS device.

Our game, The Monkey Hustle, is unable to achieve it's frame rate in the Simulator yet runs smoothly on an iOS device because the code is optimised for these devices, not the Simulator.

The Monkey Hustle - Now available on the App Store!
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Raster timing bars markhula 23 7,254 Sep 28, 2010 12:56 PM
Last Post: markhula
  Accurate Physics timing bmantzey 29 11,602 Oct 29, 2008 01:13 PM
Last Post: bmantzey