Re: [eigen] Patch for quaternion normalization and cross product for Vector4f

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

2009/3/11 Rohit Garg <rpg.314@xxxxxxxxx>:
>> yes that's true that AoS is more convenient, and I agree it might be
>> handy to have an optimized cross3. Honestly, when dealing with such
>> small vectors, if your code includes many dot/cross products,
>> normalizations, etc... then I doubt the speed up could be above x1.5.
>> Significant speedup can only come from a more high level
>> reorganization of your algorithm, and using complex memory layouts...
>
> Yes, but the problem is that many api's (like opengl for instance)
> like AoS input form. And 1.5x is any day better than 1x. :) And we
> _do_ have vectorized dot's, add, mul, normalize, subtract etc. for
> small vectors in eigen, don't we?

For fixed-size vectors, we have vectorization only if we can have it
without runtime overhead, which is only if we can align the array
without wasting memory, which is only if the size is a multiple of 16
bytes. So Vector4f yes, but Vector3f no.

For dynamic sizes (typically larger), we have vectorization regardless
of the size.

>
> Bottom line, what is the reason for such a function not being part of
> the eigen's api when almost all the family of vector ops is? After
> all, it only improves speed. :/ And it's an opt-in feature, not an
> opt-out one.

About the cross product:
I can't make myself a strong opinion either way. I was concerned of
maintainance and porting to other archs, but it seems to factor well
through our wrappers. My main concern now is that it's going to be
little used. On the other hand, it could be the first of a collection
of functions working on 3d vectors stored as 4d vectors for
vectorization; I would be OK to start a new subdirectory of
unsupported/ containing such functions. After all there is a demand
for such functions, but they fit poorly with the rest of Eigen (until
perhaps we find a better API -- one possibility might be to have a
variant of the Matrix class itself doing storage differently and
reimplementing these methods) and put a much bigger burden of the user
to take care of low-level aspects, but in unsupported/ that's ok.

Your patch also contains a vectorized quaternion product. That would
be extremely useful, I wonder why you dont mention it in your email?
Do you consider it unfinished? I may also be out of date if Gael
vectorized it already since the last time I checked.....

Cheers,
Benoit

>
>> Regarding Bullet SDK, actually only some specific parts of the SDK are
>> vectorized by hand (using directly inline assembly and/or using
>> directly intrinsics) and there the base classes (matrix, vector) are
>> not vectorized at all.
>>
>> cheers,
>> Gael.
>>
>>
>>
>
>
>
> --
> Rohit Garg
>
> http://rpg-314.blogspot.com/
>
> Senior Undergraduate
> Department of Physics
> Indian Institute of Technology
> Bombay
>
>
>