pfft 0.1

[jerro]

> This all is very interesting. Even considering all potential 
> issues and incompatibilities, it might be great to look into 
> integrating Fft into Phobos. Do you think it would work to add 
> it as a "high-speed alternative with different format and 
> alignment requirements"? Offhand I'd think someone using the 
> FFT is generally interested in speed, and a 30% margin is 
> sensible since the algorithm might be most of some 
> applications' run time.

If we were integrating pfft into Phobos, it would be best to
replace the current implementation completely. Pfft already
includes an API that is Phobos compatible (it deinterleaves and
copies the input to an internal buffer and then interleaves the
result and copies it to the output buffer when it's done). This
interface is slower than the in place, split format interface,
but is still a lot faster than the current Phobos implementation
if SIMD operations are available. I guess it wouldn't hurt to
also add split format, in place functions which would require
aligned arrays for those who need every bit of performance.

>
> Do you think Phobos can be fixed in a backwards-compatible way 
> (e.g. provide a template and alias it to the old name)?

After thinking about it a bit I think that it would be best to
solve this using lazy initialization. Users probably don't care
that much whether the internal data is computed in the
or just before computing the first transform. That way the API
doesn't need to be changed.