LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Increase max parallel loops on deployed executable

Solved!
Go to solution

Hi board,

 

I've been trying to speed up a PING + SSH process by using parallel loops.  Everything works well on my development system and I can run 20 loops in parallel, but when I deploy to a executable running the Runtime engine my parallel loops cap at 4

 

RHryniowski_0-1727731223070.png

I've looked at https://forums.ni.com/t5/LabVIEW/Maximum-number-of-generated-parallel-loops/td-p/3730104, but it seems to only apply to the Dev engine, when I add ParallelLoop.MaxNumLoopInstances=256 to the .ini generated with my build it does not seem to make a difference. 

 

Can anyone tell me what I am doing wrong?

0 Kudos
Message 1 of 12
(236 Views)

Could you do something like below as a workaround?

 

snip.png

0 Kudos
Message 2 of 12
(219 Views)

Hi Mcduff, I tried your suggestion, unfortunately it dropped the number of parallel loops from 20 to 10 on my dev PC and from 4 to 2 on the deployed executable with the runtime engine, doubling cycle time in both cases.  

 

RHryniowski_1-1727739235951.png

 

 

0 Kudos
Message 3 of 12
(184 Views)

It's not using hyperthreading. No idea why the deployed is incorrect.

0 Kudos
Message 4 of 12
(182 Views)

@RHryniowski wrote:

Hi Mcduff, I tried your suggestion, unfortunately it dropped the number of parallel loops from 20 to 10 on my dev PC and from 4 to 2 on the deployed executable with the runtime engine, doubling cycle time in both cases.  

 

RHryniowski_1-1727739235951.png

 

 


When you place the configuration option for increasing the max number of Loop instances in the file "<LabVIEW>.ini it applies to the LabVIEW application context.  

 

If you place that same line in MyApp.ini located in the same folder as MyApp.exe,  then that configuration option would apply to your executable.  

 

You didn't tell your application to use more that the default number of max Loop instances!  [Warning: this max number of parallel loop.instances value really can interact with the execution systems properties .... if you don't really know how to use execution systems on your OS let LabVIEW do that nasty work]

 

EDIT: What I am trying to say (nicely) is that you tweeked something that you shouldn't ought to tweek unless you have spent $ and practiced decades to know what you are doing.   You probably did not want to change that default behavior of MyApp.exe anyway.   but, you asked a fair question so, I did explain.

 

The Kudos button is tower left


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 12
(164 Views)

Thanks for the reply, I've tried adding ParallelLoop.MaxNumLoopInstances=256 to the .ini file, and even made sure my build options include Use custom configuration file.  Unfortunately there was no behavior or performance change.

RHryniowski_0-1727801194901.png

The workaround that I am using is to split the IPs into two groups and run two parallel loops... in parallel.  The deployed system can still only create 4 instances of each loop, but with each loop handling one group of IPs the scan sweep takes half the time.  CPU consumption rests at around 8.5% and memory usage is 60MB when the system is idle scanning for IPs.

RHryniowski_2-1727802060270.png

I'd still like a better understanding of why LabVIEW runtime can't seem to create more then 4 parallel loops.

 

0 Kudos
Message 6 of 12
(112 Views)

Changing the max number of parallel instances in the ini file has no purpose here, because you are well below the default max number.

 

What CPU hardware runs the "deployed executable"? Is this LabVIEW or LabVIEW RT? 

Message 7 of 12
(105 Views)

I'm running LabVIEW Runtime 2022 Q3 patch 3

RHryniowski_1-1727806386383.png

...on a I5-6300 with 4 logical processors.

RHryniowski_0-1727806323765.png

Comparing to my local PC which has 20 Logical Processors, this seems to be what is determining max parallel loops, is there a way to override this?  

0 Kudos
Message 8 of 12
(89 Views)

@RHryniowski wrote:

Thanks for the reply, I've tried adding ParallelLoop.MaxNumLoopInstances=256 to the .ini file,

 


This option is applicable for dev environment only, it doesn't take effect in Runtime. I mean, if you set this in LabVIEW.ini, then created a for loop with 256 instances, then build executable, then amount of the generated parallel instances in this loop will remain 256 as requested regradless from ini setting. This option is just to allow to set this in LabVIEW.

 

I think your problem is with ping or ssh. I'm not sure what inside, but with very big probability this is kind of DLL call, and then the world will changed, because by default LabVIEW will allocate only 24 threads per execution system and you will never ever able to get 256 parallel DLL calls within parallelized for loop. To be able to do this you have to set other ini key:

 

ESys.StdNParallel=256

It is quite simple to demonstate, just put inside of parallelized for loop the Sleep() from kernel32.dll with 1000 ms sleep and see what happened. The loop configured for 64 parallel instances will be executed 3 seconds (because only 24 calls will be executed paralel at the same time). But if you will set StdNParallel to 64, then the time will be decreased to 1 second.

Message 9 of 12
(88 Views)

You need to set it in the parallel configuration and wire the desired number to P. If P is not wired (as in your case), it will use the number of CPU cores.

0 Kudos
Message 10 of 12
(53 Views)