>Naturally it would be interesting to provide optional native high-performance versions as well.
FFT should be one of the interface/factory algorithms. We should probably decide if we are going to go that route or not. So far you and I are in favor of it.
Patrick, Jurgen, and Max - What do you think?
>I noticed that MKL provides very well performing FFT routines, so I think in the MKL case we could/should use them. However, I guess the other native libraries do not provide any such >routines? Should we try to integrate FFTW3 (GPL!) instead in this
ACML does, but I think FFTW is the only vectorized open source library. We could offer a non-vectorized native version for the ATLAS/LAPACK/BOOST build.
This also shows a weakness of my current proposal - that is all native bundles (MKL, ACML,ATLAS/LAPACK/BOOST, CUDA/BOOST, etc.) have to provide exactly the same functionality. A previous propsal broke up the functionanlity (i.e. LinearAlgrebra, RandomeNumbers,
FFT, etc). That is much more flexible. We could even provide a FFTW FFT provider for those that were OK with the GPL.
If we broke things up, we could have the following native providers:
Drawbacks of course are more complex wrapping code and more native DLLs.
We should probably also decide on this relatively soon. Fixed bundles all providing the same functionality or a provider plug-in approach? dnA has tried both approaches, each had its own unique problems.
Thoughts? I'm not sure.