use mklfft if available

[agramfort]

we use fftpack from scipy but anaconda offers mklfft in accelerate package. If present we should be using:

import numpy.fft.fftpack

see

https://store.continuum.io/cshop/accelerate/
https://github.com/ContinuumIO/mkl-optimizations-benchmarks/blob/master/benchFFT.py

@mainakjas it should speed up the TFR code you played with last week.

any taker?

[larsoner]

Are TFRs used a lot by you folks? I could possibly look into making a CUDA version at some point if they are.

[mainakjas]

Not still sure what was the reason for the slow code yet. Hopefully, I'll get to it later in the evening today. I think I'll be using TFR quite a bit :) maybe @agramfort can comment more

[agramfort]

yeah it's quite used by folks around me (in Neurospin mainly). @joewalter it would help too in the stft code to speed up tf-mxne code.

[larsoner]

Looks like the transfer overhead for resulting np.complex128 data of size (n_windows, n_times) cancels out the performance improvement of doing the DPSS taper window multiplication plus FFT on the GPU. The only way I could see to speed it up would be for cases where the PSD for a set of data is calculated with adaptive=False (since the weights could be sent to the GPU and the resulting PSD calculated there), and probably not at all for TF-MxNE. It would probably speed that case up quite a bit, 2-10x would be my guess. It doesn't seem like the additional code complexity that this would require is worth it, though :(

I could also look into whether CUDA would be useful for the CWT code if that would be useful.

[agramfort]

thanks for looking into this and the feedback. Let us know if you make any progress.

[larsoner]

Do we need the use_fft parameter in our CWT functions? I have had people get confused about what it meant, and it seems like it should be faster in most cases.

[agramfort]

when I wrote it I benched and there was not clear winner between the two... but that was a long time ago...