Micro-Nuggets !!! Stop beating up on the Stacked Sequence

[Hooovahh]

---

@crossrulz wrote:

Just for fun, I just tried to use Select a Control from my palette and select a VI.  It doesn't work.  It apparently only works for items in the palette.

---

Sound like a feature that should it's own Idea Exchange item.  And it seems like all the code to do this is already written just not exposed in the same way.

EDIT:  Also I noticed that if you make a package in VIPM and go to place an item on the Functions Palette it says "Insert a VI..." but on the controls palette it says "Insert a Control or VI..."  and if you add a VI to the controls palette it is selected to be merged.  Seems like those smart fellas over at JKI knew this little feature and built it into VIPM.

[JÞB]

(Also seen in the IE but brought up here for posterity)

The subject comes up now and then to REMOVE the Stacked Sequence Structure since the number of times its abused rather than used properly apparently approaches unity.

In fact it is a very easy structure to mis-use!  but there really is no direct "Replacement" for the SSS.

I took the time to put a test bench together (Source LabVIEW 2013 (13.0f2 x32) on a dual core Win 7 x64 OS.

The test code is very basic  Out = In * 3 + 6 constructed in somewhat R-G fashion.  feel free to use whatever sequential calculations you want- the code is there to benchmark the SSS not demonstrate why this calculation could not be done faster without a SSS.  (I'd better underline that  and repeat it: The code is for demoing SSS Performance not to provide an example of where a SSS is best practice)

 

For those that want to play, that's a snipette created with the CCT.  The Boolean "Fail" indicates the test cases do not yield equivalent data.  If you light that baby up you did something wrong!

As suspected, none of the test cases have performance that matches the SSS with Sequence Locals.  A Small surprise: The 1 additional unneeded tunnel the direct SSS-FSS replacement adds (presumably, to maintain the paradigm against possibly executing code parallel to a single frame of a SSS) does have a measurable performance impact of @%2 on my system.  I had expected any performance impact would be in the dirt.

So, lets stop beating up on this hard working node that gets the job done like nothing else!

[JÞB]

Just in case the CCT failed me here is the bench attached

[crossrulz]

---

@JÞB wrote:

Just in case the CCT failed me here is the bench attached

---

Good thing you did that.  You failed to tell the CCT to save the image as a snippet.

[altenbach]

I don't understand the minimum tunnel code. The number of tunnels is exactly the same as the FSS (8).

A good comparison is also the FSS case with the sequence structure removed. Now we are at 70% in the performance, and faster than the SSS.

You really need to disable debugging, because the FSS seems to have a larger debugging overhead.

Now the FSS is identical to the SSS (and identical to the case where the FSS is removed).

(You should really use the advanced histogram and use the same range and # of bins for all graphs, It is difficult to see the differences otherwise.)

 

[JÞB]

You really need to disable debugging,

---

Wow,  That was a surprise! (to me) 

For those keeping score at home:  Debugging disabled Unframed code, FSS and SSS are esentially equivallent in performance and @9x faster than a state machine.

Which leaves me with the small change in my opinion that the only meaningful use for a SSS is to associate comments with the code section in a particular frame and not merely one object.  Unless you want to debug your code.

It would be interesting to see which versions of the compiler introduce what, if any, improvements.

[lmtis]

That's a great idea.  I never thought to use a SSS to place comments "under" the code being commented.  Thanks Jeff!

[altenbach]

---

Jeff·Þ·Bohrer wrote:

For those keeping score at home:  Debugging disabled Unframed code, FSS and SSS are esentially equivallent in performance and @9x faster than a state machine.

---

A case structure with more than two cases always introduces an extra penalty, then you also have the check for the termination condition.

It is actually about 10x slower. In the image above, I already sped up your code a little bit by using a FOR loop (no check for termination). 😉

(It is curious looking at the buffer allocations. In the FSS, the sequence locals don't show any buffer allocations. Why not?? Shouldn't they?)

[GuenterMueller]

---

altenbach wrote:

(It is curious looking at the buffer allocations. In the FSS, the sequence locals don't show any buffer allocations. Why not?? Shouldn't they?)

---

They shouldn't.  The wire just stops at the sequence local. The data is still on the wire and can be read without any allocation in another frame. 

[JÞB]

And now to completely blow my mind:

So that there compiler is getting smarter by the moment.  Gotta watch out for those unexpected optomizations!

So lets stuff a "Riffle.vi" in there to drive the test code.  (ignore that "Fail?" boolean-  More on that later.....)

Whammo! SSS and FSS are now about 6x the speed of the State Machine but the UNFRAMED code seems to take a %40 performance hit compared to the sequences  That's right the sequences run faster.

All of which becomes moot If I try to fix that boolean!  Go ahead and insert a sort array in the last frame of the outer FSS  prepare to be amazed.

(For the love of God, I thought I was begining to understand LabVIEW!):smileysurprised:

All of which goes to show you that this test bench is merely picking and chosing compiler optomizations (or so I expect)