Re: [eigen] Map's and not Maps |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Map's and not Maps
- From: "Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>
- Date: Mon, 8 Dec 2008 13:07:42 +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=ycPDbnIb2/a4MZteGIV/eSF0PGKjb96ZlL5GwGOTAaY=; b=ZS82l2Xn9Io7lZ0urP7CZqclWnBVZ7M5EiujUp0JTrOPvxtRovub5GCmJ2eTbuoK00 HiWCfrYtEAlpLNYyL3bW5fM2iW9MVjsI30XTvGtvQq7TqkwI/73ZibwJ5tKKQGYI0Zhc o9HvuP09tFNl+P7Z1LLrKXD+yuTaKUDROWl60=
- 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=r6V810pyTl8vMO3VNVYKg+M2HreBhi5wFhGmtdEqlNDC9eCLAHw90Uhi4avhb9HXo3 h4o23VDw0Vmv1zzwY/EnNHjge1dyyysj/vA71AZx0QR+FISoijqz8kC89A8xA3sN7Nv7 r6IKZpLticGaElGzrbZsrwb5fJJSNqP9Cq2so=
I think that Benjamin was only asking for it to be possible at all,
letting alone vectorization... hence your example,
> template<Derived>
> float SomeCoolFunction(MatrixBase<Derived>& v, void* somedata)
> {
> EIGEN_STATIC_ASSERT_VECTOR_SPECIFIC_SIZE(Derived,3);
> // ...
> }
is, as far as I understand, exactly what he is asking for.
Benjamin: Yes you can make a SomeCoolFunction that takes seamlessly
either a Vector3f or a Map<Vector3f>, that is done as above, actually
this construction occurs all over the place in Eigen.
Anyway there is no vectorization possible for Vector3f at all because
3*sizeof(float) == 12 <sizeof_a_packet == 16.
Cheers,
Benoit
2008/12/8 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>
> Hi,
>
> you guessed right, the major issue avoiding such a construction is owing to
> the alignment of the data. Indeed, the vectorization of some fixed size
> vector/matrix types assume that the data are correctly aligned. So, in a
> general, you cannot avoid to generate 2 versions of SomeCoolFunction, one
> with the vectorization and one without (see below).
>
> In the very specific cases where the vectorization is disabled and/or you
> know the vector type won't be vectorized by Eigen or you know the data are
> aligned, then you can still simply cast your pointer:
>
> float result = SomeCoolFunction(*reinterpret_cast<Vector3f*>(inputdata),
> bla);
>
> For instance, for Vector3f this is always ok because this type cannot be
> vectorized. (if we forget the use of reinterpret_cast which is not super
> clean)
>
>
> A much more general solution is to template SomeCoolFunction and use static
> assertions to check the input types, eg:
>
> template<Derived>
> float SomeCoolFunction(MatrixBase<Derived>& v, void* somedata)
> {
> EIGEN_STATIC_ASSERT_VECTOR_SPECIFIC_SIZE(Derived,3);
> // ...
> }
>
> The advantage of this approach is that you can take as input any vector
> expression like a sub vector of a matrix:
>
> SomeCoolFunction(mat33.col(1), bla);
>
> A drawback might be that the same code could be generated multiple time
> (though the compiler/linker are supposed to be able to factorize such
> redundancies automatically, but I don't really trust them for that).
>
> I agree that this solution is not optimal from a user perspective, but
> currently I cannot see any better solution to that issue.
>
> Cheers,
> Gael.
>
>
> On Mon, Dec 8, 2008 at 12:06 PM, Benjamin Schindler
> <bschindler@xxxxxxxxxxxxxxx> wrote:
>>
>> Hi
>>
>> There is currently one thing which I really don't like atm in eigen. For
>> ease, I use a lot of direct vector's. But all the data I get from outside is
>> in the form of pointers, so I have to use maps. One thing I would really
>> love to have is a way to be able to do the following:
>>
>> float SomeCoolFunction(Vector3f& v, void* somedata);
>> ...
>> Map<Vector3f> input(inputdata);
>> float result = SomeCoolFunction(input, bla);
>>
>> This is currently not possibel and I'm not sure what exactly is needed to
>> support this kind of stuff and in which way this would impact performance
>> (One can't assume alignment for example etc). But from a design perspective,
>> this would be just amazing :)
>>
>> Any comments?
>> Benjamin
>>
>> ---
>>
>
>
---