LabVIEW
How does parallel for loop effect iteration terminal
Sorry, the only consistent rule that I can see is, "If you're not sure how it works, you probably don't need to use it." I fall into this category. So far, I haven't found a use case where its efficiency was worth setting it up correctly. Indeed, it could very well be less efficient if not set up properly.
With almost every optimization choice, it's better to "let LabVIEW do its thing".
To test just wire from N to the outside via an autoindexing terminal and look at the resulting array.
The iteration terminal is not very useful. I sometimes configure the terminal to provide the parallel instance ID and use it to execute ID dependent code. (For example in this program I have N non-reentrant dlls, all with the same code, but different file name. The Instance ID decides which one to call. See picture from this discussion. For example I can just set "parallel instances=1" to see if parallelization even helps. Sometimes it does not!)
As a general rule, I would stay away from too much micromanaging of the behavior. Just leave things at automatic, it does a great job! It is sufficient to define the number of parallel instances.
It turned out that indexing works on chunks as I expected. Every instance starts with the expected index as it would in plain sequence. The ambiguities came from my combination of test data and processing.
I have a room of interest for my 3D array. I use the index values instead of Array subset.VI+autoindexing. I hope that I save some memory this way, since my 3D input array is of the size of some gigabyte.
@Quiztus2 wrote:
I have a room of interest for my 3D array. I use the index values instead of Array subset.VI+autoindexing. I hope that I save some memory this way, since my 3D input array is of the size of some gigabyte.
Emphasis set by me. You hope and much more than that it is most likely not. Array Subset is fairly smart. It does not automatically create a copy of the data subset but rather a so called subarray. A subarray in LabVIEW is under the hood a pointer to the original array data and an offset and stride, possibly for every dimension. Many build in LabVIEW array nodes know to massage their parameters accordingly to translate the provided indices in a way that point to the correct data in the original array.
A useful display is to just graph the Parallel Instance ID to play around with the various options.
Here's how it look on "automatic" on my old laptop.
Note that if there is no 0ms wait, the compiler avoids the parallelization overhead because it would be detrimental for such a fast loop. 😄
