Parallel For Loop versus Async Call and Collect

[Stagg54]

A question about this came up the other day and I didn't have a good answer.

If you have a VI that needs to be run multiple times in parallel and all the results collected, which is better? Parallel For Loop or Async Call and Collect?

They are already calling it in a for loop serially and are just looking for better performance - it talks to several identical hardware devices so the for loop autoindexes on the Hardware refs. Parallel For Loop seems like an easy answer, but what are the tradeoffs? I seem to remember something about Parallel For Loop and the number of cores - I don't really know. I haven't used the parallel for loop much.

My initial answer was to just try both approaches and benchmark them.

[crossrulz]

What is the communication bus that is used to talk to the instruments?  Assuming anything VISA, it is likely that the communication time will swamp out any gains from going parallel.

As a gut feel, I would likely go with the Parallel FOR Loop simply because it is easier to code up than two FOR loops (one to launch the VIs and a second to collect the results).

[ShaunR]

There are surprising few situations where a parallel for loop (pLoop) is the solution. There are so many caveats and foot-shooting opportunities even if you ignore the caveats imposed by the IDE dialogue.

For example. For the pLoop to operate as you would imagine, Vi's that are called must be reentrant (and preferably preallocated clones). If a called VI is not reentrant then the loop will wait until it finishes before calling it in another parallel loop (that's just how dataflow works). If a called VI is set to reentrant shared clones then you get the same problems as with any shared clone that has memory but multiplied by the number of loop iterations.

Another that you often come across with shared, connectionless resources (say, raw sockets) is that you cannot guarantee the order that the underlying resource is accessed in. If it is, say, a byte stream then you would have to add extra information in order to reconstruct the stream which may or may not be possible. I have actual experience of this and it is why the ECL Ping functionality cannot be called in a pLoop.

 

[Jordan Kuehn]

4 hours ago, ShaunR said:

There are surprising few situations where a parallel for loop (pLoop) is the solution. There are so many caveats and foot-shooting opportunities even if you ignore the caveats imposed by the IDE dialogue.

For example. For the pLoop to operate as you would imagine, Vi's that are called must be reentrant (and preferably preallocated clones). If a called VI is not reentrant then the loop will wait until it finishes before calling it in another parallel loop (that's just how dataflow works). If a called VI is set to reentrant shared clones then you get the same problems as with any shared clone that has memory but multiplied by the number of loop iterations.

Another that you often come across with shared, connectionless resources (say, raw sockets) is that you cannot guarantee the order that the underlying resource is accessed in. If it is, say, a byte stream then you would have to add extra information in order to reconstruct the stream which may or may not be possible. I have actual experience of this and it is why the ECL Ping functionality cannot be called in a pLoop.

 

Not to derail the above conversation, but can this ping function reliably time out in Windows sub 1s?

[hooovahh]

2 hours ago, Jordan Kuehn said:

Not to derail the above conversation, but can this ping function reliably time out in Windows sub 1s?

I went to dig up my fast ping utility for Windows, but I see you were already in that thread.

As for this thread.  I rarely use the parallel for loop but when I do it is a more simple set of code.  It has those caveats Shaun mentioned and I typically use it is very small cases, and where the number of iterations typically are small.  In the past I did use it for accessing N serial ports in parallel to talk to N different devices sending the same series of commands and waiting for all of them to give the responses.  And I have used it for cases when I want to spin up N of the same actor.  Here there is other communications protocols to handle talking between processes.  And again these are usually limited to some hardware resource like two DMMs that are independent.  If it needs to be very scalable, and have large numbers of instances a parallel for loop probably isn't what you want.

[Jordan Kuehn]

1 hour ago, hooovahh said:

I went to dig up my fast ping utility for Windows, but I see you were already in that thread.

As for this thread.  I rarely use the parallel for loop but when I do it is a more simple set of code.  It has those caveats Shaun mentioned and I typically use it is very small cases, and where the number of iterations typically are small.  In the past I did use it for accessing N serial ports in parallel to talk to N different devices sending the same series of commands and waiting for all of them to give the responses.  And I have used it for cases when I want to spin up N of the same actor.  Here there is other communications protocols to handle talking between processes.  And again these are usually limited to some hardware resource like two DMMs that are independent.  If it needs to be very scalable, and have large numbers of instances a parallel for loop probably isn't what you want.

Thanks for the reminder! Since that comment I've had increased need to run this on Windows in a similar use case, but the linux command doesn't port over well. I'll give your tool another look!

[ShaunR]

17 hours ago, Jordan Kuehn said:

Not to derail the above conversation, but can this ping function reliably time out in Windows sub 1s?

Yes but you'd need to define "reliably". I think there would be  few milliseconds of jitter and probably a minimum of about 4ms.