Hopefully these are mature enough to be generally useful. I would appreciate any comments regarding the interface. The FFTW API is not particularly nice for building a pure interface on. Some of the transforms could be made slightly faster at the expense of a much nastier interface, but unless someone needs the extra few percent, or is pushing the memory limits on their machine, I'm not inclined to expose the underlying nastiness. * carray A C-compatible array library. Provides both an immutable and mutable (in the IO monad) interface. Includes utilities for multi-dimensional arrays, slicing and norms. Memory is 16-byte aligned by default to enable use of SIMD instructions. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/carray * fft Bindings to the FFTW library. Provides high performance discrete fourier transforms in arbitrary dimensions. Include transforms of complex data, real data, and real to real transforms. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fft Jed
jed:
Hopefully these are mature enough to be generally useful. I would appreciate any comments regarding the interface. The FFTW API is not particularly nice for building a pure interface on. Some of the transforms could be made slightly faster at the expense of a much nastier interface, but unless someone needs the extra few percent, or is pushing the memory limits on their machine, I'm not inclined to expose the underlying nastiness.
* carray A C-compatible array library. Provides both an immutable and mutable (in the IO monad) interface. Includes utilities for multi-dimensional arrays, slicing and norms. Memory is 16-byte aligned by default to enable use of SIMD instructions.
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/carray
* fft Bindings to the FFTW library. Provides high performance discrete fourier transforms in arbitrary dimensions. Include transforms of complex data, real data, and real to real transforms.
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fft
Jed
Excellent work! These fill a key niche. Thanks for contributing! -- Don
On Thu, 14 Feb 2008, Jed Brown wrote:
Hopefully these are mature enough to be generally useful. I would appreciate any comments regarding the interface. The FFTW API is not particularly nice for building a pure interface on.
because FFTW stores global data (called 'plan's)
Some of the transforms could be made slightly faster at the expense of a much nastier interface, but unless someone needs the extra few percent, or is pushing the memory limits on their machine, I'm not inclined to expose the underlying nastiness.
I want to mention once again that there is already a Fast Fourier transform for arbitrary length that is coded entirely in Haskell. http://hackage.haskell.org/packages/archive/dsp/0.2/doc/html/Numeric-Transfo...
On 15 Feb 2008, lemming@henning-thielemann.de wrote: On Thu, 14 Feb 2008, Jed Brown wrote:
Hopefully these are mature enough to be generally useful. I would appreciate any comments regarding the interface. The FFTW API is not particularly nice for building a pure interface on.
because FFTW stores global data (called 'plan's)
Yes. In the Haskell interface, the existence of these plans is hidden From the user. In the advanced interface, you can influence the quality of the plan which may effect how long a transform takes to compute, but it will not effect the result. If FFTW added the ability to query the plan cache, or if we kept a mirror Haskell-side, then we could make better use of memory which would improve performance. Fortunately, we have a really fast malloc.
Some of the transforms could be made slightly faster at the expense of a much nastier interface, but unless someone needs the extra few percent, or is pushing the memory limits on their machine, I'm not inclined to expose the underlying nastiness.
I want to mention once again that there is already a Fast Fourier transform for arbitrary length that is coded entirely in Haskell. http://hackage.haskell.org/packages/archive/dsp/0.2/doc/html/Numeric-Transfo...
Indeed, this package does exist, but it is lacking compared to FFTW with regard to multi-dimensional transforms, real to real transforms, and performance (particularly for large sizes). The transforms in the dsp package are only a few times slower than FFTW for small sizes, but it quickly becomes orders of magnitude slower, especially when the size is not a power of two. It also uses several times more memory, due in part to always using boxed arrays. Modifying dsp to allow use of unboxed arrays would be nice. Jed
On Fri, 15 Feb 2008, Jed Brown wrote:
On 15 Feb 2008, lemming@henning-thielemann.de wrote:
On Thu, 14 Feb 2008, Jed Brown wrote:
Hopefully these are mature enough to be generally useful. I would appreciate any comments regarding the interface. The FFTW API is not particularly nice for building a pure interface on.
because FFTW stores global data (called 'plan's)
Yes. In the Haskell interface, the existence of these plans is hidden From the user.
With locks for threaded use?
On 15 Feb 2008, lemming@henning-thielemann.de wrote:
On Fri, 15 Feb 2008, Jed Brown wrote:
On 15 Feb 2008, lemming@henning-thielemann.de wrote:
On Thu, 14 Feb 2008, Jed Brown wrote:
Hopefully these are mature enough to be generally useful. I would appreciate any comments regarding the interface. The FFTW API is not particularly nice for building a pure interface on.
because FFTW stores global data (called 'plan's)
Yes. In the Haskell interface, the existence of these plans is hidden From the user.
With locks for threaded use?
In FFTW, planning is not thread-safe, but execution of plans is. The Haskell library takes a lock during planning, but releases it before execution. Planning can be time-consuming if you want a high quality plan, and unfortunately this phase is single threaded. It would be nice if FFTW would expose slightly more of its internal interface, or take its own lock when modifying it's cache so that planning would be thread-safe. Once a plan for your transform size is created (or imported through the wisdom interface) the call to the planner will return immediately and everything else can run in parallel. In the Haskell interface, the default planner is 'estimate' which just employs heuristics rather than actually computing some transforms. If you have imported the correct wisdom, this will still do an optimized transform. If not, it will be less than optimal, but there will be no time-consuming planning phase. If you are concerned about getting the absolute best performance, you can use the advanced interface (which still hides locking, memory allocation, and internals of multi-dimensional transforms) for more control over planning. Jed
participants (3)
-
Don Stewart -
Henning Thielemann -
Jed Brown