On 25 October 2012 02:18, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 25 October 2012 00:16, Manu <turkeyman@gmail.com> wrote:
> > On 25 October 2012 02:01, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >>
> >> On 24 October 2012 23:46, Manu <turkeyman@gmail.com> wrote:
> >>
> >> > Let's consider your example above for instance, I would rewrite (given
> >> > existing syntax):
> >> >
> >> > // vector length of context = 1; current_mask = T
> >> > int4 v = [0,3,4,1];
> >> > int4 w = 3; // [3,3,3,3] via broadcast
> >> > uint4 m = maskLess(v, w); // [T,F,F,T] (T == ones, F == zeroes)
> >> > v += int4(1); // [1,4,5,2]
> >> >
> >> > // the if block is trivially rewritten:
> >> > int4 trueSide = v + int4(2);
> >> > int4 falseSize = v + int4(3);
> >> > v = select(m, trueSide, falseSide); // [3,7,8,4]
> >> >
> >> >
> >>
> >> This should work....
> >>
> >> int4 trueSide = v + 2;
> >> int4 falseSide = v + 3;
> >
> >
> > Probably, just wasn't sure.
>
> The idea with vectors is that they support the same operations that D array operations support. :-)
>

I tried to have indexing banned... I presume indexing works? :(

On 25 October 2012 09:36, Manu <turkeyman@gmail.com> wrote:
> On 25 October 2012 02:18, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>
>> On 25 October 2012 00:16, Manu <turkeyman@gmail.com> wrote:
>> > On 25 October 2012 02:01, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>> >>
>> >> On 24 October 2012 23:46, Manu <turkeyman@gmail.com> wrote:
>> >>
>> >> > Let's consider your example above for instance, I would rewrite
>> >> > (given
>> >> > existing syntax):
>> >> >
>> >> > // vector length of context = 1; current_mask = T
>> >> > int4 v = [0,3,4,1];
>> >> > int4 w = 3; // [3,3,3,3] via broadcast
>> >> > uint4 m = maskLess(v, w); // [T,F,F,T] (T == ones, F == zeroes)
>> >> > v += int4(1); // [1,4,5,2]
>> >> >
>> >> > // the if block is trivially rewritten:
>> >> > int4 trueSide = v + int4(2);
>> >> > int4 falseSize = v + int4(3);
>> >> > v = select(m, trueSide, falseSide); // [3,7,8,4]
>> >> >
>> >> >
>> >>
>> >> This should work....
>> >>
>> >> int4 trueSide = v + 2;
>> >> int4 falseSide = v + 3;
>> >
>> >
>> > Probably, just wasn't sure.
>>
>> The idea with vectors is that they support the same operations that D array operations support. :-)
>
>
> I tried to have indexing banned... I presume indexing works? :(

You can't index directly, no.  Only through .array[] property, which isn't an lvalue.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 25 October 2012 13:38, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 25 October 2012 09:36, Manu <turkeyman@gmail.com> wrote:
> > On 25 October 2012 02:18, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >>
> >> On 25 October 2012 00:16, Manu <turkeyman@gmail.com> wrote:
> >> > On 25 October 2012 02:01, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> >> >>
> >> >> On 24 October 2012 23:46, Manu <turkeyman@gmail.com> wrote:
> >> >>
> >> >> > Let's consider your example above for instance, I would rewrite
> >> >> > (given
> >> >> > existing syntax):
> >> >> >
> >> >> > // vector length of context = 1; current_mask = T
> >> >> > int4 v = [0,3,4,1];
> >> >> > int4 w = 3; // [3,3,3,3] via broadcast
> >> >> > uint4 m = maskLess(v, w); // [T,F,F,T] (T == ones, F == zeroes)
> >> >> > v += int4(1); // [1,4,5,2]
> >> >> >
> >> >> > // the if block is trivially rewritten:
> >> >> > int4 trueSide = v + int4(2);
> >> >> > int4 falseSize = v + int4(3);
> >> >> > v = select(m, trueSide, falseSide); // [3,7,8,4]
> >> >> >
> >> >> >
> >> >>
> >> >> This should work....
> >> >>
> >> >> int4 trueSide = v + 2;
> >> >> int4 falseSide = v + 3;
> >> >
> >> >
> >> > Probably, just wasn't sure.
> >>
> >> The idea with vectors is that they support the same operations that D array operations support. :-)
> >
> >
> > I tried to have indexing banned... I presume indexing works? :(
>
> You can't index directly, no.  Only through .array[] property, which isn't an lvalue.
>

Yeah, good. That's how I thought it was :)

Let me rewrite ti again then:

int4 v = [0,3,4,1];
int4 w = 3; // [3,3,3,3] via broadcast
v = selectLess(v, w, v + 3, v + 4); // combine the prior few lines: v < w =
[T,F,F,T]  ->  [0+3, 3+4, 4+4, 1+3] == [3,7,8,4]

I think this is far more convenient than any crazy 'if' syntax :) .. It's also perfectly optimal on all architectures I know aswell!

Manu:

> I think this is far more convenient than any crazy 'if' syntax :) .. It's
> also perfectly optimal on all architectures I know aswell!

You should show more respect for them and their work. Their ideas seem very far from being crazy. They have also proved their type system to be sound. This kind of work is lightyears ahead of the usual sloppy designs you see in D features, where design holes are found only years later, when sometimes it's too much late to fix them :-)

That if syntax (that is integrated in a type system that manages the masks, plus implicit polymorphism that allows the same function to be used both in a vectorized or scalar context) works with larger amounts of code too, while you are just doing a differential assignment.

Bye,
bearophile

On 25 October 2012 14:13, bearophile <bearophileHUGS@lycos.com> wrote:

> Manu:
>
>
>  I think this is far more convenient than any crazy 'if' syntax :) .. It's
>> also perfectly optimal on all architectures I know aswell!
>>
>
> You should show more respect for them and their work. Their ideas seem very far from being crazy. They have also proved their type system to be sound. This kind of work is lightyears ahead of the usual sloppy designs you see in D features, where design holes are found only years later, when sometimes it's too much late to fix them :-)


I think I said numerous times in my former email that it's really cool, and
certainly very interesting.
I just can't imagine it appearing in D any time soon. We do have some ways
to conveniently do lots of that stuff right now, and make some improvement
on other competing languages in the area.
I'd like to see more realistic case studies of their approach where it
significantly simplifies particular workloads?


That if syntax (that is integrated in a type system that manages the masks,
> plus implicit polymorphism that allows the same function to be used both in a vectorized or scalar context) works with larger amounts of code too, while you are just doing a differential assignment.
>

And that's likely where it all starts getting very complicated. If the
branches start doing significant (and unbalanced) work, an un-skilled
programmer will have a lot of trouble understanding what sort of mess they
may be making.
And as usual, x86 will be the most tolerant, so they may not even know when
profiling.
I've said before, it's very interesting, but it also sound potentially very
dangerous. It's probably also an awful lot of work I'd wager... I doubt
we'll see those expressions any time soon.

On 10/25/12 7:13 AM, bearophile wrote:
> Manu:
>
>> I think this is far more convenient than any crazy 'if' syntax :) .. It's
>> also perfectly optimal on all architectures I know aswell!
>
> You should show more respect for them and their work. Their ideas seem
> very far from being crazy. They have also proved their type system to be
> sound. This kind of work is lightyears ahead of the usual sloppy designs
> you see in D features, where design holes are found only years later,
> when sometimes it's too much late to fix them :-)

The part with respect for one and one's work applies right back at you.

Andrei

On 10/25/2012 4:13 AM, bearophile wrote:
> Manu:
>
>> I think this is far more convenient than any crazy 'if' syntax :) .. It's
>> also perfectly optimal on all architectures I know aswell!
>
> You should show more respect for them and their work. Their ideas seem very far
> from being crazy. They have also proved their type system to be sound. This kind
> of work is lightyears ahead of the usual sloppy designs you see in D features,
> where design holes are found only years later, when sometimes it's too much late
> to fix them :-)
>
> That if syntax (that is integrated in a type system that manages the masks, plus
> implicit polymorphism that allows the same function to be used both in a
> vectorized or scalar context) works with larger amounts of code too, while you
> are just doing a differential assignment.


The interesting thing about SIMD code is that if you just read the data sheets for SIMD instructions, and write some SIMD code based on them, you're going to get lousy results. I know this from experience (see the array op SIMD implementations in the D runtime library).

Making SIMD code that delivers performance turns out to be a highly quirky and subtle exercise, one that is resistant to formalization. Despite the availability of SIMD hardware, there is a terrible lack of quality information on how to do it right on the internet by people who know what they're talking about.

Manu is on the daily front lines of doing competitive, real world SIMD programming. He leads a team doing SIMD work. Hence, I am going to strongly weight his opinions on any high level SIMD design constructs.

Interestingly, both of us have rejected the "auto-vectorization" approach popular in C/C++ compilers, for very different reasons.

Walter Bright:

> Making SIMD code that delivers performance turns out to be a highly quirky and subtle exercise, one that is resistant to formalization.

I have written some SIMD code, with mixed results, so I understand part of such problems, despite my total experience on such things is limited.

Despite those problems and their failures I think it's important to support computer scientists that try to invent languages that try to offer medium-level means to write such kind of code :-) Reading and studying CS papers is important.


> Manu is on the daily front lines of doing competitive, real world SIMD programming. He leads a team doing SIMD work. Hence, I am going to strongly weight his opinions on any high level SIMD design constructs.

I respect both Manu and his work (and you Walter are the one at the top of my list of programming heroes).


> Interestingly, both of us have rejected the "auto-vectorization" approach popular in C/C++ compilers, for very different reasons.

The authors of that paper too have rejected it. It doesn't give enough semantics to the compilers. They have explored a different solution.

Bye,
bearophile