simd comparison operator?

Are there any plans that would allow using opEqual or opCmp operators with simd? My use case is that I have arrays, and I need to verify that ALL the elements in my array are comprised between two values (in this specific case 10 and 93). I was hoping I would be able to use: ubyte[] arr = ... if (arr []< 10 || arr[]> 93) throw Exception(); But that doesn't seem to work. Neither does simple opEqual comparison. //Make sure arr is initialized to 0 if (arr[] != 0) Is this a "never thought of this and not implemented" issue, or is there a reason that simd can't do this? I find it strange, since simd allows for straight up array to array opEquals, but not array to value? -------- Anybody have any idea as a workaround? My program has very high data throughput, and never actually handles the array elements individually, just manipulates them simd chunks at once. Validating the content is important, but performance is taking a real toll...

monarch_dodra: > is there a reason that simd can't do this? I find it strange, since simd allows for straight up array to array opEquals, but not array to value? SIMD instructions support those operations, so it's mostly a matter of designing a good semantics for D and implementing it. Bye, bearophile

On Tuesday, 19 February 2013 at 14:03:54 UTC, monarch_dodra wrote: > Are there any plans that would allow using opEqual or opCmp operators with simd? > > My use case is that I have arrays, and I need to verify that ALL the elements in my array are comprised between two values (in this specific case 10 and 93). > > I was hoping I would be able to use: > ubyte[] arr = ... > if (arr []< 10 || arr[]> 93) throw Exception(); > > But that doesn't seem to work. > > Neither does simple opEqual comparison. > //Make sure arr is initialized to 0 > if (arr[] != 0) > > Is this a "never thought of this and not implemented" issue, or is there a reason that simd can't do this? I find it strange, since simd allows for straight up array to array opEquals, but not array to value? Simd comparison generally doesn't return a bool, it returns a bool array, one per element. Does (arr[] < 10) mean "is every element in arr less than 10" OR "is any element of arr less than 10" OR "create a bool array which is true for each element which is less than 10" ? All make sense. That's the problem.

Don: > Simd comparison generally doesn't return a bool, it returns a bool array, > one per element. > > Does (arr[] < 10) mean "is every element in arr less than 10" OR "is any element of arr less than 10" OR "create a bool array which is true for each element which is less than 10" ? > > All make sense. That's the problem. Right, it's a design problem. I think the right thing to do is to take a look at what's an efficient operation to do in hardware (and then look at what's the most commonly useful operation for users). I think the right design here is to return a bool[N]. So in this case monarch_dodra has to add some more code to test all/any. Bye, bearophile

On Tuesday, 19 February 2013 at 16:03:58 UTC, bearophile wrote: > Don: > >> Simd comparison generally doesn't return a bool, it returns a bool array, >> one per element. >> >> Does (arr[] < 10) mean "is every element in arr less than 10" OR "is any element of arr less than 10" OR "create a bool array which is true for each element which is less than 10" ? >> >> All make sense. That's the problem. > > Right, it's a design problem. > I think the right thing to do is to take a look at what's an efficient operation to do in hardware (and then look at what's the most commonly useful operation for users). I think the right design here is to return a bool[N]. > So in this case monarch_dodra has to add some more code to test all/any. > > Bye, > bearophile There is significant opposition to any simd operators that allocate. The reasoning is that they appear fast but are in actual fact slow (for most normal size vectors, the allocation would be much slower than the calculation itself). I love the features of numpy and matlab etc. when it comes to array operations, many of which allocate implicitly, but Walter and others were quite adamant they they do not belong in D, a position I've come to agree with.

John Colvin: >> I think the right design here is to return a bool[N]. ... > There is significant opposition to any simd operators that allocate. The reasoning is that they appear fast but are in actual fact slow (for most normal size vectors, the allocation would be much slower than the calculation itself). > > I love the features of numpy and matlab etc. when it comes to array operations, many of which allocate implicitly, but Walter and others were quite adamant they they do not belong in D, a position I've come to agree with. Can't D allocate that bool[N] on the stack? Bye, bearophile

On Tuesday, 19 February 2013 at 16:46:36 UTC, bearophile wrote: > John Colvin: > >>> I think the right design here is to return a bool[N]. > ... >> There is significant opposition to any simd operators that allocate. The reasoning is that they appear fast but are in actual fact slow (for most normal size vectors, the allocation would be much slower than the calculation itself). >> >> I love the features of numpy and matlab etc. when it comes to array operations, many of which allocate implicitly, but Walter and others were quite adamant they they do not belong in D, a position I've come to agree with. > > Can't D allocate that bool[N] on the stack? > > Bye, > bearophile Perhaps it could, but it would be: a) quite counter-intuitive. An operation between two normal, heap allocated arrays generating a stack allocated array, with the scoping rules that entails? b) very easy to cause stack overflow in a way that would be totally confusing to someone who wasn't aware of the implementation.

John Colvin: > a) quite counter-intuitive. An operation between two normal, heap allocated arrays generating a stack allocated array, with the scoping rules that entails? Then maybe: bool[4] res = a > b; Bye, bearophile