|Re: [eigen] two technical points: WithAlignedOperatorNew and std::complex casting|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] two technical points: WithAlignedOperatorNew and std::complex casting
- From: "Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>
- Date: Wed, 31 Dec 2008 18:19:22 +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:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Mzr7AsBBvnXPM5ZhP3MFM9kLjnUundfiGjeB5fmuUNk=; b=xFD3i+n/gPKk7h07mZ+WO6twlvAQSO9BoBDJzlnBCANxE6EWjoeaY3o1MFXJqWeYYK rPkejxp0CQ4QiKFJgw2CFmHL+5Eu89Uc49ghLDFsfmed57G63djznFXjbRRTn2uTyQBz QSnJDkaWZbZ5MoRQIHI6UNdw67SdPZbgFXP8g=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HbXJwd/RdCalinQVU2d6Du2n9I3AmXTC4O8o5P4z/cAbsl5A+6Qzu4Vv0rVw9rSBbN nX5H/R7LWcOMknD2KIjDMAvVLFF1PktyMcHPYWG8WUorZx7+dg5eCa9cMpZvPalNzw/v 5dpII5Rea8r21OWOqvCvzdtenSgqX7zJxpKx8=
On Wed, Dec 31, 2008 at 5:07 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2008/12/31 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> Perhaps I forgot to mention that in my mind, it is perfectly fine that
>> a lib/app compiled with vectorization don't have to be compatible with
>> a lib compiled with vectorization. It is just like many other GCC
>> options which break binary compatibility if both binaries are not
>> compiled with the same options.
> If it weren't possible to have vectorized and not-vectorized code
> compatible with one another, then we could comfort ourselves with this
> argument. Meanwhile, it happens to be possible, so we really want
> that! There are at least 2 good reasons to try hard:
> 1) an app could have a vectorized path and a non-vectorized path,
> choosing between them at runtime depending on the CPU capabilities
> (think 32bit x86). In that case one can imagine a situation where the
> core of the app is compiled without vectorization, creates a Eigen
> objects, passes it to the vectorized part.
> 2) Suppose that SomeBinaryLibrary deals with Eigen objects.
> SomeProgram uses SomeBinaryLibrary. If we don't guarantee
> compatibility between vec and non-vec, then either both or neither of
> SomeBinaryLibrary and SomeProgram must enable vectorization. If
> SomeBinaryLibrary and SomeProgram are built by disconnected groups of
> people then they might pull their hair for a long time before finding
> why SomeProgram keeps crashing!
ok ok, as I said, eventually I was ok for that change.
>> In spite of what I said, eventually I'm not against to enforce
>> alignment everywhere but your example motivate me to add a "NoAlign"
>> or "Compact" flag for the fourth template parameter of Matrix<> such
>> that it is possible to use eigen to create compact structure at the
>> cost of no vectorization. Usage example:
>> typedef Matrix<float,4,1,NoAlign> Vector4Nf;
>> typedef Matrix<float,4,4,RowMajor|NoAlign> RowMatrix4Nf;
>> Of course this complexify a bit the use of Eigen, but this seems to be
>> a very important feature to me (an example among many others: to
>> create structures compatible with nvidia CUDA compiler)
> Good idea, I see the point. Something to investigate: instead of a new
> flag, maybe just forcibly unset the PacketAccessBit at the moment of
> computing the matrix flags. So hereafter we don't need to mess with
> one more flag.
yes, my idea was simply to add another enum (eg, since RowMajor==2, it
could be equal to 2) which would be valid only for the 4th template
parameter of Matrix, and then we test the presence of this bit to add
or not the AlignedBit flag in ei_compute_matrix_flag ....