LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

iFFT is slow, if input is NaN

Solved!
Go to solution

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:

 

do not execute iFFT if NaNs.png

 

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,

Message 1 of 18
(4,218 Views)

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.

Message 2 of 18
(4,198 Views)

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.

0 Kudos
Message 3 of 18
(4,168 Views)
Well, I don't see how the algorithm should depend on the values. Seems unexpected to me. Are all math operations involving NaN slow?
0 Kudos
Message 4 of 18
(4,158 Views)

Is good point...

0 Kudos
Message 5 of 18
(4,142 Views)

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....

Message 6 of 18
(4,131 Views)

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%) Smiley LOL

 

0 Kudos
Message 7 of 18
(4,101 Views)

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.

Craig H. | CLA CTA CLED | Applications Engineer | NI Employee 2012-2023
0 Kudos
Message 8 of 18
(4,011 Views)

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 🐵

Message 9 of 18
(3,997 Views)

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!

Craig H. | CLA CTA CLED | Applications Engineer | NI Employee 2012-2023
Message 10 of 18
(3,956 Views)