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

One possible workaround is to use simd operation eplicitly. I've played around a bit with this and came up with this:

https://gist.github.com/jerro/4988229

This currently only works with GDC and LDC (but it probably could be made to work with DMD too). It uses std.simd (not in phobos yet) from here:

https://github.com/TurkeyMan/phobos

On Tuesday, 19 February 2013 at 17:58:14 UTC, John Colvin wrote:
> On Tuesday, 19 February 2013 at 17:46:56 UTC, bearophile wrote:
>> 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
>
> Yes, but it's quite restrictive to force it to be declared at the same place as it's assigned, if that's what you're implying.
>
> Essentially what's needed in order to allow all this and other simd operations that don't work in-place on the main operands is a guarantee that the memory has been pre-allocated. Then it really doesn't matter whether it's stack or heap.

Hum... so long story short, it is doable, but because the result of "[]<" is ambiguous, it is not built into the language.


Gonna play around with core.simd then!

> One possible workaround is to use simd operation eplicitly. I've played around a bit with this and came up with this:
>
> https://gist.github.com/jerro/4988229
>
> This currently only works with GDC and LDC (but it probably could be made to work with DMD too).

I've update the gist now so that it works with DMD too. To use it with
DMD, you'll need this branch from my fork of std.simd:

https://github.com/jerro/phobos/tree/simd-wip

Am Tue, 19 Feb 2013 18:51:35 +0100
schrieb "tn" <no@email.com>:

> In many cases it would be nice, if "arr[] < x" translated to "map!(a => a < x)(arr)" and similarly "arr1[] < arr2[]" translated to "map!((a, b) => a < b)(arr1, arr2)" or equivalent (*).

This would make the compiler depend on std.algorithm !

-- 
Marco

On 20 February 2013 02:03, bearophile <bearophileHUGS@lycos.com> 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
>

Don is on the money.

I drafted: bool allEqual(a,b)/anyEqual(a,b) and friends in std.simd, but I
haven't written them yet (been awol for a while). They're actually quite
tricky to get right+fast in a portable way.

all/any comparisons are often used in a boolean way, but they may not be
super fast on some architectures. If you want to do component-wise logic,
the typical approach is to use component-wise selection, eg:
  uint4 mask = compareGreater(a, b); // <- build a bit mask of 0's (false)
or 1's (true) where components of a are greater than b.
  auto result = select(mask, c, d); // <- select components from c or d
according to the bit mask.

Manu:

> If you want to do component-wise logic,
> the typical approach is to use component-wise selection, eg:
>   uint4 mask = compareGreater(a, b); // <- build a bit mask of 0's (false)

Isn't something like this better?

uint4 mask = a > b;

Bye,
bearophile

I don't think opCmp can fit that model?

But aside from that, I think that's misleading, and suggests to the user
that it's a trivial operation.
Additionally, it's not necessarily even possible in a portable way.

I also think most users would expect that comparison operators produce a
boolean result.
They'll be surprised when: if(a > b) produces an error.


On 3 March 2013 23:39, bearophile <bearophileHUGS@lycos.com> wrote:

> Manu:
>
>
>  If you want to do component-wise logic,
>> the typical approach is to use component-wise selection, eg:
>>   uint4 mask = compareGreater(a, b); // <- build a bit mask of 0's (false)
>>
>
> Isn't something like this better?
>
> uint4 mask = a > b;
>
> Bye,
> bearophile
>