LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Enabling Loop Parallelism seems to take longer

Solved!
Go to solution
Highlighted

Hi guys,

 

I was benchmarking a VI to see how much time was saved by enabling loop parallelism. The loop just uses select and multiplication on an array of 2048 elements. To my surprise, enabling parallelism increased the execution time! Please see if you can re-create what I am seeing by changing the loop parallelism in the attached SubVI (Calc Central Wavelength.vi), and changing the number of parallel loops allowed. Then run Test Calc Central Wavelength.vi to see how long it takes. The more loops I allow, the longer it takes! Thank you for any insight.

 

capture.png



CLA // LabVIEW 2016 // BALUG // GCentral.org // Unofficial Forum Rules and Guidelines

www.gcentral.org
0 Kudos
Message 1 of 12
(1,906 Views)

What CPU are you running this with? Single core?

0 Kudos
Message 2 of 12
(1,889 Views)

Doing it without a loop is even faster, 3.8 seconds compared to 5.8 seconds.  Further refinements may be possible.

 

Lynn

0 Kudos
Message 3 of 12
(1,885 Views)

Can that code really be run in full parallel? Looks to me like the compiler basically has to perform the work sequentially since you are reliant on using the loop indicator and combining the results back in order via the tunnels. Given the number of iterations you are doing (thousands) it's liklely that the context switching over-head is being clearly exposed.

0 Kudos
Message 4 of 12
(1,879 Views)
Solution
Accepted by topic author Gregory

Parallelism requires some overhead in order to split and reassemble the data. etc.. If your loop code does not do much, the parallelism overhead is realtively large and can even slow you down.


LabVIEW Champion. It all comes together in GCentral GCentral
Message 5 of 12
(1,864 Views)

See if this is any faster. Smiley Very Happy

 

 

I would also use "interpolate array" to get the interpolated value at a fractional index. Modify as needed.


LabVIEW Champion. It all comes together in GCentral GCentral
0 Kudos
Message 6 of 12
(1,852 Views)

Thank you everyone for the suggestions.

 

Altenbach, yours did indeed run much faster. I started changing my function piece by piece to look like yours, running after every change to see which changes gave the best improvement (it seemed to be the usage of shift registers, which I am puzzled about). After all of the changes my function was still a factor of 2 slower, and I realized it was the "Enable Debugging" checkbox that was to blame. Thank you for your help,

 

Gregory



CLA // LabVIEW 2016 // BALUG // GCentral.org // Unofficial Forum Rules and Guidelines

www.gcentral.org
0 Kudos
Message 7 of 12
(1,759 Views)

Yes, debuging adds some overhead. Also make sure the subVI front panel is closed when testing. If performance is important, you should also try inlining the subVI (not tested).

 

One big difference between the code versions is that yours uses significantly more memory, creating a boolean array and two DBL arrays, all with the same size as the input array.

 

Mine operates in place and exclusively uses scalars that operate in place (shift registers). They only arrays are the inputs.

 

Sometimes array operations can be faster because they are more suitable for SSE instructions, but here creating all these extra huge data structures just to throw them away a nanosecond later seems pointless. My code has an extremely small memory footprint which is desirable even if there is no speed advantage. For extremely large inputs, your's will run out of memory much quicker because it requires contiguous free memory for all these arrays.

 

In any case, all code versions are probably fast enough, even on a tiny atom processor. What are your performance requirements?


LabVIEW Champion. It all comes together in GCentral GCentral
0 Kudos
Message 8 of 12
(1,751 Views)

Thank you, I will try to keep in mind these points about memory. There are no strict requirements, the VI Analyzer just told me that I had missed some opportunities to parallelize "for" loops, and I was surprised that enabling the parallelism slowed it down!



CLA // LabVIEW 2016 // BALUG // GCentral.org // Unofficial Forum Rules and Guidelines

www.gcentral.org
0 Kudos
Message 9 of 12
(1,742 Views)

A little late to the party, but something just piqued my attention in your post -

'Allow Debugging' enabled actually forces the loop to execute sequentially, as per LabView. Not sure if this tip was shown in your version, but i suspect this was another reason why parallelism was slower.

 

Sorry to have woken up a sleeping post.

 

Greetings,

D

 

 

Message 10 of 12
(905 Views)