[SOLVED]: Stopwatch accuracy in debug mode

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I want to measure the execution time of a function that uses a lot of math. If I would have the board here I will just toggle a GPIO line to measure the time with an oscilloscope. But right now I cannot do this. The second option that comes in mind is to use the stopwatch of the simulator. Of course I need to compile in debug mode in order to catch the breakpoints placed at the begin and at the end of the function.

 

The question is: how reliable could be this value?

I have hundreds of trigonometrics functions and I'm afraid about the compilation in debug mode: does this mode alter the time-execution of such a functions?

This topic has a solution.
Last Edited: Wed. May 3, 2017 - 06:58 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The stopwatch counts CPU cycles and should be totally accurate in telling you how many machine cycles a section of code will take to execute.

 

Note that for trig (and arithemtic in general) the execution time IS likely to be data dependent.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Note that for trig (and arithemtic in general) the execution time IS likely to be data dependent.

 

yes - I'm going to simulate a whole set of data (i.e. a lot of runs) and then take a mean value.

Thanks!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not what you asked, but two additional thoughts came to mind which I'll take the liberty of mentioning.

 

With "lots of Trig functions" it is obviously first necessary to get the project up and running.

Then make sure you go back and add appropriate data limits / error checking.

With lots of data being processed, and lots of trig functions, it is easy to come up with divide by zero type calculations, etc.

The point being, both to think about the consequences of data errors and how you will handle them, and directly to the question asked above, adding error checking will further lengthen your processing times.

 

Second thought was that although mean processing times are important, sometimes the maximum, upper limit, worst case processing times are equally important.

 

JC 

 

Edit: Typo

Last Edited: Wed. May 3, 2017 - 06:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

iw2nzm wrote:
Of course I need to compile in debug mode in order to catch the breakpoints placed at the begin and at the end of the function.
???

What do you mean by that?  Are you intending to e.g. use GCC and -O0?  That won't tell you much about how long things take in the real world.

 

Anyway, why not just put a breakpoint at the function call, clear the stopwatch/cycle counter, and Step Over.  Yes, there will be the parameter passing, function call/return, stack setup and teardown, and similar.  But that is all part of the job anyway.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

Not what you asked, but two additional thoughts came to mind which I'll take the liberty of mentioning.

With "lots of Trig functions" it is obviously first necessary to get the project up and running.

[...]

 

You're welcome!

I agree with you but the actual code is well tested and we use it in several projects. Porting it to xmega, we're wondering about the execution time due to the 8x8 hardware multiplier and the 32 MHz clock.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

What do you mean by that?  Are you intending to e.g. use GCC and -O0?  That won't tell you much about how long things take in the real world.

Anyway, why not just put a breakpoint at the function call, clear the stopwatch/cycle counter, and Step Over.  Yes, there will be the parameter passing, function call/return, stack setup and teardown, and similar.  But that is all part of the job anyway.

 

I haven't a deep knowledge of what happens behind a debug or release compilation, at least for GCC and AVR. In a desktop environments compiling in debug mode leads to a slower execution and bigger footprint due to the overhead needed by the debugger to work. From you answer (and from clawson's one) it seems there is no such a difference here.

For example, taking a project of mine:

 

Release mode (-Os)

    Program memory usage: 27498 bytes

    Data memory usage: 2585 bytes

 

Debug mode (-O1)

    Program memory usage: 26770 bytes

    Data memory usage: 2577 bytes

 

The differences are very small and they are due to the different optimization flags (although the -Os produces a bigger executable)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The simulator should work just fine, as well as setting breakpoints, in either optimization level.

 

Indeed, due to optimization artifacts, it is sometimes frustrating to find the right spot for a breakpoint to "take".  But I'd guess that even if your extensive function is only called once that it won't be inlined.  Even if it is, you might well be able to breakpoint at the function invocation.

 

Then there is the "real" way ;) by switching to the mixed assembly/source view and finding the desired spot.
 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also note that not everything in a build needs to be built "with/for debugging". You could compile your trig functions with full optimization and no debug info at all, but your "main" with debug info and a fitting optimization level. This will allow you to time the functions as they will run in production, while still being able to step and break in main with reasonable ease.

 

How to do builds like that depends on what environment you are using for building (Studio, makefile and command prompt, ...).

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]