January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | On 1/13/12 3:08 PM, Manu wrote:
> On 13 January 2012 22:57, bearophile <bearophileHUGS@lycos.com
> <mailto:bearophileHUGS@lycos.com>> wrote:
>
> Walter:
>
> > What's our vector, Victor?
> > http://www.youtube.com/watch?v=fVq4_HhBK8Y
>
> Thank you Walter :-)
>
>
> > If int4 is out, I'd prefer something like vint4. Something short.
>
> Current names:
>
> void16
> double2
> float4
> byte16
> ubyte16
> short8
> ushort8
> int4
> uint4
> long2
>
> Your suggestion:
>
> vvoid16
> vdouble2
> vfloat4
> vbyte16
> vubyte16
> vshort8
> vushort8
> vint4
> vuint4
> vlong2
>
>
> My suggestion:
>
> void16v
> double2v
> float4v
> byte16v
> ubyte16v
> short8v
> ushort8v
> int4v
> uint4v
> long2v
>
> Bye,
> bearophile
>
>
> I think I'd vote for leaving it as it is, swayed by the fact that the
> more ambiguous types are super-rarely used. float4/int4 has a nice
> familiarity with HLSL/Cg.
All names should have a __ prepended, and then the library defines names for them such as vec!(int, 4) that obey module lookup and all. Dumping a wheelbarrow of confusable new keywords doesn't sound right at all.
Andrei
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu Attachments:
| On 14 January 2012 00:31, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org > wrote: > On 1/13/12 2:41 PM, Walter Bright wrote: > >> On 1/13/2012 12:27 PM, Peter Alexander wrote: >> >>> On 13/01/12 8:02 PM, Mehrdad wrote: >>> >>>> Er... is there any reason why we're using such a cryptic PXOR value instead of operator overloading? >>>> >>> >>> I imagine Walter will add the operator overloads later. >>> >> >> Right. simd() is just the bottom layer building block. It's a compiler intrinsic, and I don't want to make every overload a compiler intrinsic. >> > > People will want to pass a variable for op. Would that work? ...I really don't think they will. and most people would never dive this deep if the standard lib does its job properly. |
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 01/13/2012 11:36 PM, Andrei Alexandrescu wrote:
> On 1/13/12 3:08 PM, Manu wrote:
>> On 13 January 2012 22:57, bearophile <bearophileHUGS@lycos.com
>> <mailto:bearophileHUGS@lycos.com>> wrote:
>>
>> Walter:
>>
>> > What's our vector, Victor?
>> > http://www.youtube.com/watch?v=fVq4_HhBK8Y
>>
>> Thank you Walter :-)
>>
>>
>> > If int4 is out, I'd prefer something like vint4. Something short.
>>
>> Current names:
>>
>> void16
>> double2
>> float4
>> byte16
>> ubyte16
>> short8
>> ushort8
>> int4
>> uint4
>> long2
>>
>> Your suggestion:
>>
>> vvoid16
>> vdouble2
>> vfloat4
>> vbyte16
>> vubyte16
>> vshort8
>> vushort8
>> vint4
>> vuint4
>> vlong2
>>
>>
>> My suggestion:
>>
>> void16v
>> double2v
>> float4v
>> byte16v
>> ubyte16v
>> short8v
>> ushort8v
>> int4v
>> uint4v
>> long2v
>>
>> Bye,
>> bearophile
>>
>>
>> I think I'd vote for leaving it as it is, swayed by the fact that the
>> more ambiguous types are super-rarely used. float4/int4 has a nice
>> familiarity with HLSL/Cg.
>
> All names should have a __ prepended, and then the library defines names
> for them such as vec!(int, 4) that obey module lookup and all. Dumping a
> wheelbarrow of confusable new keywords doesn't sound right at all.
>
> Andrei
All of those are library types defined in core.simd.
For example, float4 is declared as
alias Vector!(float[4]) float4
And Vector simply hides what is built-in.
template Vector(T){
alias __vector(T) Vector;
}
I think this is a very clean design.
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu Attachments:
| On 14 January 2012 00:36, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org > wrote: > On 1/13/12 3:08 PM, Manu wrote: > >> On 13 January 2012 22:57, bearophile <bearophileHUGS@lycos.com <mailto:bearophileHUGS@lycos.**com <bearophileHUGS@lycos.com>>> wrote: >> >> Walter: >> >> > What's our vector, Victor? >> > http://www.youtube.com/watch?**v=fVq4_HhBK8Y<http://www.youtube.com/watch?v=fVq4_HhBK8Y> >> >> Thank you Walter :-) >> >> >> > If int4 is out, I'd prefer something like vint4. Something short. >> >> Current names: >> >> void16 >> double2 >> float4 >> byte16 >> ubyte16 >> short8 >> ushort8 >> int4 >> uint4 >> long2 >> >> Your suggestion: >> >> vvoid16 >> vdouble2 >> vfloat4 >> vbyte16 >> vubyte16 >> vshort8 >> vushort8 >> vint4 >> vuint4 >> vlong2 >> >> >> My suggestion: >> >> void16v >> double2v >> float4v >> byte16v >> ubyte16v >> short8v >> ushort8v >> int4v >> uint4v >> long2v >> >> Bye, >> bearophile >> >> >> I think I'd vote for leaving it as it is, swayed by the fact that the more ambiguous types are super-rarely used. float4/int4 has a nice familiarity with HLSL/Cg. >> > > All names should have a __ prepended, and then the library defines names for them such as vec!(int, 4) that obey module lookup and all. Dumping a wheelbarrow of confusable new keywords doesn't sound right at all. These ARE the library defined types we're talking about, defined in simd.d |
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | On 1/13/2012 11:06 AM, Peter Alexander wrote:
> Also, slight bikeshedding issue: I'm not so sure on using names like int4 for
> vectors. You see things like int32 a lot to mean a 32-bit integer, or int8 to
> mean an 8-bit integer. Using this notation for vectors may be confusing.
Consider also that the int8 is an alias, not a keyword. This means that the compiler will inform you of any ambiguities, as well as allow:
core.simd.int8
to disambiguate.
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 13/01/12 10:31 PM, Andrei Alexandrescu wrote:
> On 1/13/12 2:41 PM, Walter Bright wrote:
>> On 1/13/2012 12:27 PM, Peter Alexander wrote:
>>> On 13/01/12 8:02 PM, Mehrdad wrote:
>>>> Er... is there any reason why we're using such a cryptic PXOR value
>>>> instead of operator overloading?
>>>
>>> I imagine Walter will add the operator overloads later.
>>
>> Right. simd() is just the bottom layer building block. It's a compiler
>> intrinsic, and I don't want to make every overload a compiler intrinsic.
>
> People will want to pass a variable for op. Would that work?
Why would people want to do that?
Also, no, it can't possibly work. It just makes no sense.
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 01/13/2012 11:29 PM, Andrei Alexandrescu wrote:
> On 1/13/12 2:37 PM, Walter Bright wrote:
>> If int4 is out, I'd prefer something like vint4. Something short.
>
> Something short must compensate its potential for confusion with
> frequent usage and well-established convention. Arguably neither applies
> here.
>
> Andrei
>
Both apply.
Frequent usage: Under the precondition that core.simd is imported, of course.
Well-Established convention: See GLSL/HLSL/OpenCL/...
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 1/13/2012 2:31 PM, Andrei Alexandrescu wrote:
> People will want to pass a variable for op. Would that work?
It'll currently fail miserably - it has to be a constant. Otherwise, we have runtime code generation. While not impossible, it is a large increase in scope.
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 1/13/2012 2:36 PM, Andrei Alexandrescu wrote:
> All names should have a __ prepended, and then the library defines names for
> them such as vec!(int, 4) that obey module lookup and all. Dumping a wheelbarrow
> of confusable new keywords doesn't sound right at all.
They're not keywords, they are (literally) simple aliases:
alias Vector!(int[4]) int4;
As aliases, they obey all scoping and disambiguation rules, which I think is superior to using __ prefixes.
You could use Vector!(int[4]) everywhere instead, but I submit it's a bit klunky to do that and might as well provide a set of aliases (or else people will produce their own aliases and they'll all have different spellings).
|
January 13, 2012 Re: start on SIMD documentation | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 13/01/12 10:55 PM, Walter Bright wrote:
> On 1/13/2012 11:06 AM, Peter Alexander wrote:
>> Also, slight bikeshedding issue: I'm not so sure on using names like
>> int4 for
>> vectors. You see things like int32 a lot to mean a 32-bit integer, or
>> int8 to
>> mean an 8-bit integer. Using this notation for vectors may be confusing.
>
> Consider also that the int8 is an alias, not a keyword. This means that
> the compiler will inform you of any ambiguities, as well as allow:
>
> core.simd.int8
>
> to disambiguate.
I realize that. It's just that I mentally associate the identifier int8 with an 8-bit integer as it is something I regularly see in C++ code.
However, I'm willing to drop my position. After a quick Google, I discovered that it's not as common as I thought. I'm happy to keep float4 etc. since it is simple and is already used in a couple of shader languages.
|
Copyright © 1999-2021 by the D Language Foundation