LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

For Loop Parallelization

Hi All,

I need to run an algorithm on 12 images. One way would be to run it in a for loop sequentially. However this will take a long execution time.

So after searching a little I  found that an alternative to speed up execution is by the using parallelized for loop- as seen here

 

I have 1 subvi(lets call it-mytry1.vi) which is present inside the parallel loop. mytry1.vi is preallocated re-entrant.

mytry1.vi uses functions from image processing toolkit and contains shift registers. All the library functions are also made re-entrant(by default they are shared and not pre-allocated).

 

My PC config is intel dual core 2.0 GHz and I'm using LabVIEW 2013.

 

When I use Find Parallelizable loops (Tools->>profile->>) to see whether mytry1.vi is parallelizable or not, I get the following result

for loop 1 : Possibly not parallelizable - One or more nodes in the For Loop may have side effects. 

I ignore this and make it a Parallelized for loop(this does not throw any error).

 

When I run the vi, it is behaving as a sequential for loop rather that parallelized.

Why does this happen? Is it because of the use of shift registers?? 

 

Regards

Aveo 

 

0 Kudos
Message 1 of 3
(2,506 Views)

Shift Registers themselves would not cause a problem.  Unitialized Shift Registers, however, could cause all kinds of interesting issues with state.  But that has nothing to do with your loops behaving serially.

 

I'm thinking it could potentially be the DLLs the toolkit calls are not thread safe.  They could potentially be set to run in the UI thread, which would cause the serial processing you are seeing.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 3
(2,481 Views)

Hi crossrulz,

My shift registers are all initialized. So no issues with that. 

However you may be correct about the inability of the dlls to run parallel threads.

Is there any way to override this? 

Also I checked a few function from the vision toolkit for the "run in UI thread" option. However , they turned out to be set to "Run in any thread" option by default.

 

A thought just struck me- I am using functions from openG toolkit. Maybe they are set to "run in UI thread". I will check it out and post. 

 

Regards

Aveo

 

0 Kudos
Message 3 of 3
(2,476 Views)