iFFT is slow, if input is NaN

[ghighuphu]

Dear users,

I am posting an answer to a question, which bothered me for some time. I was working out, why a certain part of my program runs slowly. Well, the answer was that the slow part performed an inverse FFT (Fast Fourier Transform) on an input, which was an array of NaN. If iFFT receives an array of NaN, it takes orders of magnitude longer to process the data. On my array of 7601 cells, the ratio of execution time was 0.1ms (using meaningful) to 120ms (using NaN data) in average. I corrected the code with a case structure as follows:

I am posting this fact and the issue, because I was suprised very much about this behaviour. I know, many functions can easily and quickly process NaN data. But iFFT.

Cheers,

[altenbach]

Very interesting. I see the same thing. looks like a bug. I also see the same thing for the forward FFT transform.

(for a 100k array, a NaN array is about 50x slower here)

I made an entry in the monthly bug thread.

[ToeCutter]

I'm tempted to say... does it matter? I don't care if it's a little slow in an 'error' case when you send it an invalid input. Better that than it checks every element for a NaN thereby slowing up valid outputs.

[altenbach]

Well, I don't see how the algorithm should depend on the values. Seems unexpected to me. Are all math operations involving NaN slow?

[ToeCutter]

Is good point...

[altenbach]

Doing some search, it might be a more general problem. See e.g. this matlab discussion (and the link in the first answer).

Might be interesting to test in LabVIEW 64bit....

[ghighuphu]

Thank you, altenbach, for your research! I just got it, why Windows is able to hang (do nothing visually) and use the processor at full power (98%)

[Craig_]

I'm seeing a 170 to 250x performance difference depending on what system I run it on (Perhaps CPU specific?).

Anyway, I've filed this to R&D under CAR 471675. I've attached the VI I used to replicate for reference.

[altenbach]

Craig, similar to the matlab discussion mentioned earlier, LabVIEW shows the same difference between 32 and 64bit versions. One of the responses seems to hint at some sse issues).

LabVIEW 2013(SP1) 32bit: 220x slower for NaN

LabVIEW 2013(SP1) 64bit: Same speed for NaN!!!!

(And yes, the 64bit version is quite a bit faster overall for good data... 10.5µs vs 13.5µs on my machine)

Does the FFT use the Intel MKL? (maybe we can blame Intel 🐵

[Craig_]

I see the same behavior between versions:

• 2012 SP1 32-bit: NaN Slow
• 2012 SP1 64-bit: NaN same speed
• 2013 SP1 32-bit: NAN slow
• 2013 SP1 64-bit: NaN same speed

I'll update the CAR notes to mention this as possibly the culprit.

Thanks!