Missing function: memory copy

[Ben]

---

dan_u wrote:

@Ben: This does it in place, that's correct. But instead of allocating an intermediate array it requires a for loop. This also slows things down if you have to copy big portions of the array.

I didn't do benchmarks, I think whether this method or the array subset / replace array subset combination is faster depends on the size of the portion to copy. One solution allocates memory, the other requires more CPU.

Daniel

---

Only an apples to apples benchmark will reveal the true answer but both require CPU (unless they added a new cross-bar switch the computers since I last looked) but one requires allocating memory which involves the OS kernal and possibly some disk I/O to go with it.

Just trying to help (and maybe learn something along the way),

Ben

[ceties]

2t06afre: It's available sinve 8.5

Message Edited by ceties on 03-23-2009 08:05 AM

[tst]

---

wiebe@CARYA wrote:

---

 

There is a very good reason why LabVIEW can't do this.

A LabVIEW array is stored as a single block of memory. The array subset primitive uses pointers to avoid allocating a buffer, but the replace primitive can't use this pointer. It HAS to copy the data into its own space. This doesn't require an extra allocation, but does take time.

If you single step through the attached example (8.6) you will see that only two 16 MB buffers are allocated (and another one for the indicator), but there's no intermediate buffer. I think that's as efficient as LabVIEW can get without changing the single block rule.

[dan_u]

@tst: The array subset only doesn't allocate memory because you don't use the original array (buffer) anymore. Wire the original array to the next frame and you'll see (as "show buffer allocations" displays correctly) that buffer is allocated if you continue using the original array.

While this is quite clever it doesn't help if you still need the original.

I mean in the end if there's a primitive as Wiebe suggests the implementation in C (behind the scenes) might be element-wise (as Ben shows in his example), but the loop in C might execute much faster than the one in LabVIEW. At least that's my experience.

Just my 2c.

Daniel

[Wiebe@CARYA]

"tst" <x@no.email> wrote in message
news:1237817427889-875972@exchange.ni.com...
> wiebe@CARYA wrote:
> <img
src="http://forums.ni.com/ni/attachments/ni/170/396410/1/MemCopy1.jpg"
border="0" alt="MemCopy" title="MemCopy" width="386" height="148">
> &nbsp;There is a very good reason why LabVIEW can't do this.A LabVIEW
array is stored as a single block of memory. The array subset
primitive&nbsp;uses pointers to avoid allocating a buffer, but the replace
primitive can't use this pointer. It HAS to copy the data into its own
space.

I don't see how arrays being stored as single block has anything to do with
it.

I know that the replace primitive can't use this pointer, that is why we
need the new function!

There is no reason NI can't copy data from one single block of memory to
another single block of memory, so NI should be able to copy data from one
directly to another (checking for length of both arrays of course).


>This doesn't require an extra allocation, but does take time.&nbsp; If you
single step through&nbsp;the attached example (8.6) you will see that only
two 16 MB buffers are allocated (and another one for the indicator), but
there's no intermediate buffer. I think that's as efficient as LabVIEW can
get without changing the single block rule.&nbsp;<img
src="http://forums.ni.com/attachments/ni/170/396449/1/Allocation.png"
border="0"><a
href="http://forums.ni.com/attachments/ni/170/396446/1/Allocation.png"
target="_blank"></a>

That is because the new allocated buffer is reusing the first preallocated
memory! If the top array is put in a shift register it can't be released,
and you'll see that there are 3 buffers allocated. If you use "Show Buffer
Allocations" it will show the same.

Regards,

Wiebe.

[tst]

---

dan_u wrote:

@tst: The array subset only doesn't allocate memory because you don't use the original array (buffer) anymore.

---

A valid point. Wiebe's suggestion would help in this specific case because it would explicitly tell LabVIEW that it needs to schedule things in such a way that the copy needs to happen before the top array is modified, thus not needing to create a copy at the array subset primitive. Ideally, LabVIEW should simply recognize this pattern automatically, but it might be easier to have a new primitive.

[dan_u]

---

tst wrote:

A valid point. Wiebe's suggestion would help in this specific case because it would explicitly tell LabVIEW that it needs to schedule things in such a way that the copy needs to happen before the top array is modified, thus not needing to create a copy at the array subset primitive. Ideally, LabVIEW should simply recognize this pattern automatically, but it might be easier to have a new primitive.

---

Great idea! That would be perfect, if LabVIEW would see that the copy is not needed anymore after inserting the data in the 2nd array and thus not make a copy. This could speed up this operation significantly!

[tst]

---

Wiebe@CARYA wrote:

I don't see how arrays being stored as single block has anything to do with it.

---

I misread your suggestion. I thought you meant it should simply point to the existing data.

---

That is because the new allocated buffer is reusing the first preallocated memory!

---

There is no "new" buffer in my example. The array subset simply points to part of the original array.

The fact that there is a buffer allocated when the top array is wired elsewhere actually suprised me. I thought that LabVIEW does schedule the execution in such a way as to minimize unnecessary data allocations. I must be confusing this with another detail of the LabVIEW optimization methods.

[Ben]

I just benchmarked the original sheme posted vs the inplace operation in a For loop (also as illustrated earlier) and the winner is....

The traditional method (original pattern) beating out the In-place/For loop version by a facto of 10X or more!

The iteraction of the foor loop appears to be the issue.

Ben

Attached is LV 8.6 benchmark code

[Ben]

enum for above