XNode Execution Settings

[hooovahh]

Hello all, I've been doing some XNode development and I think it is awesome.  My first XNode is an attempt to wrap some functionality into a set and get variant attribute, with some adding stuff similar to write once read many.

 

In any case all is going great and I have the Write and Read XNodes working fine.  So I wanted to compare their performance to the native, or polymorphic equivalents.  For performance I have my normal VI version set to inline, with debugging, and automatic error handling off, and set to reentrant. 

 

Calling the this VI in a loop 1,000,000 times takes about 2ms.  I then ran the same code but as an XNode and it took 265ms.

 

So I figured this must be because the XNode VI isn't being inlined.  So I added code to the GenerateCode.vi and have it set to make the execution settings the same as the normal VI version and ran again.  Still about 200ms.  I tried the reverse, and made my normal VI not inlined and it now takes 200ms.

 

I put probes in my GenerateCode.vi and see that I am setting the execution correctly, but when I right click the XNode and choose Generate Code from the wizard menu, the VI generated doesn't have the settings I set.

 

Has anyone seen this type of thing before?  Is there some extra work involved in setting this execution settings, or is this a bug that there is no need to inform NI about?

 

EDIT: In doing some tests it seems the diagram provided in the GenerateCode.vi is a "XNodeGenCodeScratchPad 1" and is likely not the VI that the XNode runs, so changing the settings of this VI does not change the execution settings of the VI that is ran when the XNode runs.

[JackDunaway]

Calling the this VI in a loop 1,000,000 times takes about 2ms.

 

There's the red flag; that's a couple order magnitudes lower from gut instinct. I suspect one of two compiler optimizations due to the benchmark harness: 1) loop invariance that's applied on inlined but not detected for non-inlined VIs, or 2) dead code elimination, from not accessing the contents of the attribute

 

 

I tried the reverse, and made my normal VI not inlined and it now takes 200ms.

 

I hear this as excellent news, that your the XNode is just as performant as a "regular" VI!

 

 

To substantiate, here's a harness that shows 1,000,000 accesses in a loop that exhibits no potential loop invariance or dead code -- on my machine, it takes roughly ~900msec:

 

[hooovahh]

Okay Jack you were right.  I thought 2ms was too low.  In my test I was reading the same attribute over and over and the compiler must have some how optimized for this.

 

So I did a new test, where I had 1M tags, like your example, then read them all using a normal VI that is inlined, a normal VI that is non-reentrant, and my XNode.  For added interest I also had the This VI returned from the Xnode because I figured I would be able to read the execution inofrmation from the XNode VI.

 

With my test the Normal Inlined VI took 607ms. Probably lower than yours because I am just reading, not checking for validity like your was.  My non reentrant was 701ms.  The XNode option was 606ms.  But interestingly enough when I read the VI Name of my XNode VI reference returned it was the name of the calling VI.  So an XNode appears to do some sort of inlining, but I can have things like property nodes in my XNode which normally inlined VIs cannot.  Of course doing this screws with all the performance numbers I mentioned earlier so I removed that.

 

Attached for those interested is my read XNode, along with the VI to check performance.  This has a dependency on the LAVA Scripting Tools.  But I think that's it.

 

I made this Read XNode because I wanted it to have the combined ability that a polymorphic VI can have, where you right click and choose the type, or you could wire in the type.  So right click the XNode and you can choose from a large list of data types to read, or if you pick Automatic you can wire in the type to use.  I'd like to release this at some point but for now it is a learning exercise.

 

 

EDIT: Saved in 2012

XNode Performance Test.zip

[lordexod]

Inline:

[hooovahh]

Inline:

inline.png

What is that supposed to do?  I realize what it is doing but I'm not sure how it is helpful.  The XNode Template.vi isn't the VI being ran when an XNode runs, and it already is inlined.

 

Is this supposed to show a simplier way to perform the GenerateCode than the way I did it with using tags on the tunnels of a structure?  Because if so I like it.

 

EDIT:  Wait so I inline my template, but how do I wire up my controls/indicators?  The controls I can look at the labels of the constants, but how would I wire the indicators?

[Neil Pate]

I love trying to understand lordexod's posts, they are like doing a cryptic crossword 

[hooovahh]

I love trying to understand lordexod's posts, they are like doing a cryptic crossword 

I was going to be funny and post a random VI that had all kinds of XNode Scripting properties all linked together in a random way, but I just can't copy his level of intrigue, while still on the surface looking random.  

 

I mean what he posted is almost not relevant to what we were talking about, but then I realized it could have been very useful at the same time.

[shoneill]

I love trying to understand lordexod's posts, they are like doing a cryptic crossword 

 

Where each of the answers to the clues are required in a different (unspecified) language.

[hooovahh]

Where each of the answers to the clues are required in a different (unspecified) language.

Well despite the very vague answer of a single picture, I was able to implement some kind of code improvement using that information.

 

Attached is a new version that doesn't perform any better, but does do the GenerateCode in a different way that is more flexible, and removes the dependency on the LAVA Scripting package.

 

I also added code to change the icon image based on the data type wired, and have it so it can read the tag data from the type wired in.  As I said before this maybe release as a complete package at some point, but for now anyone interested in doing XNodes can use this as an example on how to do similar things with adaptive terminals, icons, and custom right click menues.

XNode Read Variant.zip

[lordexod]

LvVariant Get Attribute:

LvVGetAttr.vi

[Neil Pate]

LvVariant Get Attribute:

LvVGetAttr.vi

 

Interesting, but I am not sure how these are better than using the Get/Set Variant Attribute prims. Have you benchmarked these compared to the prims? I suspect the difference will be very little difference, but am curious anyway...

 

Edit: your VI does not actually do very much, did you perhaps forget to save default values on the variants or am I missing the point completely? I tried to add a variant attribute using the standard LV prim, and then read it back using the library call, but I could not get this to work ("an exception occurred in the external code").

[lordexod]

LvVGetAttr v2.vi

test.vi

[hooovahh]

I couldn't get your example to work, which is probably why the execution time is so much more than the primative.

 

Running your test.vi it takes about 2800ms to read only 10,000 attributes.  But when you look at your Array 2 you see that it didn't read anything and just is an empty string for each attribute.  I'm guessing if it ran properly and read the attribute then it would probably take less time to execute.  So this isn't a fair comparison because the output is not the same.

 

EDIT:  Tested in 2013 SP1.

 

DOUBLE EDIT:  So your DLL call has the full path to LabVIEW.EXE and the VIs were saved for 2012 and when opened in 2013 didn't run right.  After fixing this the data is read properly, but still takes orders of magnitude longer to execute than the primatives.

[hooovahh]

Another fun thing I just learned about XNodes.  You can't have a for loop with Iteration Parallelism.  I thought for reading multiple variant attributes it would be faster to read them in parallel.  It is indeed much faster.  On my 8 core machine it was about 4 times faster reading 1M attributes.

 

But when I put this code into the XNode my VI was broken.  There was no reason given for the VI to be broken, and if I looked at the GeneratedCode the VI was not broken.  But as soon as I removed the parallelism on the for loop, the VI calling the XNode was no longer broken.  This was in 2012 SP1.

[lordexod]

VI Self-Extracting Packer (Seve vi file to desktop):

Read Variant Repository__packed.vi

[hooovahh]

VI Self-Extracting Packer (Seve vi file to desktop):

Read Variant Repository__packed.vi

Again this is a very neat trick.  I appreciate you sharing it.  But it has little to do with the topic, or even a few topics that we have had tangents on.

[Jordan Kuehn]

Again this is a very neat trick.  I appreciate you sharing it.  But it has little to do with the topic, or even a few topics that we have had tangents on.

 

Are you surprised?

[ShaunR]

VI Self-Extracting Packer (Seve vi file to desktop):

Read Variant Repository__packed.vi

 

[hooovahh]

I was curious so I looked at lordexod's posts.  When making a new topic he has one complete sentence.  For replies to topics he has either no text, quoted text, or not a complete sentence.  Very much a man of few words.  Maybe he is really busy, or maybe he is just shy?  

[lordexod]

Why immediately just shy?

My english language is poor.

[hooovahh]

Not being fluent in English is not a problem. But if you are interested in being more involved on LAVA I would suggest you learn more. Your posts do have value but is sometimes hard to understand.