LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Action Engine Benchmark

I was reading one of Darren's new blogs regarding using a feedback node in your action engine with LV 8.6 and he said that the feedback node approach can be 5-10% faster due to the lack of loop overhead.  I figured I would try and benchmark this but realized I wasn't exactly certain how to about doing it.  Attached is my attempt, using an actione engine to first write a 1D array with 10000 indices and then read the array back.  I did not know what to chose to store in my action engine and I figured that deciding what datatype to store would change the outcome of my benchmark.  I am curios to see what ideas people have for measuring this.  The attached VI's are in 8.6 as they make use of a feature that does not exist prior.
Download All
0 Kudos
Message 1 of 7
(2,588 Views)

I ran your benchmarks on LV 8.6.1.f1, AMD phenom X4 on Vista Home Premium.

 

I got .051 for USR and .062 for feedback node.

 

The only comment I would have in your benchmarking setup is to move the array initialization out of the initial flat sequence frame where you get the start time so that the time to initialize the array (although it should be constant folded) doesn't affect the timer.  My numbers above were based on moving that array out of the For loop entirely.

Message Edited by Ravens Fan on 03-24-2009 08:26 PM
0 Kudos
Message 2 of 7
(2,575 Views)

Hey guys,

 

Sorry I didn't see this post back in March...I guess it was one of y'all who asked about it on my blog.   Anyway, I made some changes to the code to make it more closely resemble my original benchmarks.  Among the changes I made:

 

1.  Changed the data type to a scalar Boolean to minimize the impact of data size on overall times.

2.  Replaced the boolean value being written to the USR/Feedback Node from a constant-folded entity (the Array Size output was constant-folded since both of its inputs were constants) to a control on the front panel, to eliminate any sort of unpredictable optimizations having to do with constant folding.

3.  Wired the output of the Read VIs to the border of the For Loop.  There are some optimizations that LabVIEW can sometimes perform if you don't wire the outputs of subVIs...I wanted to eliminate any unpredictability here as well.  Now that I think about it, when I did my original benchmarks, I did not have the USR/Feedback Nodes wrapped in subVIs...they were called directly on the diagram of the benchmarking VI.  So this could also explain some differences in our results.

 

After making these changes, I found that the Feedback Node was anywhere between 3% and 10% faster than the USR, depending on how many iterations I ran the loop.  I have attached my modified copy of your benchmarking test below for your reference.  This was tested on LabVIEW 8.6.0, Intel Quad Core on Vista Business 64-bit.

 

Another thing I noticed is that, if you change the benchmarking VI to only benchmark writing, the writing can be slower with the Feedback Node.  It seems to be consistently faster when benchmarking only reading, though.  Looking back, I think my original benchmarks focused on reading.

DNatt, NI
Message 3 of 7
(2,466 Views)
You are correct that data type matters.  In some tests I did two years ago, I saw a 6% improvement for a simple scalar, but a 70% improvement for a 1MByte array.  Unfortunately, I did not post the exact code, but it can be recreated easily enough by replacing the USRs in the posted code with feedback nodes.
This account is no longer active. Contact ShadesOfGray for current posts and information.
0 Kudos
Message 4 of 7
(2,443 Views)

>I found that the Feedback Node was anywhere between 3% and 10% faster than the USR, depending on how many iterations I ran the loop 

 

Darren,

 

I seem to consistently get a different result using basically your exact VI with the following small changes. (1) add a chart for the result (2) place a while loop with 0ms wait around it to force an update).

  1. "As is", there is virtually no difference between the two.
  2. If I change both action engines to subroutine priority, the feedback is 5-10% slower than the USR. (!)

(your "% faster" is a negative number!, see image).

 

LabVIEW 8.6.1, Old Athlon XP desktop.

 

Message Edited by altenbach on 06-17-2009 11:11 AM

LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
Message 5 of 7
(2,374 Views)

altenbach wrote:

 

I seem to consistently get a different result using basically your exact VI with the following small changes. (1) add a chart for the result (2) place a while loop with 0ms wait around it to force an update).

  1. "As is", there is virtually no difference between the two.
  2. If I change both action engines to subroutine priority, the feedback is 5-10% slower than the USR. (!)

I don't know if we can trust any results once the chart is added, due to its effects on memory allocations.  However, I definitely noticed some weirdness once I played with the priority settings.  I also noticed that the relative speed of the feedback node compared to the shift register declined in LabVIEW 2009.  So I have filed two CARs based on your findings:

 

CAR# 175377 - Feedback Node speed relative to USR decreases when inside a subroutine priority subVI

CAR# 175379 - Feedback Node speed relative to USR decreases in LabVIEW 2009

 

Thanks for bringing these issues to my attention!

DNatt, NI
0 Kudos
Message 6 of 7
(2,336 Views)

Thanks!

 

Sorry, I get the same result without chart (8.6.1). The chart just helps elevate the difference above the noise level because we can see historical data. It is also interesting that the feedback node has significantly wider deviations between iterations. This is difficult to explain. 😉


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 7 of 7
(2,333 Views)