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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi,

well, Eigen is a general purpose math library and so such "hacks" does
not match well with our objectives. We have to find a better solution.

Actually, the end of your email remind me that in my previous reply I
wanted to speak about our plugin mechanism. So what I wanted to say is
that you can already and easily use all the features of your patch
without having to patch Eigen itself. Then on the wiki we could have a
section where users could share their plugin.

So to answer your question about the use of the plugins, you have to
create a header file, e.g., myarraybaseaddons.h and put the following:

typedef Array<Scalar, RowsAtCompileTime, 1> ArSoam;

template<typename OtherDerived>
EIGEN_STRONG_INLINE ArSoam soam(ArrayBase<OtherDerived>& ar) {
  ArSoam ret = ArSoam::Zero();
  for(Index i=0; i < this->cols(); i++) {
    ret += this->col(i)*ar.col(i);
  }
  return ret;
}

then define EIGEN_ARRAYBASE_PLUGIN to myarraybaseaddons.h before
including any Eigen's header. For instance you can use the compiler
flags, use your project config.h file if you have one, or define your
own header file to include Eigen in your project doing the appropriate
#define before including Eigen/Core, well there are many solutions :)

See this page for more details:
http://eigen.tuxfamily.org/dox-devel/TopicCustomizingEigen.html#ExtendingMatrixBase,
but unlike what is mentioned there you can use plugins to extend most
of Eigen classes, not MatrixBase only!

gael

On Sat, Aug 21, 2010 at 9:14 AM, keller <christoph-keller@xxxxxx> wrote:
> 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
>>>
>>>
>>
>>
>
>
>
>