LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to calculate the execution time of a Loop?

Solved!
Go to solution

I don't agree with this. You are calculating the execution time within a loop, so in my opinion, it would take additional CPU cycles to get timer value, subtract it and output to front panel. This might prove useful to see how your code performs when running. But if you are trying to test the performance of a function, i think it would be better to use stacked sequence with timers before and after the tested code.

 

0 Kudos
Message 11 of 14
(2,949 Views)

thunderbolt87,

 

That is a flat sequence not a stacked sequence. The stacked sequence should generally be avoided because it hides code and needs sequence locals (with their accompanying right to left wiring).

 

It is quite likely that the code you pictured will not produce the results you are expecting. Since none of the dot product VIs has any outputs connected the compiler might suppress much of the  code. Similarly since they all have the same inputs the compiler might only do the calculation once, if at all.

 

You should also disable debugging to get accurate timing.

 

Because the resolution of the Tick counter is 1 ms you do not get very good results unless the time for the code in the middle frame is lots of milliseconds. It is better to put the for loop inside the middle frame and repeat the code under test.

 

I get 3.648 ms for one Dot Product repeated 10000 times but either 3 or 4 ms when "repeated" only once.

 

Lynn

Message 12 of 14
(2,935 Views)

In addition to what Lynn already mentioned...


@thunderbolt87 wrote:

I don't agree with this.


What is "this"? please quote the relevant post.


@thunderbolt87 wrote:

You are calculating the execution time within a loop, so in my opinion, it would take additional CPU cycles to get timer value, subtract it and output to front panel. This might prove useful to see how your code performs when running.


We don't care about opinions, just facts! 😄 You can easily benchmark an empty loop or even a series of tick count operations to estimate the timer and loop overhead and you will notice that it is orders of magnitude less and thus irrelevant. There is significantly more jitter just due to the nature of a multipurpose OS and the fact that many other processes are running. Did you even test your code?

If you want to contribute something useful, code up several versions, benchmark them against each other, and use the results to show that your code is better, more reliable, more realistic, etc... I doubt you can prove your case!

 


@thunderbolt87 wrote:

But if you are trying to test the performance of a function, i think it would be better to use stacked sequence with timers before and after the tested code.


Benchmarking is an art, and what you are doing here is useless. First, as Lynn already said, the LabVIEW compiler (click on the link!) can play tricks on you here.

Dead code elimination: code with no output might get eliminated.

Common subexpression elimination: duplicate code might get eliminated.

Constant folding: Since the input to the loop is constant and always the same, the compiler might decide to calculate it only once and re-use the result in all following iterations.

Parallelization: Even if you work around the above problems, the compiler might schedule several matrix operations in parallel to be run on multiple CPU cores.


@thunderbolt87 wrote:

But if you are trying to test the performance of a function, i think it would be better to use stacked sequence with timers before and after the tested code.


This sentence makes no sense. "Better" than what, exactly? Why "Stacked"?

Also, since you want the actual code execution time, and all jitter producing side effects of the OS tend to lenghten the measured time, taking the "mean" is misguided. You get a better approximation by taking the "array min" of the times after executing the code an infinite number of times.

 

Try again! 😄

0 Kudos
Message 13 of 14
(2,914 Views)

@altenbach wrote:

Try again! 😄


Given that it appears to have taken over three years for thunder bolt to reply to your last post, I wouldn't expect a second attempt any time soon Smiley Sad

0 Kudos
Message 14 of 14
(2,901 Views)