January 16, 2012 Re: SIMD benchmark | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michel Fortin Attachments:
| On 16 January 2012 21:27, Michel Fortin <michel.fortin@michelf.com> wrote:
> In fact, the optimization I'd expect the compiler to do in this case is just wipe out all the code, as it does nothing other than putting a value in a local variable which is never reused later.
>
Yes, my first thought when I saw this test was "why is it generating any
code at all?".. But I tried to forget about that :)
I am curious though, what is causing that code (on both sides) to not be
eliminated? If I write that in C, I'm sure it would generate nothing. Is
this a language implementation bug somehow?
|
January 16, 2012 Re: SIMD benchmark | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 16 January 2012 19:25, Walter Bright <newshound2@digitalmars.com> wrote: > On 1/16/2012 11:16 AM, Iain Buclaw wrote: >>> >>> But don't worry, I'm not planning on working on that at the moment :-) >> >> Leave that sort of optimisation for the backend to handle please. ;-) > > > Of course. > > I suspect Intel's compiler does that one, does gcc? > There's auto-vectorisation for for(), foreach(), and foreach_reverse() loops that I have written support for. I am not aware of GCC vectorising anything else. example: int a[256], b[256], c[256]; void foo () { for (int i=0; i<256; i++) a[i] = b[i] + c[i]; } -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; |
January 16, 2012 Re: SIMD benchmark | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On 16/01/12 8:56 PM, Iain Buclaw wrote:
> On 16 January 2012 19:25, Walter Bright<newshound2@digitalmars.com> wrote:
>> On 1/16/2012 11:16 AM, Iain Buclaw wrote:
>>>>
>>>> But don't worry, I'm not planning on working on that at the moment :-)
>>>
>>> Leave that sort of optimisation for the backend to handle please. ;-)
>>
>>
>> Of course.
>>
>> I suspect Intel's compiler does that one, does gcc?
>>
>
> There's auto-vectorisation for for(), foreach(), and foreach_reverse()
> loops that I have written support for. I am not aware of GCC
> vectorising anything else.
>
> example:
>
> int a[256], b[256], c[256];
> void foo () {
> for (int i=0; i<256; i++)
> a[i] = b[i] + c[i];
> }
>
Unfortunately, if the function was this:
void foo(int[] a, int[] b, int[] c) {
for (int i=0; i<256; i++)
a[i] = b[i] + c[i];
}
Then it can't vectorize due to aliasing.
|
January 16, 2012 Re: SIMD benchmark | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander Attachments:
| On 16 January 2012 23:57, Peter Alexander <peter.alexander.au@gmail.com>wrote: > On 16/01/12 8:56 PM, Iain Buclaw wrote: > >> On 16 January 2012 19:25, Walter Bright<newshound2@digitalmars.**com<newshound2@digitalmars.com>> >> wrote: >> >>> On 1/16/2012 11:16 AM, Iain Buclaw wrote: >>> >>> >>>>> But don't worry, I'm not planning on working on that at the moment :-) >>>>> >>>> >>>> Leave that sort of optimisation for the backend to handle please. ;-) >>>> >>> >>> >>> Of course. >>> >>> I suspect Intel's compiler does that one, does gcc? >>> >>> >> There's auto-vectorisation for for(), foreach(), and foreach_reverse() >> loops that I have written support for. I am not aware of GCC >> vectorising anything else. >> >> example: >> >> int a[256], b[256], c[256]; >> void foo () { >> for (int i=0; i<256; i++) >> a[i] = b[i] + c[i]; >> } >> >> > Unfortunately, if the function was this: > > void foo(int[] a, int[] b, int[] c) { > > for (int i=0; i<256; i++) > a[i] = b[i] + c[i]; > } > > Then it can't vectorize due to aliasing. > This is why D needs a __restrict attribute! ;) |
January 16, 2012 Re: SIMD benchmark | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On 1/16/2012 12:22 PM, Manu wrote:
> Yes, my first thought when I saw this test was "why is it generating any code at
> all?".. But I tried to forget about that :)
> I am curious though, what is causing that code (on both sides) to not be
> eliminated? If I write that in C, I'm sure it would generate nothing. Is this a
> language implementation bug somehow?
Compile with inlining off, and the compiler 'forgets' what the called function does, so it must call it.
|
January 16, 2012 Re: SIMD benchmark | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On 1/16/2012 1:54 PM, Manu wrote:
> Unfortunately, if the function was this:
>
> void foo(int[] a, int[] b, int[] c) {
>
> for (int i=0; i<256; i++)
> a[i] = b[i] + c[i];
> }
>
> Then it can't vectorize due to aliasing.
>
>
> This is why D needs a __restrict attribute! ;)
That's why D has:
a[] = b[] + c[];
because the language requires the arrays to be distinct.
|
January 16, 2012 Re: SIMD benchmark | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright Attachments:
| On 17 January 2012 00:03, Walter Bright <newshound2@digitalmars.com> wrote:
> On 1/16/2012 1:54 PM, Manu wrote:
>
>> Unfortunately, if the function was this:
>>
>> void foo(int[] a, int[] b, int[] c) {
>>
>> for (int i=0; i<256; i++)
>> a[i] = b[i] + c[i];
>> }
>>
>> Then it can't vectorize due to aliasing.
>>
>>
>> This is why D needs a __restrict attribute! ;)
>>
>
> That's why D has:
>
> a[] = b[] + c[];
>
> because the language requires the arrays to be distinct.
>
Surely it would be possible for them to be overlapping slices?
|
January 16, 2012 Re: SIMD benchmark | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On Mon, 16 Jan 2012 23:06:12 +0100, Manu <turkeyman@gmail.com> wrote:
> On 17 January 2012 00:03, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 1/16/2012 1:54 PM, Manu wrote:
>>
>>> Unfortunately, if the function was this:
>>>
>>> void foo(int[] a, int[] b, int[] c) {
>>>
>>> for (int i=0; i<256; i++)
>>> a[i] = b[i] + c[i];
>>> }
>>>
>>> Then it can't vectorize due to aliasing.
>>>
>>>
>>> This is why D needs a __restrict attribute! ;)
>>>
>>
>> That's why D has:
>>
>> a[] = b[] + c[];
>>
>> because the language requires the arrays to be distinct.
>>
>
> Surely it would be possible for them to be overlapping slices?
If they are, that's your fault and your problem.
"The lvalue slice and any rvalue slices must not overlap."
|
January 16, 2012 Re: SIMD benchmark | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjærås | On Mon, 16 Jan 2012 23:22:21 +0100, Simen Kjærås <simen.kjaras@gmail.com> wrote: > On Mon, 16 Jan 2012 23:06:12 +0100, Manu <turkeyman@gmail.com> wrote: > >> On 17 January 2012 00:03, Walter Bright <newshound2@digitalmars.com> wrote: >> >>> On 1/16/2012 1:54 PM, Manu wrote: >>> >>>> Unfortunately, if the function was this: >>>> >>>> void foo(int[] a, int[] b, int[] c) { >>>> >>>> for (int i=0; i<256; i++) >>>> a[i] = b[i] + c[i]; >>>> } >>>> >>>> Then it can't vectorize due to aliasing. >>>> >>>> >>>> This is why D needs a __restrict attribute! ;) >>>> >>> >>> That's why D has: >>> >>> a[] = b[] + c[]; >>> >>> because the language requires the arrays to be distinct. >>> >> >> Surely it would be possible for them to be overlapping slices? > > If they are, that's your fault and your problem. > > "The lvalue slice and any rvalue slices must not overlap." Sorry, forgot the link: http://www.d-programming-language.org/arrays.html#array-operations |
January 16, 2012 Re: SIMD benchmark | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | On 16 January 2012 21:57, Peter Alexander <peter.alexander.au@gmail.com> wrote: > On 16/01/12 8:56 PM, Iain Buclaw wrote: >> >> On 16 January 2012 19:25, Walter Bright<newshound2@digitalmars.com> wrote: >>> >>> On 1/16/2012 11:16 AM, Iain Buclaw wrote: >>> >>>>> >>>>> But don't worry, I'm not planning on working on that at the moment :-) >>>> >>>> >>>> Leave that sort of optimisation for the backend to handle please. ;-) >>> >>> >>> >>> Of course. >>> >>> I suspect Intel's compiler does that one, does gcc? >>> >> >> There's auto-vectorisation for for(), foreach(), and foreach_reverse() >> loops that I have written support for. I am not aware of GCC >> vectorising anything else. >> >> example: >> >> int a[256], b[256], c[256]; >> void foo () { >> for (int i=0; i<256; i++) >> a[i] = b[i] + c[i]; >> } >> > > Unfortunately, if the function was this: > > void foo(int[] a, int[] b, int[] c) { > > for (int i=0; i<256; i++) > a[i] = b[i] + c[i]; > } > > Then it can't vectorize due to aliasing. Compile with -fstrict-aliasing then? I could certainly play about with having this enabled by default, but I forsee there may be issues (maybe have it on for @safe code?) Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; |
Copyright © 1999-2021 by the D Language Foundation