July 24, 2012 Re: pfft 0.1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | > 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. |
July 24, 2012 Re: pfft 0.1 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto |
> Nice work.
>
> Just did the usual advertising in HN and Reddit,
>
> http://news.ycombinator.com/item?id=4286257
>
> http://www.reddit.com/r/programming/comments/x2tt8/pfft_a_fast_fourier_transform_written_in_d/
>
> --
> Paulo
Thanks.
|
Copyright © 1999-2021 by the D Language Foundation