Missing function: memory copy

[Wiebe@CARYA]

"dan_u" <x@no.email> wrote in message
news:1237821016357-876051@exchange.ni.com...
> 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&nbsp;recognize this pattern automatically, but it might be
easier to have a new primitive.
> &nbsp;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!&nbsp;

I could live with that!

I think a new node to do this might be better to read, and perhaps easier to
implement for NI. Also, you only need to drop one node, in stead of two!

I'm in doubt about what whould be better... Automatic optimization sound
good too.

Regards,

Wiebe.

[dan_u]

---

Ben wrote:

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!

---

I'm still on LV 8.5 so I can't open the benchmark VIs, but this matches my experience. In place array operations (like replace array subset) are quite efficient in LabVIEW, but loops are not.

I wonder how much it could be improved with the primitive Wiebe suggested (or with the improved memory management as discussed before).

I recently had a similar problem, I had to convert a 24 bit array (represented as U32) to an "interleaved" 8 bit array (U8). I tried every possible method I could think of in G, but a C dll improved execution time by a factor of ~4. Just like Wiebe, I'd prefer not to use dll but plain G.

Daniel

[Coq_Rouge]

In this discussion I guess we miss something I have tried to illustrate in the picture below, and I somehow agree

Message Edited by t06afre on 03-23-2009 05:20 PM

[dan_u]

---

t06afre wrote:

In this discussion I guess we miss something I have tried to illustrate in the picture below, and I somehow agree

Message Edited by t06afre on 03-23-2009 05:20 PM

---

I don't see what you mean and what this has to do with the discussion, but anyway your "equal" sign is wrong.

Message Edited by dan_u on 03-23-2009 05:48 PM

[Wiebe@CARYA]

Here's another problem I'm having:

Since letting LV build array's is very slow, I pre-allocate an array. But
what if this pre-allocated array is too small? This happens if you know the
array is going to be big, but you don't know how big.

I tried to check the size, and then in a case add a second large array to
the pre-allocated array. But the case forces a buffer allocation every
cycle, so instead of gaining speed, it becomes dreadfully slow! In this
case, there is no good C solution either, but boost and other libraries do
this pretty good.

Some control over how much an array grows automatically when it is too small
(internally), and it's start size in memory would be great.

Off to NI days tomorrow, so no new messages from me for a while, regards,

Wiebe.

[CoastalMaineBird]

That picture is most decidedly incorrect, as you will discover if you put an indicator on both outputs.

The first will have an array of 100 elements, containing 0...99.

The second will have an array of 100 elements, all zeroes except for #99 which contains 99. 

[RavensFan]

---

Wiebe@CARYA wrote:
Here's another problem I'm having:


I tried to check the size, and then in a case add a second large array to
the pre-allocated array. But the case forces a buffer allocation every
cycle, so instead of gaining speed, it becomes dreadfully slow!

---

How does it behave if instead of adding a 2nd larger array, (I assume you mean by Build Array?), you use Reshape Array?

[rolfk]

For this particular problem you could actually get away with calling LabVIEW:MoveBlock() in a Call Library Node. This is in fact the operation you are trying to get here from LabVIEW.

It is technically calling external code, but it is platform independant since you're calling to LabVIEW itself with this.

Rolf Kalbermattter

[dan_u]

---

rolfk wrote:

For this particular problem you could actually get away with calling LabVIEW:MoveBlock() in a Call Library Node. This is in fact the operation you are trying to get here from LabVIEW.

It is technically calling external code, but it is platform independant since you're calling to LabVIEW itself with this.

Rolf Kalbermattter

---

This sounds like a good approach. Is there any way to specify offsets? Basically we'd have to pass pointers to a specific element in the source and destination arrays. Let's say I want to copy elements 11-20 from source array to positions 31-40 in destination array. Can this be accomplished using MoveBlock()?

Daniel

[F._Schubert]

If working with pointers, you can just add the offset to them. I think the offset was counted in Bytes (as is the Length in MoveBlock).

Felix