LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does my simple parallel loop run slowly?

Hey, I'm very new to LabVIEW and I'm using it for a uni assignment where I'm demonstrating parallel performance. I've made an EXTREMELY simple program but for some reason when I enable iteration parallelism it takes annoyingly longer to complete. How do I do this properly?

0 Kudos
Message 1 of 7
(2,777 Views)

Hi xbaras,

 

why do you think the VI takes longer to run? Where do you measure the time?

 

For me it takes the same time regardless of parallelism. The only caveat is: the numeric indicator will show different results because the iteration order is kind of random with parallelism…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 7
(2,770 Views)

There is an overhead cost to making the FOR loop parallelize (creating threads, memory allocation, etc).  For something as simple as this, you will actually lose performance.  Now if you do some decent sized FFTs, then you will see the benefit.


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 3 of 7
(2,725 Views)

@xbaras wrote:

Hey, I'm very new to LabVIEW and I'm using it for a uni assignment where I'm demonstrating parallel performance. I've made an EXTREMELY simple program but for some reason when I enable iteration parallelism it takes annoyingly longer to complete. How do I do this properly?


There is nothing in your loop that can be efficiently parallelized and each parallel instances need to access the transfer buffer for the indicator and since access cannot be simultaneous, there is more contention. Most of your effort is spend in the UI thread formatting and updating the indicator. Nothing parallel about that.

 

There is really no point to parallelize unless each iteration does a significant amount of work. For very simple code, the parallelization overhead often exceeds any potential gain.

 

Parallelization is for computations and there should not be any controls or indicators inside the loop, ever.

 

For some introduction on benchmarking, have a look at our NI-Week presentation.

Message 4 of 7
(2,724 Views)

@xbaras wrote:

Hey, I'm very new to LabVIEW and I'm using it for a uni assignment where I'm demonstrating parallel performance. I've made an EXTREMELY simple program but for some reason when I enable iteration parallelism it takes annoyingly longer to complete. How do I do this properly?



Sorry, I can't open LabVIEW 2017.  However, I think you missed the point of the Assignment.  "Enable iteration parallelism" makes me think you are talking about a parallel For loop, but what I think the assignment really wants is for you to create two While loops, each with its own Stop button, possibly each with a "Pause" button, each "doing its own thing" (perhaps one counting at 1Hz, one counting at 2Hz), and then see what happens when you run the VI -- do the two While loops run independently of each other?  Can you pause one and let the other continue?  Can you stop one without stopping the other?

 

Bob Schor

 

P.S. -- I use parallel loops all the time, but I must confess I have (so far) never enabled parallelism on a For loop ...

0 Kudos
Message 5 of 7
(2,712 Views)

Iteration parallelism is a bit of an advanced concept.  If you're new to LabVIEW, are you sure that the exercise isn't intended to demonstrate loop parallelism?

 

The code you posted is attempting to update a front panel indicator in every iteration of the for loop, and with no wait time in the for loop, that loop is attempting to execute as fast as possible, consuming your CPU cycles.  There is no need to update a front panel indicator this quickly, because even an update rate of 10 Hz (100 ms loop period) "seems" instantly responsive to the user.  So, it makes sense to separate the counter function from the display function, and you can do this by using parallel loops.  In one loop, you simply increment the counter and store the latest value in a single element queue (with 0 timeout), and in the other loop, you read the value out of that queue and display it on the front panel indicator.  The second (read and display loop) need only execute at 100 ms loop period.  The first (increment counter and enqueue) can run as fast as possible, but you will still need to add some wait time to this loop so that your application will cede resources to the second loop and permit it to run.

0 Kudos
Message 6 of 7
(2,702 Views)

@CFER_STS wrote:

 

The code you posted is attempting to update a front panel indicator in every iteration of the for loop, ...


Not quite. All the loop does is update the transfer buffer of the indicator, the update of the front panel is asynchronous, done by the UI thread, and already much slower. (If you really want to slow down things, right-click the indicator and select "advanced...synchronous display". Now all indicator updates are actually carried out and things literally take forever :D)

0 Kudos
Message 7 of 7
(2,693 Views)