Memory allocation

[yao]

hi, all

this quesion confuse me for a long time. I already read some like "buffer" or "allocation" topics.

I download a example from NI website before, I would like to know why place a indicator is some kind of memory allocation.

using initialize array is not allocating first? why this indicator cause large different in the example, please explain to me.

if LAVA havd had the familiar discussion, reference to me, thanks.

[Ton Plomp]

You made a programming error, you should read the start time of the second loop at the start of the second loop not at the start of the VI.You could use a sequence, with in each sequence frame one of the two methods with their own timing.

Ton

[crelf]

It's all about when the buffer is allocated. In the first example, having an indicator forces a buffer for the data to be allocated (that's the little balck dot on the indicator terminal), and then LabVIEW uses implaceness (ie: just replaces the data instead of creating a new buffer) where it can. In the second example, the little balck dot is on the sub VI in the loop, meaning that every time the loop executes, a buffer is allocated (which is slow - especially when you're doing it 7500 times ).

[yao]

But both example have little black dot on the initialize array, the meanwhile buffer do not allocated? why should I place another component to force allocate buffer, and allocate once. Is initialize array not the same with allocate memory? what the initialize array exact do in labview. :headbang:

[crelf]

But both example have little black dot on the initialize array, the meanwhile buffer do not allocated?

The subVI in the loop is using the buffer allocated by the indicator. It can't use the buffer allocated by the initialize array, as that's required at the input tunnel of the loop.

[yao]

The subVI in the loop is using the buffer allocated by the indicator. It can't use the buffer allocated by the initialize array, as that's required at the input tunnel of the loop.

Sorry about my fool, but it's very difficult to understand.

why tunnel of the loop use the buffer allocated by the initialize array, and subVI use the buffer allocated by the indicator, how labview allot to each other. why loop tunnel doesn't use the array subset buffer, this kind buffer allocate is a common sense to you all?

[Grampa_of_Oliva_n_Eden]

Sorry about my fool, but it's very difficult to understand.

why tunnel of the loop use the buffer allocated by the initialize array, and subVI use the buffer allocated by the indicator, how labview allot to each other. why loop tunnel doesn't use the array subset buffer, this kind buffer allocate is a common sense to you all?

I agree with most of what are saying yao.

Please see attached image for how I "interpret the entrails"

A) a buffer is allocated of the size you specify and is filled in with 0's lets call it Buffer_A.

B) A branched wire has to be handled delicately since all of the sinks want to see an un-mollested "copy" of the buffer produced by the source (in the case the the Buffer A).

C) The array size shown by C has to match that of Buffer_A. We can not predict if it runs before or after the Array Subset runs.

D) Since the output of the Array Subest function can change the size of the buffer it is passed, and since its source wire branches, the Array subset function will place a copy of the dat from Buffer_A in a new buffer Buffer_D.

E) a buffer is allocated of the size you specify and is filled in with 0's Buffer_E.

F) See D above. The Array subset function will under the proper conditions, not create a new buffer but will re-use the buffer it has been passed. In this case Buffer_E just has to have some pointer updated to reflect the subset. It simply passes the pointers along. But in-so doing, it appears to mask the buffer it recieved from down-wire enties.

G) I am not sure why Buffer_E can't be re-used by the sub-VI call. Maybe its "to far away" for the buffer re-use logic to "see it" so a copy is passed via a new buffer. I believe this to be a complication of using the "Array Subset.

H) Since the Buffer_D is the input to the sub-VI call can simply pass the refence Buffer_D since it "knows' about it.

So I suspect there is something in the fine print of the array subset functin that is coming into play.

All of the above is just my speculation about what is really happening. If I have mis-represented any of the above please correct me. :thumbup:

Ben

Download File:post-29-1169924586.zip

[Rolf Kalbermatter]

I agree with most of what are saying yao.

Please see attached image for how I "interpret the entrails"

A) a buffer is allocated of the size you specify and is filled in with 0's lets call it Buffer_A.

B) A branched wire has to be handled delicately since all of the sinks want to see an un-mollested "copy" of the buffer produced by the source (in the case the the Buffer A).

C) The array size shown by C has to match that of Buffer_A. We can not predict if it runs before or after the Array Subset runs.

D) Since the output of the Array Subest function can change the size of the buffer it is passed, and since its source wire branches, the Array subset function will place a copy of the dat from Buffer_A in a new buffer Buffer_D.

E) a buffer is allocated of the size you specify and is filled in with 0's Buffer_E.

F) See D above. The Array subset function will under the proper conditions, not create a new buffer but will re-use the buffer it has been passed. In this case Buffer_E just has to have some pointer updated to reflect the subset. It simply passes the pointers along. But in-so doing, it appears to mask the buffer it recieved from down-wire enties.

G) I am not sure why Buffer_E can't be re-used by the sub-VI call. Maybe its "to far away" for the buffer re-use logic to "see it" so a copy is passed via a new buffer. I believe this to be a complication of using the "Array Subset.

H) Since the Buffer_D is the input to the sub-VI call can simply pass the refence Buffer_D since it "knows' about it.

So I suspect there is something in the fine print of the array subset functin that is coming into play.

All of the above is just my speculation about what is really happening. If I have mis-represented any of the above please correct me. :thumbup:

Well as far as C) is concerned: LabVIEW is smarter than that since I think at least 3.0. Since Array Size is a function that does not (re)use the array ever, LabVIEW always attempts to schedule this call before any other functions that use the branched array, in order to avoid unnecessary buffer copies.

And here appearently happens the difference. Because Array Subset usually does modify the buffer passed in it does create a copy in D since the source wire has a branch. Since D is now a new buffer it can be passed directly to the subVI.

In the second case Array Subset does reause the buffer but flag it as not clean, since it usually would have resized the array somehow, but in this case without reallocating the actual memory area. Since the buffer is not clean, LabVIEW create now a clean copy to pass it to the subVI.

All this shows that analyzing for optimization is a difficult thing to do. In this case the first solution will be more performant since the additional buffer is only allocated once outside of the loop. Array Subset being a function that modifies the buffer is of course a nasty thing to analyze and as you can see optimizing the Array Subset here can actually have negative effects since LabVIEW has to consider many possible corner cases eventhough in this case the extra copy would not strictly be necessary.

I'm also sure the entire story would look again different if you would add a shift register to the loop and pass the array into this, feeding it inside the loop from the left to the right shift register terminal. While this code may look useless it almost always helps LabVIEW to optimize the code in the best possible way, as the LabVIEW optimizer has some very smart shift register optimization rules.

Rolf Kalbermatter

[Grampa_of_Oliva_n_Eden]

Well as far as C) is concerned: LabVIEW is smarter than that since I think at least 3.0. Since Array Size is a function that does not (re)use the array ever, LabVIEW always attempts to schedule this call before any other functions that use the branched array, in order to avoid unnecessary buffer copies.

Good point, thank you. That was one of the reasons I selected this node to force the wire branch. i was somewhat suprised to still see the buffer copy.

All this shows that analyzing for optimization is a difficult thing to do.

I'd say! At first glance I'd say the array size was a NO-OP and toss it in about two seconds. I wonder if the VIA would say anything about the construct.

I'm also sure the entire story would look again different if you would add a shift register to the loop and pass the array into this, feeding it inside the loop from the left to the right shift register terminal. While this code may look useless it almost always helps LabVIEW to optimize the code in the best possible way, as the LabVIEW optimizer has some very smart shift register optimization rules.

This part tricked me too! It appears tht the buffer must be in the wire feeding the lopp (SR or not) for it to be re-used.

Ben

[yao]

This part tricked me too! It appears tht the buffer must be in the wire feeding the lopp (SR or not) for it to be re-used.

Ben

I appreciate your reply, and learn much knowledge I have never thought about. thanks you all.

I think I understand more about memory allocation now.

About add shift register, I change it to feedback node, and got another result. In the second case, the buffer allocate in feedback node, not in subvi, and the excute time reduce from about 1400ms to 360ms in my pc, it's amazing. There is much trick about LabVIEW I should learn.

[Grampa_of_Oliva_n_Eden]

QUOTE(yao @ Jan 28 2007, 09:51 PM)

I appreciate your reply, and learn much knowledge I have never thought about. thanks you all.

I think I understand more about memory allocation now.

About add shift register, I change it to feedback node, and got another result. In the second case, the buffer allocate in feedback node, not in subvi, and the excute time reduce from about 1400ms to 360ms in my pc, it's amazing. There is much trick about LabVIEW I should learn.

http://forums.lavag.org/index.php?act=attach&type=post&id=4797''>http://forums.lavag.org/index.php?act=attach&type=post&id=4797'>http://forums.lavag.org/index.php?act=attach&type=post&id=4797

To who ever may have this issue in the future;

I have reason to believe that an upgrade to 8.2.1 may be worth the time.

Can't give details!

Ben