Re: [eigen] Map's and not Maps

["Keir Mierle" <mierle@xxxxxxxxx>]

On Mon, Dec 8, 2008 at 4:07 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:

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.

Since 2 and 3 are quite common operations it might be worth investigating if it's faster to do vectorized 4-ops where the last elements are ignored.

For example, for element wise multiply, pack the three elements into the 4-wide register, put a zero in the last register, then ignore the result in last element.

It's probably necessary to benchmark if such a hack is worthwhile.

Cheers,
Keir

 

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

---