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

[keller <christoph-keller@xxxxxx>]

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.


Greetings,
Christoph




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.
>
> gael
>
>
>
> On Sat, Aug 7, 2010 at 9:36 PM, keller<christoph-keller@xxxxxx>  wrote:
>    
> > Hello,
> >
> > 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
> > everyone.
> >
> > Thanks for all the time you invested in answering my questions.
> >
> > Greetings,
> > Christoph
> >
> > P.S. This is my first patch for an OS Project
> >
> >      
>
>