LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Micro-Nuggets !!! ~~~~ Post 'em if you got 'em


@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.

0 Kudos
Message 241 of 361
(2,410 Views)

(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)

 SSSBench.png

 

 

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!


"Should be" isn't "Is" -Jay
Message 242 of 361
(2,261 Views)

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


"Should be" isn't "Is" -Jay
Message 243 of 361
(2,239 Views)

@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.Smiley Surprised

GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 244 of 361
(2,226 Views)

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.)

 

 

Message 245 of 361
(2,211 Views)

You really need to disable debugging,


Wow,  That was a surprise! (to me)  Smiley Very Happy

 

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.Smiley Surprised  Unless you want to debug your code.

 

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


"Should be" isn't "Is" -Jay
Message 246 of 361
(2,194 Views)

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

Jim

LV 2020
0 Kudos
Message 247 of 361
(2,187 Views)

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?)

 

 

0 Kudos
Message 248 of 361
(2,162 Views)

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. 

0 Kudos
Message 249 of 361
(2,147 Views)

And now to completely blow my mind:

 

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

SSSBench.png

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 sequencesSmiley Surprised  That's right the sequences run faster.

 

All of which becomes moot If I try to fix that boolean!Smiley Surprised  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) 


"Should be" isn't "Is" -Jay
0 Kudos
Message 250 of 361
(2,141 Views)