Memory Manger

[santi122]

Hi,

I am working at a high perfomance Application on a cRIO 9014 where I have to store big amounts and have a need to acess the data very fast.

Is there a possibilty to allocate an amount of memory e.g 10 MB and access this memory via references.

e.g. I store Data with a size of 10 kB and get a reference for this if i want to read or delete it.

I know it´s also possible to realize this with arrays, but this is not as fast as references(pointer).

Anyone an idea ?

greetz from Austria

chris

[Pnt]

You can not preallocate memory in LabVIEW.

The main reason is that it is not needed. 

---

santi122 wrote:

I know it´s also possible to realize this with arrays, but this is not as fast as references(pointer).

---

How did you came to that conclusion ?

10Mbytes are a small amount of memory, and LabVIEW will have no problem.

You should be careful, not to make data copies ....

You can post a test vi, so we can possibly help you with your coding style

Message Edited by Pnt on 11-13-2009 01:17 PM

[Ray.R]

Sometimes, when trying to complicate things within LabVIEW to manage memory (as you would do in C), you end up messing things within LabVIEW  😉

As Pnt mentionned, please post you r code and people can make suggestions on how to improve performance (if necessary)

Message Edited by Ray.R on 11-13-2009 09:15 AM

[DFGray]

Please tell us whether you are trying to do this on the FPGA or the host as well. I would assume the host, but just need to verify.

[santi122]

Hi,

thanks for your replies ! What I want to do is to manage a lot of 1D I32 Arrays with different lenght which represent data sets. Store them in an 1D or 2D array is quite complex and you need a datamanagement if you delete a dataset and want to use the free place for a new set.

I solved this now with the new Data Value References of LabVIEW 2009. I have an array of references which are pointing to my datasets.

greetz Chris

[Pnt]

 I thought the new Data Value References are not designed for that.

A simple reference would do.

Have you notice a better performance ?

We need some performance tests....

[Ben]

---

Pnt wrote:

 I thought the new Data Value References are not designed for that.

A simple reference would do.

Have you notice a better performance ?

We need some performance tests....

---

They will allow that type of usage. The only draw back that comes to mind from doing i that way is it would be possible to run into a dead-lock if you don't code it right. Lets see if the following illustrates the issue.

1) Array of DRVs is used by two sub-VI A and B.

2) "A" get the ref for the first block OK.

3) "B" gets the ref for the second block OK but needs to look at the first buffer currently owned by "A".

4) "A" wants to compare what is the first block (it owns it already) so tris to look at the second block owned by "B".

So both "A" and "B" are hopelessly dead-locked. There is nothing built into the DVR to prevent this dead-lock.

Now as far as speed goes...

LV is DAMN good at optimizing our code provided we don not ham-stiring by using less than optimal code constructs. Now being honest about LV and performance, the few people that have LV performance issue masters are few and far between. So unless you are a LV performance Guru it may be easier to code using the DVR since the memory usage is no longer implied but is explicit.

So in theory a DVR is not always faster, but writing fast code with a DVR can be easier.

The above are just my thoughts on the Q. If you have another opinion please share.

Ben

[F._Schubert]

Well, it's specified that we need an array of references. Each data set is an array of random length (but they are all of the same type).

There are several concepts of doing by-ref, which might be the one big reason behind developing the DVR. But we should not forget the classic approach via single element queue. And when you want to 'include' code, have a vi ref to a AE, although the VI Server overhead might be a problem.

Felix

[Ben]

---

F. Schubert wrote:

Well, it's specified that we need an array of references. Each data set is an array of random length (but they are all of the same type).

There are several concepts of doing by-ref, which might be the one big reason behind developing the DVR. But we should not forget the classic approach via single element queue. And when you want to 'include' code, have a vi ref to a AE, although the VI Server overhead might be a problem.

Felix

---

I'd go with Queues over VI served AE's. I suspect the VI server Invoke node call by reference's ability to work across the network prevents it from being able to work "in-place" when passing data to or recieving from same.

Ben

[F._Schubert]

It really depends on other constraints. If most of the number crunching is inside the AEs and we do cluster computing... I really would love to see an app like that, based on Tomis worker-pool of course... 😉

Felix