Re: [eigen] On std::complex<> default ctor |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] On std::complex<> default ctor
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 25 Jan 2011 07:58:56 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=OYaZvC8UuKtgcB261c1k/3mmCOtzI19X/A0UNZngwro=; b=SKi1Qj+AbQbuUjojcxEGYW2LJp6ex7S90Kw7WyuRTa8pFfyvMxyf+QH3drK7bSjzXu O7r1YVk6AH62+l8SMerVAvIGcpkaaxIQ55oZ6npQkkImaWGzWG7mjOe0yUrEh0n9jhb0 u9V8EIr4OU2iUCVUhR3mhnVGqMUq53AuiqTR0=
- 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; b=jk2Ln1mgiHxBq6hp0YkJSXcX5YJDE6/2HNO0rI+0mfQTtjw7ubaA9A43ImscGaAc2A huIbrn5D4TjldV1OnjY/BeZkaVUfqRuo3Ff5uEfQd0yQrJak2nGw3KvjYA9gjLssnVe+ g8gK2R5hmU87x31e6lQTLyOln1LRhpMg1NARM=
2011/1/19 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> Hi,
>
> on the forum a user is having some performance issue with a simple code as:
>
> MatrixXcd mat(30000,30000);
>
> which takes about 20secs because std::complex default ctor initialize
> the values to zero. (He has 256GB of memory !) Here this is of course
> an extreme case, but we are basically hitting a performance hit
> anytime we create matrices of complexes. This behavior is also not
> very consistent with our default ctor which is supposed not to
> initialize the coefficients. I see two approaches to overcome this
> issue and waste of time. The easiest way would be to explicitly add
> exceptions for complex<float> and complex<double> as follow:
>
> template<> inline std::complex<float>* aligned_new(size_t size)
> { return reinterpret_cast<T*>(aligned_malloc(sizeof(std::complex<float>)*size));
> }
>
> template<> inline std::complex<double>* aligned_new(size_t size)
> { return reinterpret_cast<T*>(aligned_malloc(sizeof(std::complex<double>)*size));
> }
>
> A more general approach would be to encode this information in the
> NumTraits struct via a RequireInitialization enum which would be false
> by default and could be enabled only for scalar types for which it is
> really necessary to call their default ctor. I'm strongly in favor for
> this second solution.
I'm in favor of the second solution too because it's really a property
of the scalar type, whether it needs to be default-initialized.
But I would default RequireInitialization to true, because it is
safest and users may easily use scalar types that require
initialization (bignums...) and because any sane scalar type which
doesn't require initialization should anyway have a default
constructor that does nothing, making this issue disappear.
Adding stuff to NumTraits seems OK to me, keep in mind that we can
handle defaults in GenericNumTraits so only people who need
non-default behavior would need to add any code.
Benoit
>
> gael
>
>
>