Re: [eigen] A complex FFT for Eigen |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] A complex FFT for Eigen*From*: Christian Mayer <mail@xxxxxxxxxxxxxxxxx>*Date*: Tue, 02 Dec 2008 18:33:09 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding:sender; bh=bjX44ro+RC9AHulf4r1AHIs7yQIylGvsefQtPJ9p0RQ=; b=rVhvTYeI8kT/0lgq+WbymLAsP2/FQCwZ97zV1tVTUyDy56R5rn0OflYq0SUbU4cBjI UeA0XeOCo8LdMbZwT969nufjR6kJwhypGDZftjIIrggzJrrNs3BF71yy8LkfIreTAv28 Yt0/HkuZQNRPApV+icJQk7Ggmp2m9Y8efqtOU=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:sender; b=dPUPokDM9IG+9PXTAGq1U6tDE0TM5JXdMhwDrO3gLnaZMvALcvfZACOK6RhAsACyU+ s7pADF2K2e29R7jdmXrjzKCSB2GA5/2JvDjQ9VVxq22/PbV4biZEeVBseqZMCpQ7pjx+ N7KK0C6QBwi5l/C6usz2mfu9ZBxOfCb+nCqyU=

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Benoit Jacob schrieb: > Yes I agree, I too prefer the 1st solution: own specialization of > complex<double>. Actually I hadn't thought of that possibility. > > Unfortunately, at least here in gcc 4.3, <complex> does specialize > complex for float and double. Not just as an external, but the actual > specialization is in the header. Which prevents us from doing our own. Yes, <complex> is meant to be treated special by the compiler (most? any? aren't doing it "yet" though). It's a bit similar to the <array> module that's guaranteed to be unaliased... The newest C standard (C99 IIRC) is a bit clearer though. It comes with the complex and alias key words and doesn't rely on a "naming convention". > Moreover, comments refer to what seem to be sections in the C++ spec, > so this is probably standard. > > So at this point I want to say: OK so the c++ standard expects the std > lib implementors to fully take care of optimizing complex for float > and double, fine! So the next thing to do is to check the assembly > with some test program: enable SSE2 and check that the compiler really > produces vectorized code. An addition of complex<double> should be > vectorized for example. Looking at the <complex> header, there doesn't > seem to be any explicit vectorization, but perhaps they know that the > compiler does a good job here, or perhaps i don't understand what > these __real__, __imag__ pseudo keywords mean. > Apart from the <complex> STL lib, you could try the C keyword complex. It's not in the C++ Standard yet, but people are argumenting for it to keep the compatability between C and C++. Anyway most modern C++ compilers are supporting it... If it comes to our own implementation of complex numbers it might be an idea to seperate the real and imaginary parts, i.e. avoid to store them in the same SSE register. SSE was for a long time very bad at using "horizontal" comands, i.e. commands that use two parts of one register together - something that's needed for an complex multiplication. For an FFT I'm *guessing* that using a vector for all real parts and an other vector for the imaginary numbers can be faster. CU, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkk1cVQACgkQoWM1JLkHou05AwCgkk/SzEzoEJ02EQ6F2gxK3gJN MPgAnjfnuOmNkaNkTPlLQLpOyfVyXEFa =Rt8a -----END PGP SIGNATURE----- ---

**References**:**Re: [eigen] A complex FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] A complex FFT for Eigen***From:*Gael Guennebaud

**Re: [eigen] A complex FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] A complex FFT for Eigen***From:*Gael Guennebaud

**Re: [eigen] A complex FFT for Eigen***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] A complex FFT for Eigen** - Next by Date:
**[eigen] ei_pmul issues** - Previous by thread:
**Re: [eigen] A complex FFT for Eigen** - Next by thread:
**[eigen] ei_pmul issues**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |