| 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-----
---