VI of the Day (10/15/2009) - Always Copy

[Darin.K]

I wish I had more to say about today's function, "Always Copy", but to be honest it has had me a little puzzled since I first saw it.  The help was not-so-helpful in this case.  The idea is simple enough, copy the input to a new memory location.  I have had plenty of block diagrams light up like Christmas trees when I show buffer allocations so making copies has never been a problem, yet I know it is there for a reason.  The LV compiler seems to do remarkably well handling memory issues, and when in doubt tries to err on the side of extra copies.  Perhaps there are a few situations where things go wrong in the other direction and this function will help.  Or, maybe since we have been given more power to muck around with the allocation process, this is now required to restore order.

I'd really like to see an example where this function is used "naturally", ie. not to overcome a compiler glitch.  Of course, if you have seen a glitch that is fixed by this, that is also good to know.

VIOTD groundrules here. 

[tst]

---

Darin.K wrote:

I'd really like to see an example where this function is used "naturally"

---

I don't think there is one. The primitive is explicitly there to help you control how the compiler allocates memory.

If you search the LAVA forums, you should be able to find one of AQ's threads where he posts an implementation of a map which relied on this primitive - I believe it was used to make sure a new buffer is always created, so that the old one is guaranteed to stay in place, but I don't remember the details.

[dan_u]

---

Darin.K wrote: Of course, if you have seen a glitch that is fixed by this, that is also good to know.

---

There was a bug in LV 8.5 which could be solved by using the "Always Copy" function. See this thread. I don't have a use case other than overcoming compiler glitches, either.

Message Edited by dan_u on 10-15-2009 04:45 PM

[Andrey_Dmitriev]

---

Darin.K wrote:

I wish I had more to say about today's function, "Always Copy", ...

... 

I'd really like to see an example where this function is used "naturally", ie. not to overcome a compiler glitch.  Of course, if you have seen a glitch that is fixed by this, that is also good to know.

---

Great function for Bug fixes in LabVIEW!

Refer, for example, to the following threads:

Bug in cluster to array in for loop with non-indexed output

Unxepected behaviour with clusters inside of while loop with shift register

With best regards, 

Andrey.

[dan_u]

---

Andrey Dmitriev wrote:

Great function for Bug fixes in LabVIEW!

---

Probably this was the purpose of this function 

It's great that the compiler tries to optimize (reuse) memory as much as possible, so there might be cases where it does it's job a bit overzealous and reuses memory where it shouldn't. Then this function comes in handy.

[F._Schubert]

If you play with ddl's and pointers, this might be useful in some situations. But I havn't run into this yet in the real world.

Also I guess that when you want to get the best performance out of an critical algorythm, it might be useful to explictly copy the data of one branch of the wire and reuse the other branch.

I would generally say, that it needs to be used together with InPlace, Reference and that sort of advanced functions.

Felix

[BYeske]

Also, here is a link to another thread where this Always Copy Vi fixed a bug in LV 8.6.1

http://forums.ni.com/ni/board/message?board.id=170&message.id=386839#M386839

Edit*  I didn't see this link listed above.

I have always wondered about this fuction also.  I am just now getting more involved with using the in-place functions.

Message Edited by monzue on 10-15-2009 11:14 AM

[Ben]

Aside from bug fixes...

I have not used it explictly in code development yet, but I beleve it can shine when doing heavy number crunching on a data set with multiple processesors. Here is the scenario where it could be used.

Suppose that memory is not an issue.

If we have a data set that is looked at by a bunch of number crunching routines that does not modify the data AND there is one that does update the data.

If we write code that presents the same wire to all of the sub-VI (with terminals on the icon connector wired thru) that crunch the data including teh one that changes the data...

LV can do allof the work in-place by controlling the execution order. By scheduling all of the "look only" code to run first and then allow the VI that modifies the buffer to run, everything can be done in place. But to pull this off, LV had to force the "lookers" to run first and THEN let the poking code to run.

If we use the "always copy" to feed the wires of the sub-VI's, LV can allow all of the number-crunching code to run in parallel on multiple cores.

Now before you reply saying the above is a convuluted example, let me ask "Did you really expect a simple use-case for a function that conteracts in-placeness?

Your thoughts?

Ben

[dan_u]

---

F. Schubert wrote:

...to get the best performance out of an critical algorythm, it might be useful to explictly copy the data of one branch of the wire and reuse the other branch.

---

The ideas of Felix and Ben are kind of similar. This definitely makes sense. If you have two branches you can control which one creates a copy. Good point.

[Darin.K]

I knew it would be a tool for the power users since the rest of us spend our time fighting against making copies.  I also like its bug-fighting powers.  Most times when we come across a bug, the workaround is very complex because the compiler is going to do what it does and there is usually nothing we can do about it.  Here we can give it a little kick in the pants now and then.