| 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: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Tue, 19 May 2009 20:02:15 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bSMbyZEGS6iUlZGwrJbcJFztaoT2pggpot5+qHh2m4s=; b=NpBp4ejO5CuvEDkEoOvzJHChn2UTturdNcMGgGVbevCeHyBpoGvXHfZr34e9lYH+lh PwgcAWrOYT7edlI1zLDIXvtA7FIoVG8lUYfPyvwmTMQyVtmM3FoTrVhYNOwXsYaxI+5s 8uCkXu8hNPj3GEjF2wm1rBGoYyXQMPlOf5E/M=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=wvjxrWPsde5pmvGIJJu8BNq5VC57mcFJYbp9yUh0/7EvzUD2PO3bTjIYVvpNyJYlcX JcBkECrlC1YL+D5xF1YwpoeMo/ydGEkiX53q7MUL0soPOflaqEGodj0PZ4FxzI3d4jWd muHXKjYHXR72XLOb5gXmafasIU/WtHxc1OC9c=
On Tue, May 19, 2009 at 7:07 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> i'd be (pleasantly) surprised if this could be done without
> very big (not worth it) changes in Eigen....
definitely !
Anyway, I just wanted to add that such a storage scheme would also be
optimal to vectorize code dealing with many Vector3 or other non easy
to vectorize data types....
Gael.
> Benoit
>
> 2009/5/19 Rohit Garg <rpg.314@xxxxxxxxx>:
>> This is probably not a good idea. I believe that they should be stored
>> in the interleaved format. I'll be happy to pitch in with SSE2/3
>> intrinsics code for complex multiplication, division if neccessary. I
>> think we should go the standard way as many other libraries and
>> std::complex use it.
>>
>> So far, on this discussion, the only reason for not using the
>> interleaved format that I have seen is that it is tricky to multiply
>> using that. Is there any other reason?
>>
>> IMHO, we shouldn't lose compatibility with ~90% of other complex
>> libraries/formats just to simplify multiplication.
>>
>> On Tue, May 19, 2009 at 5:49 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> I can believe that this is probably a very efficient storage scheme.
>>> We could offer this as an option if really it's not too hard to
>>> implement (i didn't start thinking about this).
>>>
>>> The default should remain the current for many reasons, but as an
>>> option why not.
>>>
>>> Cheers,
>>> Benoit
>>>
>>>
>>> 2009/5/19 Márton Danóczy <marton78@xxxxxxxxx>:
>>>>> I concur: I don't think that it would be very useful to have complex
>>>>> matrices with the real and imaginary parts stored separately. Most
>>>>> operations -- and the more costly ones -- would run slower in such a
>>>>> scheme. The basic issue here is memory locality.
>>>>
>>>> What about storing them packet by packet? That is, in case of floats,
>>>> four real parts followed by four imaginary parts. That would not be
>>>> too hard to implement and vectorization of component-wise operations
>>>> would be trivial. And I think even FFTW can handle that using the guru
>>>> interface, by setting up a split fft plan with a stride of
>>>> 2*packetsize.
>>>>
>>>> Marton
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Rohit Garg
>>
>> http://rpg-314.blogspot.com/
>>
>> Senior Undergraduate
>> Department of Physics
>> Indian Institute of Technology
>> Bombay
>>
>>
>>
>
>
>