Jump to content

Parallel For Loops inside another


Recommended Posts

I have a parallelized For Loop within another parallelized For Loop to quickly process a 2D array. This is in a reentrant VI that is called twice "at the same time" (nothing guarantees that they run at the same time, but they can execute in parallel with the way they are wired in the caller VI)

It seems to be causing random issues... some of the output is set to 0 randomly... these zeros seem to appear by chunks, so it seems related to the loops not working correctly. I was always feeding it the same data and the output was changing.

Did anyone ever noticed these issues as well?

I'm having trouble reproducing it reliably though.

I disabled the parallelism of the inner loop, and my output was fine, then I re-enabled them and it's still fine, so I don' t know if it has to do with the modifications being in memory or whatever, but yeah...

post-25044-0-59135300-1309443327_thumb.p

Link to comment

There are several white papers and various forum threads on the use of parallelized for loops. I believe it is not very useful to nest parallelized for loop. Not wiring the P terminal, will yield a number of threads equal to the logical processors. I think the way you have nested these for loops will cause twice the thread count, and not be more efficient then a single parallelized for loop, nested with another regular for loop.

If you can reproduce the issue, you could submit it to NI on their forums.

Link to comment

We fixed something that sounds exactly like what you are describing for LV 2011. I tried running the snippet you attached in LV 2010, and I got the correct answers. It's possible you have the connector pane configured differently than I do. Can you attach the actual VI that is reproducing this issue? I want to try it in 2010 and 2011 to make sure we fixed what you are experiencing.

Mary Fletcher

Staff Software Engineer

LabVIEW R&D

Link to comment

Well, I'd have to do some more tests, cause what you see up there was actually called twice from a VI (in parallel), and the result of both calls was thrown into another similar nested for loop. So I'm not sure which loop was creating the problem.

Note that the array in there was about 2500x2000 (from ImageToArray), so I guess it takes quite a lot of data before it gets confused.

SuperS, that's a good point you have there... but I'm wondering, does it really take the number of processors, or does it take the value you give it in the 'Configure iteration parallelism...' dialog? These 2 information seem contradictory :/

But either way, I guess it makes sense that it doesn't add any efficiency anyway.

Link to comment

If it reproduces again, post the VIs. I suspect that the problem is with the nested loops in the subVI and not with the calling VI.

The number of loop instances used at run-time is the minimum of the number specified in the dialog and the number wired to P. If you don't wire anything to P, that input defaults to the number of logical processors in the machine. If you have a quad-core machine and you specified at least four in the dialog, both loops will be four-way parallel. The outer loop will execute using four loop instances, and each of those loop instances will execute the inner loop using four loop instances. That would result in 16 loop instances executing in parallel. SuperS_5 is right that this probably is not efficient.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.