Darren's Occasional Nugget 08/15/2007

[David L.]

_orko_

Good news - the In Place Element Structure does have the option to 'Mark As Modifier'. Choose which type of element you want to use with the In Place Element Structure, and then right click on the element to get the 'Mark as Modifier' option.

Message Edited by David L. on 08-16-2007 05:06 PM

[tst]

---

@jarrod S. wrote:
My point tst was when you needed to have global initialization from the outermost loop,

---

Good point. I didn't notice that initialize terminal was out there.

[_orko_]

---

@David L. wrote:
Good news - the In Place Element Structure does have the option to 'Mark As Modifier'. Choose which type of element you want to use with the In Place Element Structure, and then right click on the element to get the 'Mark as Modifier' option.

---

Hmm.  I'm not sure I understand the "mark as modifier" option fully then.  Putting two In Place Element (IPE) structures in the same block diagram with the same cluster as inputs, then marking both as modifiers, then waiting in one...it doesn't appear that they wait on the other to release the structure for modification?

See attached.  I'm probably just not grasping this concept fully yet.

[Angela M]

Hello _orko_,
As you noted, the "Mark as Modifier" option is not for synchronization purposes.  If you need to avoid race conditions you could use semphores or data flow to control access to protected data.

The "Mark as Modifier" option is a clue to the compiler that in some cases you will be modifying the data type, even if your base case does not modify the data. In your example, you would not need to mark as modifier, because it is already clear to the compiler that you are modifying the data in both structures.

As an example, add a third structure that does not modify the data.  Go to Tools>>Profile>>Show Buffer Allocations.  This option will show a small square at each terminal where a buffer is allocated.  You will notice that a buffer is allocated for all three In Place Element structures if the third structure is marked as a modifier.  If you do not mark the third structure as a modifier, no buffer will be allocated.  The top two structures will allocate a buffer whether they are marked as modifiers or not since you are clearly modifying the data.

This is a very simple use of the structure, and typically, if you're just modifying one small element of a small datatype this structure is really not necessary.

Hope this helps to clear up some of the confusion.

Regards,

Angela M
National Instruments

Message Edited by Angela M on 08-21-2007 03:01 PM

Message Edited by Angela M on 08-21-2007 03:01 PM

[devchander]

"Feedback loop, reloaded"

[Gabi1]

Wouwaw!

Finally a stop in the for loop!! just for that it is worth switching to 8.5 🙂

and i love the feedback node on LV2 functional as well (right now i use LV2 quite intensively, and the overhead due to the loop is quite big).

upgrade on the way! (i just need to spend 8 zillions hours convincing IT department to call the computer center of the faculty to call NI to get the product...you see how it goes at uni... 🙂 )

[bienieck]

Can someone prove me that "Feedback Node executes slightly more efficiently than it's Functional Global counterpart"? I found information that it is completely different:

http://forums.ni.com/t5/LabVIEW/Execution-speed-feedback-node-vs-shift-register/td-p/295536

http://labviewcvi.wordpress.com/2010/04/26/difference-between-shift-registersn-and-feedback-nodesfn/

I created some FGV's - one with Feedback Node and second with Shift Register. I tried to benchmark it to compare executions speed but every time I got duration equal 0 

So which FGV is better?

[Darren]

Here is a benchmark VI I use to compare shift registers and feedback node performance. I've noticed that the performance benefits have varied between LabVIEW releases since I first started advocating this programming pattern in LabVIEW 8.5. In LabVIEW 2013, it appears that feedback nodes are still a bit faster. We should keep in mind, though, that most of the time, a functional global variable is not being called in a tight loop like the ones in my benchmark code, and as such, variations in the comparable speeds between the two approaches probably have minimal effect on most applications. The main reason I like using feedback nodes in functional global variables is because I find them faster to write, and the diagrams are easier to read.

Also, in your VI, I noticed you initialized the feedback node. You'll want to leave that feedback node uninitialized in order for it to actually work as a functional global variable.

[bienieck]

Mean execution times for Your benchmark VI are:

For 100 samples

SR 113.31ms

FN 100.64ms

For 1000 samples

SR 116.44ms

FN 108.55ms

So at first glance You were right, Darren, FN is faster (a little bit but still).

I did my benchmark (with Your VI) but with enabled debugging so the results are probably not so precise. The problem is that, when debugging is disabled then Your VI works not so well (probably caused by some compiler optimization). Or maybe I'm wrong... 

How can I check execution time of my FGV's which I attached previously?

[Darren]

---

@bienieck wrote:

How can I check execution time of my FGV's which I attached previously?

---

Can you just replace the code within the tight loops of my benchmark VI with your subVIs? I agree that you should probably turn off debugging (on both the main VI, and your subVIs) when benchmarking. It might not be a bad idea to try out some other optimizations, like inlining, or changing execution priority, to see how it affects the results.