LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Missing function: memory copy

Hi,

Perhaps this should be posted to the feature request forum, but I really
like some discussion on the subject as well...

I'm making some compression and decompression algorithms, and am finding
that the C implementations are a factor 10 faster. I always claimed myself
that G code can be nearly as fast as C code, but in this case, I really
think it can't be as fast... I really don't want to use external routines,
since they are not platform independent.

The algorithms typically use a table that stores data. This data is then
copied to the output. That's a very simple description, in fact it's much
more complex.

In C, you can simply copy from one array to another, and this is just as
fast as any other copy. If you copy a number of values, it might even be
faster, since you get caching benefits and perhaps even mmx stuff kicking
in.

In G, there is no way to copy from one array to another, without first
making a new array. This really eats away processor time. So, why isn't
there a node that has one source array (in), one destination array (in/out),
an index (in) and length (in)? Or is there another solution to this in pure
G (I don't think so, but you never know)? This shouldn't be hard to make for
NI, but impossible for us, G programmers...

Regards,

Wiebe.


Message 1 of 34
(3,261 Views)

You can't do that with the in-place memory operators?

 

Could you post a code example to demosntrate whay you wna to do but can't?

 

Confused,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 34
(3,243 Views)

So, why isn't there a node that has one source array (in), one destination array (in/out), an index (in) and length (in)? 

 

 

There is:

Pic

 

 
 
 
 
Message Edited by CoastalMaineBird on 03-23-2009 06:36 AM
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 3 of 34
(3,230 Views)

This is very slow, compared to how C does it. This is because the array subset has to be created, before it is inserted into the other array.

 

 

Regards,

 

Wiebe.

MemCopy

Message Edited by wiebe@CARYA on 03-23-2009 07:27 AM
0 Kudos
Message 4 of 34
(3,216 Views)

..and this is what I would like to have...

 

 

So instead of:

Creating a new buffer allocation

The subset is copied to this new buffer allocation

Copy the new buffer to the destination array

 

We can simply:

 Move the data from source to destination.

 

Message Edited by wiebe@CARYA on 03-23-2009 07:40 AM
Message 5 of 34
(3,208 Views)
>There is:<img
src="http://forums.ni.com/ni/attachments/ni/170/396397/1/Picture%201.png"
border="0" alt="Pic" title="undefined" width="294" height="211" align="left"
onmouseover="undefined" onmouseout="undefined">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Message Edited by CoastalMaineBird on
03-23-2009 06:36 AM

No, that doesn't do what I explained.

This function gets a subset of an array.

What I want, is to copy this subset into another array. Without the get
array subset allocating a new array first.

Regards,

Wiebe.



0 Kudos
Message 6 of 34
(3,206 Views)

I fully agree, I'd also like this function. I just programmed a VI where this would have been useful.

I think it would have 2 array inputs, plus an index and a length for the portion of the source array to be copied and an index for the destination array.

It would basically be the combination of array subset and replace array subset, but without doing the copy first.

 

Very good idea... I hope to see this in a future version of LabVIEW!

 

Daniel

 

0 Kudos
Message 7 of 34
(3,202 Views)

This is how I envisioned the same code using the inplace operators.

 

 

Buffer "A" and "B" are created by the init arrays. Since A is not modified, buffer "A" is used as the source of the data.

 

Buffer "B" is really handled by the compiler (in the source code, like "A") so to make sure it is the same from run to run it is copied to buffer "C" where all of the work is done.

 

The lack of buffer allocation dots show that all of the rest of the work is done "in-place".

 

I hope that is getting closer to your concern,

 

Ben

Message Edited by Ben on 03-23-2009 07:51 AM
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 8 of 34
(3,200 Views)

Is it something like this function. I think it appeared in Labview 8.6

Message Edited by t06afre on 03-23-2009 01:57 PM


Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)
0 Kudos
Message 9 of 34
(3,193 Views)

@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.

 

Also, I think if you don't need the old value, there's no need for the in-place element structure because replace array subset should also be an in place operation.

 

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

 

 

Message Edited by dan_u on 03-23-2009 02:01 PM
0 Kudos
Message 10 of 34
(3,188 Views)