Parallel processing on different data size

[Amit B]

Hello, 

I got a matrix with with N columns.

I would like to run the same processing (sub VI) on each column of the matrix and I'm trying to make it run in parallel.

I could duplicate the code N times, but it's messy, on the other hand, working with a loop will not make it run in parallel (As far as I know).

Is there a way to combine scalability of my code to different matrix sizes, while maintaining good parallelism?

Thanks,

Amit. 

[Robbob]

Amit,

Making the code into a subVI and making the subVI re-entrant will allow for parallel execution, given that you have a multi-core processor.  If the number of columns exceeds the number of cores you have, then you will no long have true parallel processing anyways.  If parallel operations are in the same loop, LabVIEW will automatically develop different threads for them and it is up to the OS on how to handle those threads.

I would look over the wealth of information on parallel execution at http://zone.ni.com/devzone/cda/tut/p/id/6422 and see if any of that information helps you.

[Ben]

---

Amit B wrote:

Hello, 

I got a matrix with with N columns.

I would like to run the same processing (sub VI) on each column of the matrix and I'm trying to make it run in parallel.

I could duplicate the code N times, but it's messy, on the other hand, working with a loop will not make it run in parallel (As far as I know).

Is there a way to combine scalability of my code to different matrix sizes, while maintaining good parallelism?

Thanks,

Amit. 

---

Been there done that. But boy does 32 processors running in parallel make a difference.

THere suggestion that rob made about using re-entrant VI's is a good one if your number crunching takes a long time and justifies the load time for all of the instances you will use. If this is still OK with you then use queues to fire off the data that need crunched and watch another queue for the results.

CC's original version of the Leader List used this approach so he could have multiple process hammering the NI site to query all of the users info. It worked rather well compared to the hours it would have taken to do it one after the other.

Or....

WEll you will have to check back in a couple of months if you want a better idea.

Ben

[Amit B]

Thank you for the answer, a few questions about it.

1. Are Sub VI's defined as re-enterant by default, if not, why not?

2. Is partitioning the data in 4 (the number of cores in my machine) and running in loops (4 separate loops) on the data within each of the sections a good design practice? Will the running speed be harmed if I put this loop in a sub-vi?

3.  What will happened in a couple of month? 

Thanks again,

Amit

[Ben]

---

Amit B wrote:

Thank you for the answer, a few questions about it.

1. Are Sub VI's defined as re-enterant by default, if not, why not?

2. Is partitioning the data in 4 (the number of cores in my machine) and running in loops (4 separate loops) on the data within each of the sections a good design practice? Will the running speed be harmed if I put this loop in a sub-vi?

3.  What will happened in a couple of month? 

Thanks again,

Amit

---

1) No. re-entrant VIs are (for the most part) made re-entrant by creating a seperate data space for each. This would require more memory and could have negative effects.

2) "Good" hmmm... If good means faster, then yes.

2a) Use of sub-VIs only become an issue when passing data to and returning from the sub-VI call. Make sure any terminals an the icon connector are on the "root" (white background of diagram) and check your buffer allocations etc to ensure you are not duplicating arrays.

3) I predict another stimulus package will be passed by the US congress and many states will push for a new contitutional congress to be held to ammend the constitution and enforce the tenth ammendment. I also predict that NI will release a new verions of LV that will include a lot of nice features that will make our lives easier. That is about all I can say for now. 

Ben