Re: [eigen] Map's and not Maps

["Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>]

I already thought a bit about this.

This won't ever become a default option, because of the big waste of
memory that it incurs.

I then thought of having a separate flag for vectors i.e. a separate
type, switching to this behavior. That would be used for temporary
vectors, while storage vectors would be optimized for memory usage.
But I found that was a bad idea: if the storage vectors aren't
aligned, then any operation involving them can't be vectorized.

So the only way that this could ever bring a real benefit is if we
switch entirely to align all vectors. Big waste of memory. Could still
be a fun compile-time non-default option to play with.

No need to initialize the remaining coefficients to zero. On the other
hand, the nontrivial aspect in implementing this is that it can't be
done for all operations. It's not just a matter of saying that
3-vectors are systematically handled as 4-vectors in calculations,
because it only applies to certain calculations.

For that reason, this seems a little bit tricky to implement...
Cheers,
Benoit


2008/12/8 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
>> >>
>> >> ---
>> >>
>> >
>> >
>>
>> ---
>>
>
>

---