LabVIEW MathScript RT Module
FFT performance
Solved!
Hey, that's not even an order of magnitude. 😉 I would guess Mathscript makes slightly more internal data copies.
- How are you measuring the speed?
- What is your LabVIEW version? Mathscript received performance improvements with nearly every upgrade.
- Can you attach your actual benchmark code? (e.g. Are you looping 100x inside the same mathscript mode ar are you calling the mathscript node 100 times?)
- Make sure there is no constant folding for a fair comparison.
So, you want to compare FFT LabVIEW with FFT Mathscript (don't call it matlab on the indicators! ;)).
To compare raw FFT performance, you should eliminate all other operations, for example:
- don't include the graph update inside the frame, it might steal CPU cycles.
- the dynamic data conversion (you coerce waveform to dynamic, back to waveform, extract Y array). Dynamic data conversions are often expensve.
- Don't compare with the express VI, which is also slower because it carries more baggage. Use the plain FFT.
- Don't do scaling (to dB, trim, etc.).
- Don't use stacked sequences, they make the code clumsy. 😉
Here's a quick example how a better benchmark would look like that only compares FFT and not all the extra stuff. You will see that now LabVIEW is even faster. 😄
FYI, Constant folding is internal optimization where certain data is folded into constant (example) (details). While there is folding in the FOR loop, it's OK, because the FFT is not folded as it seems.
us09 wrote:Thanks for the reply. I use FFT or analysing of long time series sampled at high
rates + overlapping. So waiting 30 minutes or 150 minutes make a some difference
even it is not an entire order of magniltude.
Ah, now we are getting to the interesting part. As you can see, it would be best to use all lowlevel function and code in a way to keep things in-place as much as possible and re-use data buffers. Use plain arrays instead of complicated data types and keep track of dt and df elsewhere. Coding style alone will make a huge difference. Do you have more details on how your data is arranged? You'll be surprised how fast these things can go when done properly. 😄
Thanks a lot. This is very, very instructive.
But what about my original question 
? Now LabView is even faster and
MathScript evern slower. So what is the reason for this difference. I would expect
that MathScript and LabView use the same FFT core routines. But in this case the
wouldn't differer that much. Right?
Hmm... That means I must implement the Welch algorithm myself.
Just for checking how good the the build-in function is. I hoped I
could avoid this
A polymorphic VI is just a collection of similar VIs and the correct one is selected e.g. based on inputs (or polymorphic selector status). Once it is placed, the correct instance is used, whcih should be equally fast as a plain VI, after al, it now IS a plain VI. :D. The magic occurs during editing, not in run mode.
I am not familiar with your TSA:Welch. VI. Can you give the full path? Is this from a toolkit?
Of course everything else being equal, working on plain arrays is of typically fastest, but you can still get orders of magnitude difference between an poor and an excellent implementation.
