Change definition of the number of parallel instances in For Loops

[GregSands]

I've just run into a "feature" of the LV2009 Parallel For Loops which is a bit of a nuisance!  The number of loop instances is determined by two values: 1) the number of instances in the Configure Iteration Parallelism dialog, and 2) the number wired to the P terminal of the loop.  It turns out that the number of instances created is the smaller of these two.

The nuisance is that if I wire the number of processors from CPU Information to P (as recommended) then when my new 16-core machine arrives (I wish!) I don't get that benefit unless the dialog value is also >= 16.  And the 64-core machine that arrives next requires the dialog value to be reset in every Parallel For Loop - or I set it to be some unreasonably large number now, and therefore it's pretty much meaningless.

My suggestion is that the default number of instances set in the dialog is "Maximum" - i.e. it will use the maximum number of processors available.  It should still be able to be set lower should the programmer wish to restrict the number below that.  Then the default case works transparently as the programmer would usually want without needing to wire from CPU Information, and there are no surprises down the track when loops don't speed up on a new machine as expected.

[Dragis]

does it hurt to just set the value in the dialog to, say, MAX_INT and then always use P to throttle it down to a reasonable number?

[GregSands]

Looks like it's currently limited to 64.  It would still be nice not to need to type that in for every parallel loop.

[Intaris]

I wouldn't want the number of threads limited to the number of logical cores.  Some iterations may include functions with wait times (instrument control) and an 8-core system would probably be able to deal with 16 (or more) threads no problem.

[JasonD_at_UML]

I *just* saw this myself a week ago. I had developed on a 4 core box, and then moved the code to an 8 core machine. It took us a while to figure out why we could only get 4 of 8 cores to fire up.

It's very confusing to have to do it twice - This makes it difficult to port code to other machines, unless I remember to enter 64 cores (the max allowed), and then also use the CPUInfo vi.

On the plus side... I absolutely LOVE how easy it is now to parrallelize loops! Nice work NI!

[JasonD_at_UML]

Intaris - I don't think it has to do with threads in this Loop Parallellizing usage as much as cores to operate on.

For my heavy number crunching program, we actually turned off the hyperthreading - we were seeing 16 cores in the CPU monitor, even though we had "only" 8 physical cores. 

[jdeguire]

Would it be better to have the value wired to the P-Terminal always override whatever is in the dialog box, regardless of which one is larger?  That way, you could use the option in the dialog box as a default value if you leave P unwired.

[mfletcher]

GregS is correct; the number of instances executed at run time is min(the value entered in the dialog box, the value wired to P). At compile time, LabVIEW generates as many copies of the loop as you specify in the dialog. At run time, the amount of parallelism is limited by the number of instances generated at compile time.

We understand that this can be confusing and that it leads to code bloat. This implementation allowed us to ship the Parallel For Loop sooner, and except for some confusion, it has worked well.

For now, we suggest entering a number in the dialog box that is the most instances you expect to need. If you expect to get an n-core machine in the next few years, set the value to n. (It's unlikely that machines with more than 64 cores will be common any time soon, so I don't expect that the limit of 64 will be an issue.) Keep in mind that making the number of instances large will increase the code size and compile time. As a result, I would not recommend setting the value to MAX_INT. 😄

We may eventually remove the number of instances setting from the Configure Iteration Parallelism dialog box, and instead of generating loop copies at compile time, spawn the instances dynamically at run time. There isn't a known release date for that change though.

Message Edited by mfletcher on 04-16-2010 01:44 PM

[mfletcher]

Also, you don't need to wire CPU Information to P. If you leave P unwired, LabVIEW will default to the number of logical processors on your machine.