labview FFT speed vs. "calling a C++ .dll FF, matlab, etc"

[Azazel]

Hello all,

I would like your opinion in a processing speed question.  My application requires thousands of FFT's (1024 samples/FFT) in a continuous mode and I am currently using the built in Pwr Spectrum vi.  What are your opinions on the built in FFT?  I know there have been great strides in making this function faster over the last couple of labview releases, but for my application I require a FFT method that is a little faster.  Do any of you have experience with using external FFT .dll's or another technique (matlab, visual C, etc) that you feel optimizes this signal processing technique.  If so can you point me in the direction of the external FFT functions that are compatable with LV if they are public knowledge.  Thanks for your opinion

[altenbach]

---

@Azazel wrote:
... but for my application I require a FFT method that is a little faster. 

---

Then get a computer that is a "little faster" 🙂 A Pentium 4 is not a very good processor to begin with.

You should make sure that you don't allocate new memory for every transform. Where is the data coming from and at which rate, and where does the result need to go. (stream to disk, further processing, just update a realtime graph?)?

Seriously, the LabVIEW FFTs are very good, so I doubt you'll gain much of anything. If you have a lot of time, you might be able to get the fftw libraries to run in a call library node. I haven't tried this: http://www.fftw.org/

Sizes that are integer powers of two as in your case are most trivial and should be very fast in any case. Most of the improvements have been gained for arbitrary sized arrays.

[johnsold]

The FFT.vi is slightly faster than Power Spectrum.vi. I put together a quick test VI where I fed the same 1024 element array of random numbers to both VIs and ran the profiler. With 100000 iterations of an outer loop FFT.vi averaged 29 us and Power Spectrum.vi averaged 33 us. This was fairly consistent over repeated runs. The outputs were not connected during this test. Both VIs call a dll internally. I think I recall seeing a comment that NI had put considerable effort into optimizing the performance of such VIs in recent versions of LV.

Are you careful to reuse buffer allocations and similar things to optimize the performance of your program?

Lynn

[altenbach]

Yes, could you attach a simplified version of the algorithm you are using. There are a few flavors of "power spectrum" available.

For speed, you should stick with "pure" arrays (DBL, CDB) and stay away from fancy things like waveforms, dynamic data, express VIs, and such.

[Azazel]

Hello Lyn,

Can you post the vi. you created as I may not be reusing buffer allocations as my FFT vi is definetly taking longer than yours.  What vi. analyzing function did you use to get a timing accuracy of us?
Thanks for you help.

[johnsold]

Azazel,

Here it is. (LV82) For the timing I used the Profiler. It is at Tools >> Profile >> Performance and Memory. Turn on check boxes for Timing statistics and Timing details. Set Time unit to microseconds.

Profile Buffer Allocations is the next menu item. It will show little boxes on the diagram where memory is being allocated.

Lynn