Re: [eigen] AVX/LRB and SSE with SoA support

[ Thread Index | Date Index | More Archives ]

Hello Gael,

One Problem with the boolean approach is the use of doubles. One would have to define a type of doubleBool which represents a 8 byte bitmask (In Computer Graphics this may not be needed, because only floats are used).

I think one should be able to enable the logical operators on floats and ints at least with a #define.

One needs to be able to store the masks. This is very important in my opinion and is pretty common. If one defines this type as bool, one may get in trouble. For example one part of the software has vectorisation disabled, stores the bool, and another one expects a mask.

Maybe changing the = operator for masks may help here, but it does cost time.

Also if you use 32-Bit integers it makes a difference if the masks are stored as floats or as ints, as transferring from the floating point unit to the integer unit takes 2 cycles.
(Or of integer masks in the floating point unit = big potential penealty).
Using types als intBool, floatBool helps, but it may complicate things.

Using the logical operators avoids all of these problems of course. One can still use functions like the select function without defining many special comparison types.

It is not important for upper things, but how do i change a function i add via plugin to array.h like
typedef Array<_Scalar, _Rows, 1, _Options, _MaxRows, 1> ArSoam;
EIGEN_STRONG_INLINE ArSoam soam(Array& ar) {
  ArSoam ret = ArSoam::Zero();
  for(int i=0; i < _Cols; i++) {
    ret += this->col(i)*ar.col(i);
  return ret;
to be able to work in arraybase, so that the function can use it with Map.


On 08/20/2010 12:28 PM, Gael Guennebaud wrote:
Hi Christoph,

thank you for the patch, and sorry for the delay.

Actually, I'm not sure what is the best to expose such features.  For
instance, bitwise operations for non integer types does not really
makes sense. They are only useful to perform very low level
vectorization optimizations. I would rather focus on improving the
vectorization of the higher level operations such that the user do not
have to explicitly deal with masks, etc. More precisely, I'm thinking
about the vectorization of the select mechanism:

result = (x>  0).select(a,b);

which means:

foreach i
   result_i = x_i>  0 ? a_i : b_i;

To alllow more aggressive optimization we should also add a way to
tell at compile time if a or b is either one or zero.

This should already cover 99% of the use case for bitwise operations
on non integral types. However this is not trivial since it affects
the return type of coeff-wise comparison operators which are currently
seen as an object of boolean. For vectorization purpose we should have
a way to request packets compatible with the scalar type of a and b.
Again, templating the *packet* function on the packet type seems to be
the way to go.


On Sat, Aug 7, 2010 at 9:36 PM, keller<christoph-keller@xxxxxx>  wrote:

The Patch is attached.

The contents of array.h of my previous post are not included, because i do
not know how to do this in an Eigen-consistent way, that is useful for

Thanks for all the time you invested in answering my questions.


P.S. This is my first patch for an OS Project

Mail converted by MHonArc 2.6.19+