Optimization problem - order of operations

[mwebster]

I'm scratching my head a bit trying to figure out why one of these two ways of doing something is ~5 times slower than the other.

I'm generating a command curve: an array of angles for a motor. I'm translating these to 2 of the 3 motor phases for output to a motor driver. I then take each of these phases and pass it through a zero-order hold and a low-pass filter.

If, instead, I zero-order hold and low pass filter the command and then translate that into the angles, it's about 5 times faster. Now I'd be happy to just leave it at that, but there are some artifacts if I do it this way near the trigonometric asymptotes (causes short duration spikes where it shouldn't). I know that I'm calling ZOH and the LPFilter twice as often the first way, but I can't understand why it's 4-5 times slower instead of twice as slow. Even more puzzling is if I turn the filter off (give it an input <= 0) and on in prefilter mode, it only adds about 50% overhead vs 400% when post-filtering.

Anyone got any bright ideas or have I just made some stupid wiring mistake?

The attached VI's are LV2010 and require the mathscript module to be installed to run (actually, you could get past that requirement by opening the Command to DAQ output tester, removing the Generate command curve VI, and replace it with an initialized array of, say 20000 doubles, the behavior is the same)

FilterSineOrSineFilter.zip

[Jon Kokott]

I'm scratching my head a bit trying to figure out why one of these two ways of doing something is ~5 times slower than the other.

I'm generating a command curve: an array of angles for a motor. I'm translating these to 2 of the 3 motor phases for output to a motor driver. I then take each of these phases and pass it through a zero-order hold and a low-pass filter.

If, instead, I zero-order hold and low pass filter the command and then translate that into the angles, it's about 5 times faster. Now I'd be happy to just leave it at that, but there are some artifacts if I do it this way near the trigonometric asymptotes (causes short duration spikes where it shouldn't). I know that I'm calling ZOH and the LPFilter twice as often the first way, but I can't understand why it's 4-5 times slower instead of twice as slow. Even more puzzling is if I turn the filter off (give it an input <= 0) and on in prefilter mode, it only adds about 50% overhead vs 400% when post-filtering.

Anyone got any bright ideas or have I just made some stupid wiring mistake?

The attached VI's are LV2010 and require the mathscript module to be installed to run (actually, you could get past that requirement by opening the Command to DAQ output tester, removing the Generate command curve VI, and replace it with an initialized array of, say 20000 doubles, the behavior is the same)

The two processes which you have executing in parallel (both inside case structures) are causing alot of thread swamping (thats my guess anyway.)

Force those operations to occur serially (only one at a time.) and you get your expected processing increase in time.

I'd be interested if building the VI into an executable helped the situation at all.

~Jon

[mwebster]

That was it. Separating those into their own loops (even with the added overhead of reindexing the arrays) brought the execution time to ~2x vs 4-5x.

It's funny though, even when allowing those new loops to execute in parallel instead of serially, the improved performance is still there. I guess it goes and executes a few hundred loops of one, then yields to the other resulting in a lot fewer thread swaps.

So, for an array of ~20k elements,

prefiltering = 110ms, old post-filtering = 440ms, and new post-filtering = 235ms

Built into EXE:

prefiltering = 98ms, old post-filtering = 220ms, new post-filtering = 215ms

That's pretty interesting that the built method yielded that much optimization.

Thanks for your help,

Mike