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

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

2010/9/3 keller <christoph-keller@xxxxxx>:
> On 09/02/2010 10:56 AM, Gael Guennebaud wrote:
>>
>> On Wed, Sep 1, 2010 at 9:23 PM, keller<christoph-keller@xxxxxx>  wrote:
>>
>>>
>>> On 08/23/2010 08:53 PM, Gael Guennebaud wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> If one wants to use the Vector units of the processor and store masks for
>>> comparisons, the comparison operators cannot return values of type bool..
>>>
>>
>> The problem is that we cannot know in advance whether a comparison
>> should return bools or bitmasks. Also the nature of the bitmasks
>> depends on the underlying vectorization engine.
>> So the idea is to have powerful high level expressions such that there
>> is no need to expose special scalar types. For instance, in:
>>
>> c = (a<  b).select(x,y);
>>
>>
>
> Well, as is said before: I dont't think this is flexible enough

I, too, have concerns about the suitability of operators returning
bools wrt vectorization. One issue is that sizeof(bool) could be
anything so I don't really get how vectorization will work.

Already having sizeof(bool) < sizeof(Scalar) will require subtle
changes in our vectorization engine, and I still don't see how to make
that work without overhead. Then the case sizeof(bool) >
sizeof(Scalar), which could easily happen on compilers where
sizeof(bool)==4 once we have vectorization of small integers, seems
like it will be even worse.

So I see 3 possibilities:
 1. Gael makes me understand something I was missing above.
 2. We let operator< return a pseudo-bool type that is actually an
integer type of the same sizeof() as Scalar.  As Keller suggests, and
as had been discussed earlier with Rohit (IIRC).
 3. But I understand Gael's concern that it's not too good to let such
optimization details influence the return type of basic operators. So
perhaps keep operator< and friends unchanged, returning bool, and add
new methods with explicit names, like a.simdLess(b). The other nice
aspect of this approach is that there's no rush to do it now (Eigen
3.0 API freeze is near), it can start as a new separate module for
now, and if for some types that happens not to be convenient we'll
just not offer such a method, and the usual operator< will just keep
working as usual, unaffected by simd issues.

Benoit

>>
>> returns an expression of bool, not a matrix of bool, and so
>> vectorization is still possible. Then when we call select on it we can
>> known whether this whole expression can be vectorized. If so we would
>> generate something like:
>>
>> c(i) = ei_pselect(ei_plt(a(i),b(i)),x(i),y(i));
>>
>> where ei_pselect would be implemented in term of pand/pnotand,por for
>> SSE2 and 3, and using BLENDVP* with SSE4. Note that the BLENDVP*
>> instructions read only the first bit and are therefore much more
>> flexible.
>>
>>
>
> Ok, i did read the AVX-docs that careful. They have a select instruction,
> that is better than the or and and solution.
> Maybe it is possible to define a type
> EigenBool<type T, int VEC_ENGINE>
>
> The <=, < return an expression of this type. This type can be evaluated in
> two ways:
> -with sth. like toBool(), which returns a normal bool
> -with sth. like toVecBool(), which returns a mask in format VEC_ENGINE
> -these can be templatized with a function toEBool<EigenBoolType>
>
> This adresses the two problems you mentioned at the beginning. Basically the
> type itself does not need to know the way it will be evaluated. This has to
> be used to decide if to return a bitmask or a bool (different eval
> functions).
>
> -With this approach one can store the result of a comparison with each
> vectorisation engine. This is typesafe. Say one part of the Software uses
> SSE and the other does not, then the typesystem takes care of the Format of
> bools (at least it gives errors).
> -The systax can be like your select syntax
> -If one wants to store normal bool types with sth. like this
> Matrix<bool,...> = (a < b)
> maybe we can add a function toBool<EigenBoolType>() to the expressions of
> type bool. So they can basically be transformed to any other EigenBool type.
> Every boolean expression inherits these transformation functions from a base
> class.
> The operator= of Matrix <bool, ..., >, Matrix <EigenBool, ..., > use the
> toBool function to evaluate a boolean expression, so this would not break
> existing code.
> -Last, but not least: EigenBool<> types can be used with logical operators
> and the Vectorisation Engine.
>
> This just an idea, i dunno if it would work like this.
>
> Greetings,
> Christoph
>
>
>