Dynamically parallel

[SuperS_5]

Originally Posted by kamocat

Hi Folks,

Here's how I'm trying to execute them in parallel:

Hi, You only have one VI ref here. You will need a new ref for each VI instance that you want to run. Secondly, you specify to open as a re-entrant VI as the option when opening the reference.
<Hint>Open VI Reference primitive</hint>

Edit: While this is "legal" LabVIEW code, I would recommend against it if you can avoid it. There is some overhead when opening VI's in this manner. (Dynamic calling) If calling parallel code statically, (IE. Specifying at edit time on the block diagram) the overhead is very minimal.

[Greg McKaskle]

As others have mentioned, you need to get a new vi ref for each run. What I'd recommend is to in advance, loop through doing the opens and putting the refs into an array, same size as the CAN IDs. Then your timing will not include data space cloning and mgmt overhead. Personally, I've only used this a few times, and for profiling, tend to drop the reentrant code N times. If much code is involved, I wrap it into another reentrant subVI. If I need hundreds, I drop ten, make a subVI, and drop ten of those, etc.

Greg McKaskle

[SuperS_5]

Hi again. I just want to add an extra note. The performance of parallel code will greatly depend upon the target. Single core targets will likely not benefit from parallel code. (Massively multi-core targets obviously benefit greatly) The exception would be if a piece of code must wait for a response from another device, then parallel coding MAY benefit. Usually LabVIEW's compiler can generate more efficient code that is serial then code that is parallel, and therefore, parallel code may potentially be worse in terms of performance. There are a number of articles on the NI site that describe this. Parallel "engines" like what I think you are trying to build can introduce race conditions.