LabVIEW
Can not configure for loop for parallelism
Haha, Ben. I think we have been through this before a while back.
The code itself is not actually crashing in the traditional sensee. No errors are being thrown, but when I try to configure for iteration parallelism, Labview dies with NO error (i.e. locks up and has to be shutdown using task manager). For your edification, I have attached the code with it's dependencies. The VI in question is called GetTauParams and the loop in question is the bottom loop which fits a number of exponential decays (a for loop nested in a for loop).
I am not sure which is the best loop to optimize; I can set the inner loop as parallel successfully but I am not achieving the performance boost I expect - execution times vary from those without explicit parallelism to something that is about 4 fold better on a controller with 4 CPUs (the variation is not acceptable as it causes overruns in a higher level loop that ultimately lead to laggy performance).
What this code is supposed to do:
The instrument that this program drives fires lasers at 1 kHz into eight high finesse cavities. Mirrors allow the light to bounce back in forth for a period time as the residual signal exponentially diminishes due to extinction by gasses and particles. We measure the 1000 exponential decays in the 8 different cells using an S-series card operating at 2.5 MS/s. The data (taken from a DAQmx read) is pumped into the class CRDObj (of which there are 8 representing the 8 cells) which is then queued up and sent to a processing loop which calls the VI GetTauParams. GetTauParams then determines a characteristic decay time (tau) for all 8000 decays. For each cell, the 1000 decays associated with the cells is then collapsed into a single set of numbers (fitting parameters). For a thousand point shot, the VI Get Tau is optimized such that, depending on the method, the parameters can be retrieved within 100 to 200 microseconds on a dual core machine. This translates to about 200 ms for 1000 fits. If all fits are conducted in series, this would translate to a total acquisition time of ~1.5 to 2 s, well above the 1 Hz that we are shooting for. However, if we can run reliably in parallel, then we should be able to reduce this by a factor of 4 on a quadcore processor and hit the times that we are shooting for.
That's a lot of background which probably doesn't matter, but I thought I might preempt some further questions and hopefully see if any of you had some ideas about optimization.
Peace, Matt (NOT mtat76
)
Hi Matt,
Sorry again, but there are far too many (unincluded) dependencies in this VI to make it useful for debugging. That said, I would not like another ZIP file with all the dependencies attached
If you could strip out all the dependencies and isolate the issue into the simplest VI you can manage. This will help us down the road if it is indeed a CAR-able issue. Thanks.
