cluster array performance penalty

[Ben]

HI Shane,

I changed it even more to only allocate buffers before testing and then work from SR's.

You mention of LV 8.2 remended me to try that as well.

I think we have a bug   in LV 8.2 (LV 8.2.1 Beta to be technically correct).

IN LV 7.1 all of the versions opperate in-place and it is a toss-up which verson is better. This is consistent with the KB article you quoted earlier.

Now in LV 8.2 method #2 (Cluster wired thru one bundle terminal wired) wants to create new buffers!

This screen shot illustrates.

Method #2 and #3 are identical with the exception of an un-wired input to the bundle function. In previous of versions of LV they are wire equivalent code.

Can I get some consensus on this being a bug ?

If this is not a bug, please help me understand the diffrences.

The LV 7.1 and LV 8.2 versions are attached.

Ben

Message Edited by Ben on 02-25-2007 10:18 AM

[Ben]

Adding to the above...

With the exception of the bug, the in-placness algorithm is rather impresive, is it not?

Ben

[shoneill]

'tis indeed Ben.

I see you've been quite busy with this trinket over the weekend.  I needed a bit of time today before I could catch up.

So, am I right in summarizing:

1) Working on clustered arrays must not neccessarily be slower than working on "naked" arrays.  The scope of this statement is the testing we've performed, and was limited up to now on uncomplicated clusters.
2) Working on arrays within a cluster is independent on the size of other data structures in the cluster (again only tested for small, uncomplicated clusters).
3) Some forms of clutered array manipulation seem to be buggy in the newest LV version. (Namely the "Cluster 2 no Passthrough" you have recently wisely removed from the test program).
4) The in-place algorithm rocks, when it's used.
5) I need to learn how to use the buffer allocation imformation in LV 8.20 😉

OK, 4 and 5 are perhaps less critical....

I think I need to whip up an example with significantly more complex clusters, just in case.

Shane.

[altenbach]

---

@shoneill wrote:
3) Some forms of clutered array manipulation seem to be buggy ...

---

I'm sure you meant to say cluttered. 😄

[Ben]

The bug invloving the Bundle function in LV 8.2 was reported to NI Support unde SR 934633.

I will update this thread if I learn more.

Ben

[Ben]

A CAR has been filed for this issue;

"

the title is

"Cluster Array Performance Penalty," and the ID is 46QG7LJG.

"

Ben

[Travis_M.]

Hello,

The screenshots on the font panel of your 8.2 attachment - were those taken from 8.2? 

To address these issues as I see them:
A) No buffer allocation should occur at a tunnel (not auto indexed) going into any structure or coming out of any loop (I could see a case for an allocation for a tunnel coming out of a case structure since the compiler doesn't know which case is going to be executed until the program runs).  I think this is what you are pointing out in your picture labeled as "A" and "B".  I don't see these allocations occurring with LabVIEW 8.20

B) Why does the "wiring through" of the array in method 3 alter the inplaceness of the operation?  I do think I can answer this question, and it is not a bug (though it could probably be improved.  I believe that the algorithm to detect if an operation can occur in place looks for a 'well known pattern'.  A well known pattern is an unbundle, operation, rebundle with the same wire (such as done in "method 3"), I believe that if you don't connect all the terminals the pattern is not recognized as something that can occur in place and therefore a buffer allocation is performed (as in method 2).

Please let me know if you have any comments. Have a great afternoon-

[shoneill]

Travis,

Thanks for your input on this one.  It's nice to get an idea as to where these issues are coming from.

Regarding the optimisations of the inplaceness detection, can this be taken seriously please?  Should I post a product suggection form (or whatever it's called).  It's pretty hard for a user to know when a cluster's going to be re-used and when not.  Since the variable length cluster elements are strored in separate memory areas, can't this simply be done for each variable length element individually.  This would pretty much simplify the "pattern" detection, no?  My guess would be that the algorithms for detecting inplaceness should ideally be quite similar (if not the same) to those used for the variable-length elements on their own (not clustered).  With NI advocating the use of state machines, wiring lots of parameters through multiple states is pretty much becoming a requirement.  If we can rest assured that the in-placeness is working properly, then it makes performance predictions a bit easier.  This was actually the origin of this thread: a discussion on the requirement for a new feature to make handling state machine data easier.  Perconally, I think clusters are the best, but they need some more tweaking I think.

One of the most worrying aspects is the difference in performance between LV versions.  I no longer have the values fresh in memory, but I recall LV 6.1 having less problems with this inplaceness than LV 8.20.

My 2c.

Shane.

[Ben]

Hi Travis,

Please look again.

LV 7.1 handles the bundle efficiently.

LV 8.2 (8.2.1 Beta) does not.

Applications that use that construct and run fine in LV 7.1 will suffer badly if used in LV 8.2.

So please run the benchmarks yourself in both version and please post back.

Thank you,

Ben

[Travis_M.]

Hello folks,

First, I assure you that we do take the issues seriously and we will look into it.  I am submitting the following 2 files with the bug report which really highlight the issue at hand.  I tried them on both 7.1 and 8.2 (I don't know about 8.2.1, I don't think we made any announcements about anything called 8.2.1), and like we saw before 8.2 is much slower (and, yes, I do agree that this is a problem).

Does anyone have any other comments related to this issue that I can add to the bug report?

Thanks for everyone's contributions, have a good afternoon-