Does an autoindexing parallel For loop retain element order?

[BertMcMahan]

Embarrassing question time... I can't seem to find this in the documentation.

If I have an For loop processing a bunch of data (autoindexed at an input) that generates a new value unique to that input, and I autoindex the output, will LabVIEW guarantee my output array is in the same order as my input array?

I understand that, for parallelization to work, all operations must be completely iteration dependent. In my case, the operations don't depend on results of other iterations, but they do need to stay in the same order. I can't see anywhere how autoindexing an output tunnel works.

Will an autoindexed output tunnel give me results in the order they were processed, or in the order they were in originally?

(In other words- if I need to maintain the order of my data, do I need to keep track of the index manually, then resort the output later, or will the autoindexed loop do that for me?)

[mcduff · Accepted solution]

---

@BertMcMahan wrote:

Will an autoindexed output tunnel give me results in the order they were processed, or in the order they were in originally?

Originally ordered. I have done parallel processing on segments of an array, and the segments return in the correct order. 

[altenbach · Accepted solution]

It will be exactly as expected. One of the overheads of the parallel FOR loop is splitting up the tasks and assemble the results back in the correct order.

If you graph the instance ID, you can see it is all over the place (Since there is basically no code inside the loop, the compiler decided that two instances are sufficient for automatic partitioning, even though I have 32 cores here)

[BertMcMahan]

Thanks to both of you for confirming! That was what I guessed (and found in testing), but I couldn't be sure my test cases weren't oversimplified to where I just "got lucky" with it.

[JÞB]

---

@BertMcMahan wrote:

Thanks to both of you for confirming! That was what I guessed (and found in testing), but I couldn't be sure my test cases weren't oversimplified to where I just "got lucky" with it.

---

Interesting enough.   Although,  the output elements are ordered to be consistent with the input elements,  there is one strange case.

If, you stick the dice (PRNG) in a parallel For Loop, you are guaranteed to get an output array containing the same values (given the same initial seed) BUT, there is no means to track which iterations execute in each order!  HENCE: the array output values may be flip-flopped in order but will contain all of the exact same values!  (There is an inherent seed leftover sent to the next to execute die roll)  you get the same die roll, PRNG, values but the order they rolled is the order out

Not all loop iterations are completely agnostic to values within prior iterations! The Compiler is smart enough to avoid ALMOST all of those!  You should ensure that your data elements ARE completely independent (an IIR or even FIR filtered array input could mess that up muchly)

[BertMcMahan]

Interesting. I wish there was about 20% more documentation on this sort of behavior.

In my particular use case, I generate a waveform of data, then use each point to create a packet to send to a device. There are several hundred thousand of these packets that need to be created, and there's a bit of a delay when making them. I need to make this giant list of packets, and I need to send them in order, but the time sequence is already defined when I start the loop.

The only potential dependency would be if I used the i terminal as a packet counter input (to number sequential packets), but I do know that's not repeatable (that one's in the example finder) so I'll be using a separate sequential array as the packet counter.