Upgrade MKL FFT wrappers

[pfeatherstone]

Main idea

At some point, MKL changed the internals of the library such that computing the DFT descriptors become more heavyweight. It didn't used to be the case. Maybe it used to cache them internally and now that's up to the user to do so. Anyway, need to cache the descriptors now. I can submit a PR at some point.

Anything else?

No response

[pfeatherstone]

Though i don't know if DftiComputeBackward() and DftiComputeForward() are thread-safe when sharing descriptors (plans)

[pfeatherstone]

Mmh, you have to set DFTI_NUMBER_OF_USER_THREADS and you can't know for sure how many threads are going to share that descriptor. Maybe we have to stick to computing plans on the fly. It's really slow though now.

[pfeatherstone]

Yeah so on a forum it says:

The compute functions are thread-safe assuming not more than N threads are using the same descriptor, where N is the value you set with DFTI_NUMBER_OF_USER_THREADS

Ok, maybe we should leave it as is. Shame though. I've noticed that MKL is at least 10X slower than FFTW now when computing FFTs in a loop due to the plan creation stuff.

[pfeatherstone]

Problem goes away if i use thread_local instead of static for caching plans. Ok will submit a PR this weekend.

[davisking]

The compute functions are thread-safe assuming not more than N threads are using the same descriptor, where N is the value you set with DFTI_NUMBER_OF_USER_THREADS

That sounds fundamentally not threadsafe. E.g. I don't get how that isn't literally describing a race condition or even how it would be implemented for real. Maybe there is some array in the descriptor that's indexed by a thread ID and the ray is DFTI_NUMBER_OF_USER_THREADS long and once it fills up it just explodes?

In any case, that's all horrible design :(

But yeah, having thread_local descriptors seems like a totally fine way of dealing with this.

[pfeatherstone]

I also parallelise some of the unit tests to check thread safety.

[pfeatherstone]

#3101