Re: [eigen] FFT for Eigen |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] FFT for Eigen
- From: Ricard Marxer Piñón <email@xxxxxxxxxxxxxxxx>
- Date: Mon, 18 May 2009 17:44:18 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=gXNeMauZv7/0mhGjbmxbN9HxTIvVuKWrfgv+uicg0Fo=; b=HlYePo4lzuoj21doiNHn8GXuSQGbR7EyWbnQr9d4CiHglZ0uCXoauevsvhvIcsRQ04 C7ECOyu91sjMxhBSzV5yI42U9ZCdFiQLYOHDFEomvp4Yk43DJn89IWArHWQzELgjBnIm yiDgXfuZ6UZS8vd0FEmkKP2ly2KvvBPlJUV7A=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=N2Z81oSMvCWukDIL6UZVGy7cOWb6dEWkzX0WfvxmaCaFV4026TZrRdCMB4tBEqYaTl rB6Kf6Zl7IZQQdvVA0cS8KMtVffz87JbY5q8wCiS7li95p9270N1X6sGq6u56Vzf7vQx VMXA5gGJOn6k0MMDAVIWO8qThb9nUOoT7fA6g=
I have been using fftw as well [1], and by doing so I also end up
copying the data, which is a pity, so I would also very much
appreciate such a module.
There are several tricky points I have been bumping into:
1- If I recall correctly, when creating a plan, you pass it two
pointers (or optionally when done inplace, only one) that have been
allocated by fftw. This way fftw assures they are aligned, etc.
Maybe there is lower level API fftw which might let you apply plans to
pointers you have allocated on your own, otherwise, I don't know how a
copy could be avoided.
2- The complex type matrices in Eigen are still somewhat basic. I
think they are just a Matrix with data type std::complex (real and
imaginary components are interleaved). Which for some use cases is
not great. For example if I am going to do a lot of vector operations
with the real and imaginary part separately, these operations cannot
be easily vectorized (correct me if I'm wrong). On the other hand it
is true that this storage might be the one used by most external
libraries.
It has been already a long time since I told Benoit I would write a
wiki page for this discussion, but still haven't. Sorry for that.
[1] Here you can find the way I'm currently using FFTW in case it can
help (I'm no C++ pro, you have been warned :) ):
http://github.com/rikrd/loudia/blob/1d8a766c8c171f1e6b02502854fca3362d66aa6d/src/FFT.h
http://github.com/rikrd/loudia/blob/1d8a766c8c171f1e6b02502854fca3362d66aa6d/src/FFT.cpp
ricard
On Mon, May 18, 2009 at 4:56 PM, Thomas Capricelli
<orzel@xxxxxxxxxxxxxxx> wrote:
>
>
> I agree that fftw is kind of a strandard, it handles every sizes (not only
> power of 2) and every dimension (not only 1D or 2D FFT).
> I use it on some projects and i'm very happy with it.
>
> Though of course, the current situation if you want to use both eigen and fftw
> is to convert data back & forth between libraries. This is especially not
> great as complex numbers are involved.
>
> I would enjoy a fft in eigen, and in an ideal world that would use fftw in the
> backend.
>
> The way fftw works is the following : you create a "plan" (describing
> dimensions, sizes, type and so on), and you use the plan on data. The idea of
> course is that you create the plan once and use it several times. I am not
> sure if this is good or bad wrt to the use of fftw in eigen. Just wanted to
> mention it.
>
> greatings;
> Thomas
>
>
> In data lunedì 18 maggio 2009 16:34:47, Benoit Jacob ha scritto:
>> Many people who need a linear algebra library, also need a FFT
>> library. In that case, if both libraries use the same data types
>> (read: if they both talk in terms of Eigen:: objects like vectors)
>> then it's extra convenient. They can also share infrastructure for
>> handling various numeric types, for handling fixed-size/dynamic-size
>> with a consistent API... Eigen has all that and so it makes sense to
>> add a small FFT module that integrates well with that. Then, I think
>> that Mark was very clear that FFTW is "much faster", and that's why I
>> think we all agree that a must-have feature is that such optimized
>> libraries may be used as optional backends. The idea is to enjoy their
>> performance while using a uniform Eigen API. Also Mark notes that
>> kissFFT provides more flexibility wrt custom datatypes (like
>> fixed-point).
>>
>> Cheers,
>> Benoit
>>
>> 2009/5/18 Robert Lupton the Good <rhl@xxxxxxxxxxxxxxxxxxx>:
>> > I'm not quite sure why eigen needs an FFT library,
>> > especially when there's a standard (C) library
>> > that everyone uses, FFTW?
>> >
>> > Now, I can see the advantages of a pure-template
>> > C++ library if it's competitive computationally,
>> > so the question that I'd ask is, how do the
>> > kissfft benchmarks look relative to FFTW?
>> >
>> >
>> > R
>
> --
> Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>
> http://www.freehackers.org/thomas
>
>
>
--
ricard
http://www.ricardmarxer.com
http://www.caligraft.com