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

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] AVX/LRB and SSE with SoA support*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Fri, 3 Sep 2010 07:50:43 -0400*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=p5aRE3kEyZFobrvbtT/XFDveEqMKrCk38aWqBzOgsJI=; b=aHjUDtV0FDSEb4FJACJdVlWTrMnH5NCTeKXQNAWBL0bFFfFhCwMZNir3zBUZuSrgSI SzdXr9D+Tw3Vt2sYtjNMuf2E7Cbh7bz7U+9P9cXCmW6BPw0dAR3xgDk8AFDs3Ab8wdrj WeFjGiGPE+n/G0ghH7PoHJl/BGaVIwC/YCZ7M=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=tuPMsPhRXQfGM1UKwUHU+WqsJLHszhr4RCJgKP30c/BwX8aI50tBsC2RqxduIrUU+u ywT2FVZ1yapwG12OS8yOzlTttU8BBdQqGlf+KtPFKMpBLYcRTeOyQCLPcPgF3Gn693Ol TdYVdnKS+gMrvR+70y0X1amWBIf5Ag8EzDuH8=

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 > > >

**Follow-Ups**:**Re: [eigen] AVX/LRB and SSE with SoA support***From:*Gael Guennebaud

**References**:**Re: [eigen] AVX/LRB and SSE with SoA support***From:*keller

**Re: [eigen] AVX/LRB and SSE with SoA support***From:*Gael Guennebaud

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Why no LU::solveInPlace()?** - Next by Date:
**Re: [eigen] Why no LU::solveInPlace()?** - Previous by thread:
**Re: [eigen] AVX/LRB and SSE with SoA support** - Next by thread:
**Re: [eigen] AVX/LRB and SSE with SoA support**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |