From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Architectural Problem, Suggestions Please

Solved!
Go to solution

I have an architecture... It's not Quite OOP and It's not Quite QMH.
I have a OOP based processing module where I need to run 50 processes on large array sets (20kx2k) very fast. I'm running FFTs, tranposes, additions, normalisations and other functions from the MASM palette.
I need to run each of these functions numerous times per data set, then add the resulting data set to the result of the next data set for n counts (typically 15).
The input array size for each module can be different, (or even not exist, causing the module not to need to run).
I have an array of 50xClass data holding the data sets for processing.

 

When I run these through re-entrant clone processing modules (fully in parallel), depending on PC spec and setup, I can hit 100% CPU usage as I can't limit what gets run.

 

I've changed the architecture to run the array of class through 1 processing module and limit a number of parallel for loop executions based on Logical processors available...

however...
Data is streamed in for for processing, and with small array sets (2kx2k) the new method now takes twice as long as it did before for the same CPU usage. - which is madness. (I do have a good performance increase for larger data sets. but I need to handle both 😣)
I suspect this is due to the FOR loop delaying the start of processing for the next function until the first has been done on all data sets.

Any ideas how to resolve this please???

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 1 of 4
(1,670 Views)

Hard to tell without seeing some code, but if you use a parallel loop, I probably would use the plain processing tools, not the parallelized versions from the MASM toolkit.

 

Trying to use multiple cores for several sections that already run in parallel seems wrong.

Message 2 of 4
(1,604 Views)
Solution
Accepted by topic author James_W

Ahh Christian,
I thought I could rely on you for a good sensible response and some good advice.😃 (That was my thinking too)

On a "slow" PC (2.6GHz processor with 64 processors) I max out the CPU
on a fast PC I9 spec'd at 3.5G (running at 5G) with only 16 processors I run at around 5%.

Finally after getting really frustrated and going back to the drawing board this morning I found a solution.
Set MASM threads to 1 for Linear Algebra and 1 from Transpose, replace the standard 2D FFT with an MASM 2D FFT and i'm thread limited so the CPU usage plummets. - and strangely because the re-entrant VIs are not all fighting for threads now it executes faster....

Except on the i9 processor where I now get error code -20003 at the FFT module 😫 (This was fine and didn't the performance enhancement)
(I eventually tracked it down to the FFT module running 2D dbl FFT 50 [section] *10 [stacks] = 500 times per result set and clogging up the CPU.

Can't say I've worked with MASM before - picking up someone else's code so learning as I do so.

Any ideas why error -20003 on a faster CPU?
(No I haven't searched yet, it's been a long week already😴)

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 3 of 4
(1,581 Views)

😣Turns out the -20003 was valid and pointed to an error that otherwise would have gone undetected. CPU was not the issue, it was an attached development DAQ device. Has allowed us to identify that this only happens with particular F/W versions and needs to be checked against.

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 4 of 4
(1,400 Views)