Iteration timings of five FOR loops inside one Timed Loop..

[MogaRaghu]

Have a look at the attached code that simply runs five different but identical FOR loops inside a single Timed Loop.

It was quite interesting to note the iteration timings for each of the FOR loop :  1,1,2,3,0 millisec. The most curious thing is the timing of the last loop which mostly reads 0 ! Not only this if you delete the fifth loop, the foruth one will read 0 .

I am unable to figure out this behaviour ? Also if LV processes different loops parallely why should there be a progressive increase in timing of successive loops ??

Thanks for any help.

[altenbach · Accepted solution]

First of all, 0..2 ms is not statistically significant, you should increase the iteration count by another factor of 10, at least.

A fast FOR loop without a wait statement will grab the CPU for significantly more than one iteration, so whatever loop is first in line will push the other loops back and run until LabVIEW decides to switch to another loop. How many CPU cores do you have?

You can force a release after each iteration by placing a 0ms wait inside each FOR loop. While all times will be significantly longer because of the increased switching overhead, all loops will now take about the same time.

You might also want to read this for related information.

I am sure somebody else can provide more details in the right lingo. I don't know the exact terms for all this. 😉

[MogaRaghu]

That was a some learning !

I agree there must be some jargon like pre-emptive multitasking or whatever.

And your suggestion to introduce a 0ms wait state worked like magic - though I still dont comprehend how a 0-wait can matter !  Possibly its just a decoy - LV notices that there is a Wait primitive and goes to execute it , only to find its already zero. All the 5 loops were holding rock steady at 5ms and so was the iteration timing. Real hard core mutlitasking  

I was actually wonerding if my  Intel i5 CPU was being fried in the process - but no it was just running OK  consuming  about 16 to 25% resources.

Thanks.

[Yamaeda]

As i've understood it, the 0-ms wait forces a thread release, causing the system to look at which loop is next in line to run (in this case one of the other loops). Without the wait only the preemptive multitasking forces thread switch every X ms.

/Y

[altenbach]

Another problem are all the big array indicators what will get updated at one point or another. The updates are not synchronous so the arrays of the completed loops could randomly get updated while a later loops is executing, possibly slowing it down.