At 3:35 PM -0800 3/8/99, Adam Dingle wrote:
>The text file created by the profiler in the emulator contains a number of
>statistics at the end of the file; these include "cycles counted" and "total
>clocks".  I have found that these two values often differ by about 10%.  Can
>anyone give a precise explanation of the difference between these?

As the author or the profiling code, I'll give it a shot.

As you've surmised, "cycles counted" sums up the total number of cycles in
all the functions and interrupts in the tree.  It's basically the sum of
what shows up in the profiling output.   "total clocks" is just the delta
between the clock counter when profiling was started and the clock counter
when profiling finished.

In theory, these two numbers should be identical--every clock cycle should
be accounted for.  In practice, this isn't the case, and I've never quite
been able to pin down exactly why.

I *think* it has something to do with how Poser works its way into the OS.
Sometimes Poser itself makes OS calls, and the profiler is currently
configured to not count time spent in those calls against the functions,
because those calls don't happen on the real device.  (the global
gProfilingCounted gets set to false to implement that.)

I intended the cycle counting to also stop when Poser was making OS calls,
but apparently that's not happening, or perhaps something else is
responsible for the extra clocks.

Whenever I've timed operations with a stopwatch on a real device and
compared it to Poser's profiler times, I've always found them in agreement
to a tenth of a second, which is about as good as I can get with a
stopwatch, so I didn't worry about the mismatch too much.  The .1 second
accuracy seems good even over operations that take several seconds, and at
that point I stopped improving it becasue the profiler was "accurate
enough" to do a lot of optimization, even if it's not perfect.

Also, if you look in Profiling.h or Profiling.c you'll see some notes on
other minor inaccuracies in the profiler cycle counting scheme.

If someone wants to take the time to improve the accuracy of the profiler,
I'd be more than happy to help.  Currently I'm busy with other things.

                                --Bob


Reply via email to