LabVIEW 2015 Buffer Allocation Bug?

[mcduff]

Look at this image. The task Manager on Windows shows memory allocations.(The IPE structure should operate in-place for this simple case.) I think this is a bug and should be a CAR. I am going to forward it to someone, hopefully it will get looked into.

Cheers,

mcduff

[Intaris]

---

@mcduff wrote:

This occurs in LabVIEW 2015 SP1 32bit running on 64bit Win 7; it does not seem to occur in LabVIEW 2014.

Look at the screen shot, the subVI is a simple in and out with no operations.

---

The IPE cannot guarantee that the sub-VI modifies the length of the array you are entering.  this is of importance because it's a Sub-array (It must remain aligned in memory with the part of the "DBL Array in" which is wired through.  An extension of that part of the array may not be possible while still maintaining a single memory space.  The Sub-VI retrieves a pointer to PART of an array, not the entire array.  This limits what can and cannot be done in-place.  The pointer entering the sub-VI and exiting the sub-VI must point to the exact same memory space.  If the sub-VI tries to do something else, the IPE will coerce the result so that it matches again, hence the data copy.

The version outside of the IPE however receives the FULL array and can reallocate and resize as it wishes as it will not step on anyone else's toes.  Essentially a memory location pointer goes in, and a memory location pointer comes out.  Where those pointers point to doesn't matter.  Compare the IPE with a case where you manually "Get Array subset" and feed the second part into the sub-VI and re-incorporate it afterwards (or just right-click the IPE and choose "Remove IPE").  It should show the same buffer allocation dot.

Also note that MANY buffer allocation dots in the IPE are "potential" allocations, not guarantees.  Even performing a "Index Array" ont he left-hand side of the IPE will AUTOMATICALLY create a buffer allocation node for the case where that Index data does not exist (Index 20 of a 10-element array).  If you have code to make sure the index is never outside the valid range of your array, that buffer allocation will never actually take place.  Understanding when they are real and when not and benchmarking is key to getting your code running as you want it.

PS, yeah, the display of buffer allocations is relatively buggy.  Try instead to understand WHEN allocations may occur and work from there.  I've had software showing absolutely NO buffer allocations running like treacle with "unbundle - modify - bundle" but running super fast when actually utilising the IPE to do the same thing.  Code complexity also plays a role here.  If code compelxity of a compile job gets too large (and here too LV has bugs, the complexity of inlined VIs IIRC do not properly contribute to the displayed complexity of the code containing them), LV stops doing all optimisations and if the in-placeness is one of those - bang - your performance just disappeared.

[mcduff]

I agree with just about everything you have said. Take a look at the attached picture and LabVIEW VI. In this case the compiler should know that there is no resizing, it is a simple operation. However, I see a buffer allocation that appears to be real. This example I cannot explain, except bug. This occurs in 2015, I do not think it occurs in 2014, I need to check though.

Cheers,

mcuff

EDIT: I am wrong. The extra buffer allocation appears in 2014 also. I have no idea why this is the case.

[AristosQueue (NI)]

I have an answer. You're not going to like it. Well, you might, since I come bearing a workaround, but the reason the workaround is needed is the frustrating bit.

The two buffer allocations on the Split node are legit. Those represent the allocation of "subarray handles" -- that is, LV allocated a tiny bit of information that is the pointer to a real array and a stride length. It is NOT an allocation that represents a copy of the full subarray.

But the allocation on the Subtract node and on the Replace node represent actual data copies.

Is this a bug? Well... not exactly. It's a place where the smartness of the compiler is still developing. Somewhere around LV 2011, we started developing this concept of subarrays, letting a wire represent a connection back to an original array. Prior to that, any operation that needed just a piece of an array was a copy. That allows you to do all sorts of operations on the subarray so long as you do not change the size of the array. If LV thinks you're changing the size of the array, it makes a copy.

The Subtract node obviously does not change the size of the array. But LabVIEW doesn't know that. Every individual function that operates on arrays has to be tagged with whether it resizes or not. That tagging is not complete and is, in fact, on hold pending some other compiler work. So most of the primitives that operate on arrays do not yet tell the compiler "It's ok, I don't resize."

So if you want to do the operation that you're trying to do in a way that LV knows doesn't resize the array, you have to do this:

I'm sorry to be the bearer of bad news. But at least there is a way to do what you're trying to do without memory copies. I hope that salves the wound.

[mcduff]

Thanks for the in-depth explanation. I have been using the solution you have suggested to avoid data copies, I just thought it should be unneeded. This is one thing about LabVIEW that frustrates me: Using primitives seems cleaner and faster than loop constructs, however loop constructs are usually as fast or faster and are sometimes more memory efficient.

Thanks again.

Have a good weekend.

Cheers,

mcduff

[User002]

---

@mcduff wrote:

Using primitives seems cleaner and faster than loop constructs, however loop constructs are usually as fast or faster and are sometimes more memory efficient.

---

Perhaps consider keep on using primitives since the LabVIEW/LLVM compiler technology continously improves?

Roger

[AristosQueue (NI)]

---

@User002 wrote:

Perhaps consider keep on using primitives since the LabVIEW/LLVM compiler technology continously improves?

---

That's generally my advice in *any* programming language -- write good code from a human standpoint, let the compiler get better at communicating with the machine. Only step out of that box when you have an application that definitely needs the performance improved -- not just theoretically, but actually. But then, that's really just a subset of my even more general rule: Write good code for functionality and then optimize after everything is working only the parts that need optimization. Trying to optimize early just leads to clunky code and -- worse -- code that the compiler can't optimize later.

[User002]

I think that there fundamentally does not exist any "good" code, except in the most trivial cases, only more or less poor choises of implementations. As ones own skill, experience, computer science and hardware in general improves over time, effort is better spent to make code easier to rework/refactor for new paradigms, than slapping more lipstick on the pig. Decent software is the output of a sound, dare I say it; a humble development process.

But I digress.

Otherwise I concur with everything you stated.

Roger

[AristosQueue (NI)]

It would appear that the misalignment between Roger and I is only one of optimism.

Where he says there is only "decent" code, I say there is only "good" code.

Where he says there is no "good" code, I say there is no "great" code.

Cheer up, Roger!

Here... enjoy some happy kittens! Then go write good code!

[User002]

Thanks for trying to cheer me up AQ. The positive optimist.

Though, life as a negative optimist isn't that bad either.

A objection though, showing a picture of several carnivore younglings to a herbivore.

A bit scary if you ask me. 

http://m.huffpost.com/us/entry/214390.html