www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.simd

reply Manu <turkeyman gmail.com> writes:
--20cf300faca16c9eeb04bb4b291b
Content-Type: text/plain; charset=UTF-8

Hey chaps (and possibly lasses?)

I've been slowly working a std.simd library, the aim of which is to provide
a lowest-level hardware-independent SIMD interface. core.simd implements
SSE currently for x86, other architectures are currently exposed via
gcc.builtins.
The purpose of std.simd, is to be the lowest level API that people make
direct use of, while still having as-close-to-direct-as-possible mapping to
the hardware opcodes, but still being portable. I would expect that custom,
more-feature-rich SIMD/vector/matrix/linear algebra libraries should be
built on top of std.simd in future, that way being portable to as many
systems as possible.

Now I've reached a question in the design of the library, I'd like to take
a general consensus.

lowest level vectors are defined by: __vector(type[width])
But core.simd also defines a bunch of handy 'nice' aliases for common
vector types, ie, float4, int4, short8, etc.

I want to claim those names into std.simd. They should be the lowest level
names that people use, and therefore associate with the std.simd
functionality.
I also want to enhance them a bit:
  I want to make them a struct that wraps the primitive rather than an
alias. I understand this single-POD struct will be handled the same as the
POD its self, is that right? If I pass the wrapper struct byval to a
function, it will be passed in a register as it should yeah?
  I then intend to then add CTFE support, and maybe some properties and
opDisplatch bits.

Does this sound reasonable?

--20cf300faca16c9eeb04bb4b291b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey chaps (and possibly lasses?)<div><br></div><div>I&#39;ve been slowly wo=
rking a std.simd library, the aim of which is to provide a lowest-level har=
dware-independent=C2=A0SIMD interface. core.simd implements SSE currently f=
or x86, other architectures are currently exposed via gcc.builtins.</div>
<div>The purpose of std.simd, is to be the lowest level API that people mak=
e direct use of, while still having as-close-to-direct-as-possible mapping =
to the hardware opcodes, but still being portable. I would expect that cust=
om, more-feature-rich SIMD/vector/matrix/linear algebra libraries should be=
 built on top of std.simd in future, that way being portable to as many sys=
tems as possible.</div>
<div><br></div><div>Now I&#39;ve reached a question in the design of the li=
brary, I&#39;d like to take a general consensus.</div><div><br></div><div>l=
owest level vectors are defined by: __vector(type[width])</div><div>But cor=
e.simd also defines a bunch of handy &#39;nice&#39; aliases for common vect=
or types, ie, float4, int4, short8, etc.</div>
<div><br></div><div>I want to claim those names into std.simd. They should =
be the lowest level names that people use, and therefore associate with the=
 std.simd functionality.</div><div>I also want to enhance them a bit:</div>
<div>=C2=A0 I want to make them a struct that wraps the primitive rather th=
an an alias. I understand this single-POD struct will be handled the same a=
s the POD its self, is that right? If I pass the wrapper struct byval to a =
function, it will be passed in a register as it should yeah?</div>
<div>=C2=A0 I then intend to then add CTFE support, and maybe some properti=
es and opDisplatch bits.</div><div><br></div><div>Does this sound reasonabl=
e?</div>

--20cf300faca16c9eeb04bb4b291b--
Mar 15 2012
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 15 Mar 2012 12:09:58 -0500, Manu <turkeyman gmail.com> wrote:
 Hey chaps (and possibly lasses?)

 I've been slowly working a std.simd library, the aim of which is to  
 provide
 a lowest-level hardware-independent SIMD interface. core.simd implements
 SSE currently for x86, other architectures are currently exposed via
 gcc.builtins.
 The purpose of std.simd, is to be the lowest level API that people make
 direct use of, while still having as-close-to-direct-as-possible mapping  
 to
 the hardware opcodes, but still being portable. I would expect that  
 custom,
 more-feature-rich SIMD/vector/matrix/linear algebra libraries should be
 built on top of std.simd in future, that way being portable to as many
 systems as possible.

 Now I've reached a question in the design of the library, I'd like to  
 take
 a general consensus.

 lowest level vectors are defined by: __vector(type[width])
 But core.simd also defines a bunch of handy 'nice' aliases for common
 vector types, ie, float4, int4, short8, etc.

 I want to claim those names into std.simd. They should be the lowest  
 level
 names that people use, and therefore associate with the std.simd
 functionality.
 I also want to enhance them a bit:
   I want to make them a struct that wraps the primitive rather than an
 alias. I understand this single-POD struct will be handled the same as  
 the
 POD its self, is that right? If I pass the wrapper struct byval to a
 function, it will be passed in a register as it should yeah?
   I then intend to then add CTFE support, and maybe some properties and
 opDisplatch bits.

 Does this sound reasonable?

This sounds reasonable. However, please realize that if you wish to use the short vector names (i.e. float4, float3, float2, etc) you should support the full set with a decent range of operations and methods. Several people (myself included) have written similar short vector libraries; I think having having short vectors in phobos is important, but having one library provide float4 and another float2 is less than ideal, even if not all of the types could leverage the SMID backend. For myself, the killer feature for such a library would be have the CUDA compatible alignments for the types. (or an equivalent enum to the effect)
Mar 15 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300faca1f5c8c204bb4cba8b
Content-Type: text/plain; charset=UTF-8

On 15 March 2012 20:35, Robert Jacques <sandford jhu.edu> wrote:

 On Thu, 15 Mar 2012 12:09:58 -0500, Manu <turkeyman gmail.com> wrote:

 Hey chaps (and possibly lasses?)

 I've been slowly working a std.simd library, the aim of which is to
 provide
 a lowest-level hardware-independent SIMD interface. core.simd implements
 SSE currently for x86, other architectures are currently exposed via
 gcc.builtins.
 The purpose of std.simd, is to be the lowest level API that people make
 direct use of, while still having as-close-to-direct-as-possible mapping
 to
 the hardware opcodes, but still being portable. I would expect that
 custom,
 more-feature-rich SIMD/vector/matrix/linear algebra libraries should be
 built on top of std.simd in future, that way being portable to as many
 systems as possible.

 Now I've reached a question in the design of the library, I'd like to take
 a general consensus.

 lowest level vectors are defined by: __vector(type[width])
 But core.simd also defines a bunch of handy 'nice' aliases for common
 vector types, ie, float4, int4, short8, etc.

 I want to claim those names into std.simd. They should be the lowest level
 names that people use, and therefore associate with the std.simd
 functionality.
 I also want to enhance them a bit:
  I want to make them a struct that wraps the primitive rather than an
 alias. I understand this single-POD struct will be handled the same as the
 POD its self, is that right? If I pass the wrapper struct byval to a
 function, it will be passed in a register as it should yeah?
  I then intend to then add CTFE support, and maybe some properties and
 opDisplatch bits.

 Does this sound reasonable?

This sounds reasonable. However, please realize that if you wish to use the short vector names (i.e. float4, float3, float2, etc) you should support the full set with a decent range of operations and methods. Several people (myself included) have written similar short vector libraries; I think having having short vectors in phobos is important, but having one library provide float4 and another float2 is less than ideal, even if not all of the types could leverage the SMID backend. For myself, the killer feature for such a library would be have the CUDA compatible alignments for the types. (or an equivalent enum to the effect)

I can see how you come to that conclusion, but I generally feel that that's a problem for a higher layer of library. I really feel it's important to keep std.simd STRICTLY about the hardware simd operations, only implementing what the hardware can express efficiently, and not trying to emulate anything else. In some areas I feel I've already violated that premise, by adding some functions to make good use of something that NEON/VMX can express in a single opcode, but takes SSE 2-3. I don't want to push that bar, otherwise the user will lose confidence that the functions in std.simd will actually work efficiently on any given hardware. It's not a do-everything library, it's a hardware SIMD abstraction, and most functions map to exactly one hardware opcode. I expect most people will want to implement their own higher level lib on top tbh; almost nobody will ever agree on what the perfect maths library should look like, and it's also context specific. --20cf300faca1f5c8c204bb4cba8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 15 March 2012 20:35, Robert Jacques <span dir= =3D"ltr">&lt;<a href=3D"mailto:sandford jhu.edu">sandford jhu.edu</a>&gt;</= span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Thu, 15 Mar 2012 12:09:58 -0500,= Manu &lt;<a href=3D"mailto:turkeyman gmail.com" target=3D"_blank">turkeyma= n gmail.com</a>&gt; wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Hey chaps (and possibly lasses?)<br> <br> I&#39;ve been slowly working a std.simd library, the aim of which is to pro= vide<br> a lowest-level hardware-independent SIMD interface. core.simd implements<br=

gcc.builtins.<br> The purpose of std.simd, is to be the lowest level API that people make<br> direct use of, while still having as-close-to-direct-as-possible mapping to= <br> the hardware opcodes, but still being portable. I would expect that custom,= <br> more-feature-rich SIMD/vector/matrix/linear algebra libraries should be<br> built on top of std.simd in future, that way being portable to as many<br> systems as possible.<br> <br> Now I&#39;ve reached a question in the design of the library, I&#39;d like = to take<br> a general consensus.<br> <br> lowest level vectors are defined by: __vector(type[width])<br> But core.simd also defines a bunch of handy &#39;nice&#39; aliases for comm= on<br> vector types, ie, float4, int4, short8, etc.<br> <br> I want to claim those names into std.simd. They should be the lowest level<= br> names that people use, and therefore associate with the std.simd<br> functionality.<br> I also want to enhance them a bit:<br> =C2=A0I want to make them a struct that wraps the primitive rather than an= <br> alias. I understand this single-POD struct will be handled the same as the<= br> POD its self, is that right? If I pass the wrapper struct byval to a<br> function, it will be passed in a register as it should yeah?<br> =C2=A0I then intend to then add CTFE support, and maybe some properties an= d<br> opDisplatch bits.<br> <br> Does this sound reasonable?<br> </blockquote> <br></div></div> This sounds reasonable. However, please realize that if you wish to use the= short vector names (i.e. float4, float3, float2, etc) you should support t= he full set with a decent range of operations and methods. Several people (= myself included) have written similar short vector libraries; I think havin= g having short vectors in phobos is important, but having one library provi= de float4 and another float2 is less than ideal, even if not all of the typ= es could leverage the SMID backend. For myself, the killer feature for such= a library would be have the CUDA compatible alignments for the types. (or = an equivalent enum to the effect)<br> </blockquote></div><div><br></div><div>I can see how you come to that concl= usion, but I generally feel that that&#39;s a problem for a higher layer of= library.</div><div>I really feel it&#39;s important to keep std.simd STRIC= TLY about the hardware simd operations, only implementing what the hardware= can express efficiently, and not trying to emulate anything else. In some = areas I feel I&#39;ve already violated that premise, by adding some functio= ns to make good use of something that NEON/VMX can express in a single opco= de, but takes SSE 2-3.=C2=A0I don&#39;t want to push that bar, otherwise th= e user will lose confidence that the functions in std.simd will actually wo= rk efficiently on any given hardware.</div> <div>It&#39;s not a do-everything library, it&#39;s a hardware SIMD abstrac= tion, and most functions map to exactly one hardware opcode. I expect most = people will want to implement their own higher level lib on top tbh; almost= nobody will ever agree on what the perfect maths library should look like,= and it&#39;s also context specific.</div> --20cf300faca1f5c8c204bb4cba8b--
Mar 15 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 16 March 2012 08:02, Manu <turkeyman gmail.com> wrote:
 On 15 March 2012 20:35, Robert Jacques <sandford jhu.edu> wrote:
 This sounds reasonable. However, please realize that if you wish to use
 the short vector names (i.e. float4, float3, float2, etc) you should sup=


 the full set with a decent range of operations and methods. Several peop=


 (myself included) have written similar short vector libraries; I think
 having having short vectors in phobos is important, but having one libra=


 provide float4 and another float2 is less than ideal, even if not all of=


 types could leverage the SMID backend. For myself, the killer feature fo=


 such a library would be have the CUDA compatible alignments for the type=


 (or an equivalent enum to the effect)

I can see how you come to that conclusion, but I generally feel that that=

 a problem for a higher layer of library.
 I really feel it's important to keep std.simd STRICTLY about the hardware
 simd operations, only implementing what the hardware can express
 efficiently, and not trying to emulate anything else. In some areas I fee=

 I've already violated that premise, by adding some functions to make good
 use of something that NEON/VMX can express in a single opcode, but takes =

 2-3.=C2=A0I don't want to push that bar, otherwise the user will lose con=

 that the functions in std.simd will actually work efficiently on any give=

 hardware.
 It's not a do-everything library, it's a hardware SIMD abstraction, and m=

 functions map to exactly one hardware opcode. I expect most people will w=

 to implement their own higher level lib on top tbh; almost nobody will ev=

 agree on what the perfect maths library should look like, and it's also
 context specific.

I think that having the low-level vectors makes sense. Since technically only float4, int4, short8, byte16, actually make sense in the context of direct SIMD, providing other vectors would be straying into vector-library territory, as people would then expect interoperability between them, standard vector/matrix operations, and that could get too high-level. Third-party libraries have to be useful for something! Slightly off topic questions: Are you planning on providing a way to fallback if certain operations aren't supported? Even if it can only be picked at compile time? Is your work on Github or something? I wouldn't mind having a peek, since this stuff interests me. How well does this stuff inline? I can imagine that a lot of the benefit of using SIMD would be lost if every SIMD instruction ends up wrapped in 3-4 more instructions, especially if you need to do consecutive operations on the same data. -- James Miller
Mar 15 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Great to hear this is coming along. Can I get a link to the 
(github?) source?

Do the simd functions have fallback functionally for unsupported 
hardware? Is that planned? Or is that something I'd be writing 
into my own Vector structures?

Also, I noticed Phobos now includes a "etc" library, do you have 
plans to eventually make a general purpose higher-level Linear 
systems library in that?
Mar 15 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 16 March 2012 11:14, F i L <witte2008 gmail.com> wrote:
 Great to hear this is coming along. Can I get a link to the (github?)
 source?

 Do the simd functions have fallback functionally for unsupported hardware?
 Is that planned? Or is that something I'd be writing into my own Vector
 structures?

 Also, I noticed Phobos now includes a "etc" library, do you have plans to
 eventually make a general purpose higher-level Linear systems library in
 that?

Looks like we have the same questions. Great minds think alike and all that :D -- Jame sMiller
Mar 15 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235447044c74c33c04bb4fd4d4
Content-Type: text/plain; charset=UTF-8

On 15 March 2012 22:27, James Miller <james aatch.net> wrote:

 On 16 March 2012 08:02, Manu <turkeyman gmail.com> wrote:
 On 15 March 2012 20:35, Robert Jacques <sandford jhu.edu> wrote:
 This sounds reasonable. However, please realize that if you wish to use
 the short vector names (i.e. float4, float3, float2, etc) you should


 the full set with a decent range of operations and methods. Several


 (myself included) have written similar short vector libraries; I think
 having having short vectors in phobos is important, but having one


 provide float4 and another float2 is less than ideal, even if not all


 types could leverage the SMID backend. For myself, the killer feature


 such a library would be have the CUDA compatible alignments for the


 (or an equivalent enum to the effect)

I can see how you come to that conclusion, but I generally feel that

 a problem for a higher layer of library.
 I really feel it's important to keep std.simd STRICTLY about the hardware
 simd operations, only implementing what the hardware can express
 efficiently, and not trying to emulate anything else. In some areas I

 I've already violated that premise, by adding some functions to make good
 use of something that NEON/VMX can express in a single opcode, but takes

 2-3. I don't want to push that bar, otherwise the user will lose

 that the functions in std.simd will actually work efficiently on any

 hardware.
 It's not a do-everything library, it's a hardware SIMD abstraction, and

 functions map to exactly one hardware opcode. I expect most people will

 to implement their own higher level lib on top tbh; almost nobody will

 agree on what the perfect maths library should look like, and it's also
 context specific.

I think that having the low-level vectors makes sense. Since technically only float4, int4, short8, byte16, actually make sense in the context of direct SIMD, providing other vectors would be straying into vector-library territory, as people would then expect interoperability between them, standard vector/matrix operations, and that could get too high-level. Third-party libraries have to be useful for something! Slightly off topic questions: Are you planning on providing a way to fallback if certain operations aren't supported?

I think it depends on HOW unsupported they are. If it can be emulated efficiently (and in the context, the emulation would be as efficient as possible on the architecture anyway), then probably, but if it's a problem that should simply be solved another way, I'd rather encourage that with a compile error. Even if it can only be picked at compile time? Is
 your work on Github or something?

Yup: https://github.com/TurkeyMan/phobos/commits/master/std/simd.d
 I wouldn't mind having a peek, since
 this stuff interests me. How well does this stuff inline?

It inlines perfectly, I pay very close attention to the codegen every single function. And have loads of static branches to select more efficient versions for more recent revisions of the SSE instruction set.
 I can
 imagine that a lot of the benefit of using SIMD would be lost if every
 SIMD instruction ends up wrapped in 3-4 more instructions, especially
 if you need to do consecutive operations on the same data.

It will lose 100% of its benefit it it is wrapped up in even ONE function call, and equally so if the vectors don't pass/return in hardware registers as they should. I'm crafting it to have the same performance characteristics as 'int'. --00235447044c74c33c04bb4fd4d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 15 March 2012 22:27, James Miller <span dir= =3D"ltr">&lt;<a href=3D"mailto:james aatch.net">james aatch.net</a>&gt;</sp= an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 16 March 2012 08:02, Manu &lt;<a href=3D"mailto:turkey= man gmail.com">turkeyman gmail.com</a>&gt; wrote:<br> &gt; On 15 March 2012 20:35, Robert Jacques &lt;<a href=3D"mailto:sandford = jhu.edu">sandford jhu.edu</a>&gt; wrote:<br> </div><div><div class=3D"h5">&gt;&gt; This sounds reasonable. However, plea= se realize that if you wish to use<br> &gt;&gt; the short vector names (i.e. float4, float3, float2, etc) you shou= ld support<br> &gt;&gt; the full set with a decent range of operations and methods. Severa= l people<br> &gt;&gt; (myself included) have written similar short vector libraries; I t= hink<br> &gt;&gt; having having short vectors in phobos is important, but having one= library<br> &gt;&gt; provide float4 and another float2 is less than ideal, even if not = all of the<br> &gt;&gt; types could leverage the SMID backend. For myself, the killer feat= ure for<br> &gt;&gt; such a library would be have the CUDA compatible alignments for th= e types.<br> &gt;&gt; (or an equivalent enum to the effect)<br> &gt;<br> &gt;<br> &gt; I can see how you come to that conclusion, but I generally feel that t= hat&#39;s<br> &gt; a problem for a higher layer of library.<br> &gt; I really feel it&#39;s important to keep std.simd STRICTLY about the h= ardware<br> &gt; simd operations, only implementing what the hardware can express<br> &gt; efficiently, and not trying to emulate anything else. In some areas I = feel<br> &gt; I&#39;ve already violated that premise, by adding some functions to ma= ke good<br> &gt; use of something that NEON/VMX can express in a single opcode, but tak= es SSE<br> &gt; 2-3.=C2=A0I don&#39;t want to push that bar, otherwise the user will l= ose confidence<br> &gt; that the functions in std.simd will actually work efficiently on any g= iven<br> &gt; hardware.<br> &gt; It&#39;s not a do-everything library, it&#39;s a hardware SIMD abstrac= tion, and most<br> &gt; functions map to exactly one hardware opcode. I expect most people wil= l want<br> &gt; to implement their own higher level lib on top tbh; almost nobody will= ever<br> &gt; agree on what the perfect maths library should look like, and it&#39;s= also<br> &gt; context specific.<br> <br> </div></div>I think that having the low-level vectors makes sense. Since<br=

the context of direct SIMD, providing other vectors would be straying<br> into vector-library territory, as people would then expect<br> interoperability between them, standard vector/matrix operations, and<br> that could get too high-level. Third-party libraries have to be useful<br> for something!<br> <br> Slightly off topic questions:<br> Are you planning on providing a way to fallback if certain operations<br> aren&#39;t supported?</blockquote><div><br></div><div>I think it depends on= HOW unsupported they are. If it can be emulated efficiently (and in the co= ntext, the emulation would be as efficient as possible on the architecture = anyway), then probably, but if it&#39;s a problem that should simply be sol= ved another way, I&#39;d rather encourage that with a compile error.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> Even if it can only be picke= d at compile time? Is<br> your work on Github or something?</blockquote><div><br></div><div>Yup:=C2= =A0<a href=3D"https://github.com/TurkeyMan/phobos/commits/master/std/simd.d= ">https://github.com/TurkeyMan/phobos/commits/master/std/simd.d</a></div><d= iv>=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I wouldn&#39;t mind having a peek, since<br=

<br></div><div>It inlines perfectly, I pay very close attention to the code= gen every single function. And have loads of static branches to select more= efficient versions for more recent revisions of the SSE instruction set.</= div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"> I can<br> imagine that a lot of the benefit of using SIMD would be lost if every<br> SIMD instruction ends up wrapped in 3-4 more instructions, especially<br> if you need to do consecutive operations on the same data.<br></blockquote>= <div><br></div><div>It will lose 100% of its benefit it it is wrapped up in= even ONE function call, and equally so if the vectors don&#39;t pass/retur= n in hardware registers as they should.</div> <div>I&#39;m crafting it to have the same performance characteristics as &#= 39;int&#39;.</div></div> --00235447044c74c33c04bb4fd4d4--
Mar 15 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--002354471058032e7c04bb4fe7db
Content-Type: text/plain; charset=UTF-8

On 16 March 2012 00:14, F i L <witte2008 gmail.com> wrote:

 Do the simd functions have fallback functionally for unsupported hardware?
 Is that planned? Or is that something I'd be writing into my own Vector
 structures?

I am thinking more and more that it'll have fallback for unsupported hardware (since the same code will need to run for CTFE), but as well just pipe unsupported platforms through that code. But it probably won't be as efficient as possible for those platforms, so the jury is still out. It might be better to encourage them to do it properly.
 Also, I noticed Phobos now includes a "etc" library, do you have plans to
 eventually make a general purpose higher-level Linear systems library in
 that?

I don't plan to. If I end out using one in my personal code, I'll share it though. --002354471058032e7c04bb4fe7db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 16 March 2012 00:14, F i L <span dir=3D"ltr">= &lt;<a href=3D"mailto:witte2008 gmail.com">witte2008 gmail.com</a>&gt;</spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> Do the simd functions have fallback functionally for unsupported hardware? = Is that planned? Or is that something I&#39;d be writing into my own Vector= structures?</blockquote><div><br></div><div>I am thinking more and more th= at it&#39;ll have fallback for unsupported hardware (since the same code wi= ll need to run for CTFE), but as well just pipe unsupported platforms throu= gh that code.</div> <div>But it probably won&#39;t be as efficient as possible for those platfo= rms, so the jury is still out. It might be better to encourage them to do i= t properly.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Also, I noticed Phobos now includes a &quot;etc&quot; library, do you have = plans to eventually make a general purpose higher-level Linear systems libr= ary in that?<br></blockquote><div>=C2=A0</div><div>I don&#39;t plan to. If = I end out using one in my personal code, I&#39;ll share it though.</div> </div> --002354471058032e7c04bb4fe7db--
Mar 15 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 16 March 2012 11:44, Manu <turkeyman gmail.com> wrote:
 On 15 March 2012 22:27, James Miller <james aatch.net> wrote:
 On 16 March 2012 08:02, Manu <turkeyman gmail.com> wrote:
 On 15 March 2012 20:35, Robert Jacques <sandford jhu.edu> wrote:
 This sounds reasonable. However, please realize that if you wish to u=




 the short vector names (i.e. float4, float3, float2, etc) you should
 support
 the full set with a decent range of operations and methods. Several
 people
 (myself included) have written similar short vector libraries; I thin=




 having having short vectors in phobos is important, but having one
 library
 provide float4 and another float2 is less than ideal, even if not all
 of the
 types could leverage the SMID backend. For myself, the killer feature
 for
 such a library would be have the CUDA compatible alignments for the
 types.
 (or an equivalent enum to the effect)

I can see how you come to that conclusion, but I generally feel that that's a problem for a higher layer of library. I really feel it's important to keep std.simd STRICTLY about the hardware simd operations, only implementing what the hardware can express efficiently, and not trying to emulate anything else. In some areas I feel I've already violated that premise, by adding some functions to make good use of something that NEON/VMX can express in a single opcode, but tak=



 SSE
 2-3.=C2=A0I don't want to push that bar, otherwise the user will lose
 confidence
 that the functions in std.simd will actually work efficiently on any
 given
 hardware.
 It's not a do-everything library, it's a hardware SIMD abstraction, an=



 most
 functions map to exactly one hardware opcode. I expect most people wil=



 want
 to implement their own higher level lib on top tbh; almost nobody will
 ever
 agree on what the perfect maths library should look like, and it's als=



 context specific.

I think that having the low-level vectors makes sense. Since technically only float4, int4, short8, byte16, actually make sense in the context of direct SIMD, providing other vectors would be straying into vector-library territory, as people would then expect interoperability between them, standard vector/matrix operations, and that could get too high-level. Third-party libraries have to be useful for something! Slightly off topic questions: Are you planning on providing a way to fallback if certain operations aren't supported?

I think it depends on HOW unsupported they are. If it can be emulated efficiently (and in the context, the emulation would be as efficient as possible on the architecture anyway), then probably, but if it's a proble=

 that should simply be solved another way, I'd rather encourage that with =

 compile error.

 Even if it can only be picked at compile time? Is
 your work on Github or something?

Yup:=C2=A0https://github.com/TurkeyMan/phobos/commits/master/std/simd.d
 I wouldn't mind having a peek, since
 this stuff interests me. How well does this stuff inline?

It inlines perfectly, I pay very close attention to the codegen every sin=

 function. And have loads of static branches to select more efficient
 versions for more recent revisions of the SSE instruction set.

 I can
 imagine that a lot of the benefit of using SIMD would be lost if every
 SIMD instruction ends up wrapped in 3-4 more instructions, especially
 if you need to do consecutive operations on the same data.

It will lose 100% of its benefit it it is wrapped up in even ONE function call, and equally so if the vectors don't pass/return in hardware registe=

 as they should.
 I'm crafting it to have the same performance characteristics as 'int'.

Cool, thanks for answering my questions. Some of what I'm working on atm would benefit from simd. -- James Miller
Mar 15 2012
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 15 Mar 2012 14:02:15 -0500, Manu <turkeyman gmail.com> wrote:
 On 15 March 2012 20:35, Robert Jacques <sandford jhu.edu> wrote:
 On Thu, 15 Mar 2012 12:09:58 -0500, Manu <turkeyman gmail.com> wrote:


 This sounds reasonable. However, please realize that if you wish to use
 the short vector names (i.e. float4, float3, float2, etc) you should
 support the full set with a decent range of operations and methods. Several
 people (myself included) have written similar short vector libraries; I
 think having having short vectors in phobos is important, but having one
 library provide float4 and another float2 is less than ideal, even if not
 all of the types could leverage the SMID backend. For myself, the killer
 feature for such a library would be have the CUDA compatible alignments for
 the types. (or an equivalent enum to the effect)

I can see how you come to that conclusion, but I generally feel that that's a problem for a higher layer of library.

Then you should to leave namespace room for that higher level library.
Mar 15 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30334f8fa35f0804bb5a5cab
Content-Type: text/plain; charset=UTF-8

On 16 March 2012 01:32, Robert Jacques <sandford jhu.edu> wrote:

 On Thu, 15 Mar 2012 14:02:15 -0500, Manu <turkeyman gmail.com> wrote:

 On 15 March 2012 20:35, Robert Jacques <sandford jhu.edu> wrote:

 On Thu, 15 Mar 2012 12:09:58 -0500, Manu <turkeyman gmail.com> wrote:


 This sounds reasonable. However, please realize that if you wish to use
 the short vector names (i.e. float4, float3, float2, etc) you should
 support the full set with a decent range of operations and methods.
 Several
 people (myself included) have written similar short vector libraries; I
 think having having short vectors in phobos is important, but having one
 library provide float4 and another float2 is less than ideal, even if not
 all of the types could leverage the SMID backend. For myself, the killer
 feature for such a library would be have the CUDA compatible alignments
 for
 the types. (or an equivalent enum to the effect)

that's a problem for a higher layer of library.

Then you should to leave namespace room for that higher level library.

I haven't stolen any names that aren't already taken by core.simd. I just want to claim those primitive types already aliased in std.simd to enhance them with some more useful base-level functionality. --20cf30334f8fa35f0804bb5a5cab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 16 March 2012 01:32, Robert Jacques <span dir= =3D"ltr">&lt;<a href=3D"mailto:sandford jhu.edu">sandford jhu.edu</a>&gt;</= span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Thu, 15 Mar 2012 14:02:15 -0500, Manu &lt;<a href=3D"m= ailto:turkeyman gmail.com" target=3D"_blank">turkeyman gmail.com</a>&gt; wr= ote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 15 March 2012 20:35, Robert Jacques &lt;<a href=3D"mailto:sandford jhu.e= du" target=3D"_blank">sandford jhu.edu</a>&gt; wrote:<br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Thu, 15 Mar 2012 12:09:58 -0500, Manu &lt;<a href=3D"mailto:turkeyman gm= ail.com" target=3D"_blank">turkeyman gmail.com</a>&gt; wrote:<br> </blockquote></div></blockquote> [snip]<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> This sounds reasonable. However, please realize that if you wish to use<br> the short vector names (i.e. float4, float3, float2, etc) you should<br> support the full set with a decent range of operations and methods. Several= <br> people (myself included) have written similar short vector libraries; I<br> think having having short vectors in phobos is important, but having one<br=

r> all of the types could leverage the SMID backend. For myself, the killer<br=

<br> the types. (or an equivalent enum to the effect)<br> <br> </blockquote> <br></div><div class=3D"im"> I can see how you come to that conclusion, but I generally feel that that&#= 39;s<br> a problem for a higher layer of library.<br> </div></blockquote> <br> Then you should to leave namespace room for that higher level library.<br> </blockquote></div><br><div>I haven&#39;t stolen any names that aren&#39;t = already taken by core.simd. I just want to claim those primitive types alre= ady aliased in std.simd to enhance them with some more useful base-level fu= nctionality.</div> --20cf30334f8fa35f0804bb5a5cab--
Mar 16 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:
 Then you should to leave namespace room for that higher level 
 library.

What makes you thing that there would be only one such high-level library wanting to define a floatN type? There is no such thing as a global namespace in D (well, one could probably argue that the things defined in object are). Thus, I don't see a problem with re-using a name in a third-party library, if its a good fit in both places – and you'll probably have a hard time coming up with a better name for SIMD stuff than float4. If at some point you want to mix types from both modules, you could always use static or renamed imports. For example, »import lowlevel = std.simd« would give you »lowlevel.float4 upVector;«, which might be clearer in the context of your application than any longer, pre-defined name could ever be. True, we shouldn't generally pick very likely-to-collide names by default just because we can so, but denying the existence of the D module system altogether is going to set us back to using library name prefixes everywhere, like in C (and sometimes C++) code. David
Mar 16 2012
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <see klickverbot.at>=
  =

wrote:

 On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:
 Then you should to leave namespace room for that higher level library=


 What makes you thing that there would be only one such high-level  =

 library wanting to define a floatN type?

The fact that several people have proposed unifying the existing librari= es = any putting them into phobos :)
 There is no such thing as a global namespace in D (well, one could  =

 probably argue that the things defined in object are). Thus, I don't s=

 a problem with re-using a name in a third-party library, if its a good=

 fit in both places =E2=80=93 and you'll probably have a hard time comi=

 a better name for SIMD stuff than float4.

 If at some point you want to mix types from both modules, you could  =

 always use static or renamed imports. For example, =C2=BBimport lowlev=

 std.simd=C2=AB would give you =C2=BBlowlevel.float4 upVector;=C2=AB, w=

 clearer in the context of your application than any longer, pre-define=

 name could ever be.

 True, we shouldn't generally pick very likely-to-collide names by  =

 default just because we can so, but denying the existence of the D  =

 module system altogether is going to set us back to using library name=

 prefixes everywhere, like in C (and sometimes C++) code.

 David

Unrelated libraries using the same name is relatively painless. Highly = related libraries that conflict, on the other hand, are generally painfu= l. = Yes, there are a lot of mechanisms available to work around this, but = selective imports and renaming all add to the cognitive load of using an= d = writing the code. To me float4 isn't a SIMD name; its a vector name and if it's implemente= d = using SIMD, great, but that's an implementation detail. I can understand= a = close to the metal SIMD library and encourage the work. But if it isn't = = also going to be a vector library, if possible, it shouldn't use the = vector names.
Mar 16 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3005dc221eb12204bb631fb5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 16 March 2012 22:39, Robert Jacques <sandford jhu.edu> wrote:

 On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <see klickverbot.at>
 wrote:

  On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:
 Then you should to leave namespace room for that higher level library.

What makes you thing that there would be only one such high-level librar=


 wanting to define a floatN type?

The fact that several people have proposed unifying the existing librarie=

 any putting them into phobos :)

I personally can't see it happening. Above the most primitive level that I've tried to cover with std.simd, I think it'll be very hard to find agreement on what that API should look like. If you can invent a proposal that everyone agrees on, I'd be very interested to see it. Perhaps if you extend the fairly raw and D-ish API that I've tried to use in std.simd it could work, but I don't think many people will like using that in their code. I anticipate std.simd will be wrapped in some big bloated class by almost everyone that uses it, so why bother to add the emulation at that level? There is no such thing as a global namespace in D (well, one could probably
 argue that the things defined in object are). Thus, I don't see a proble=


 with re-using a name in a third-party library, if its a good fit in both
 places =E2=80=93 and you'll probably have a hard time coming up with a b=


 for SIMD stuff than float4.

 If at some point you want to mix types from both modules, you could
 always use static or renamed imports. For example, =C2=BBimport lowlevel=


 std.simd=C2=AB would give you =C2=BBlowlevel.float4 upVector;=C2=AB, whi=


 clearer in the context of your application than any longer, pre-defined
 name could ever be.

 True, we shouldn't generally pick very likely-to-collide names by defaul=


 just because we can so, but denying the existence of the D module system
 altogether is going to set us back to using library name prefixes
 everywhere, like in C (and sometimes C++) code.

 David

Unrelated libraries using the same name is relatively painless. Highly related libraries that conflict, on the other hand, are generally painful=

 Yes, there are a lot of mechanisms available to work around this, but
 selective imports and renaming all add to the cognitive load of using and
 writing the code.

 To me float4 isn't a SIMD name; its a vector name and if it's implemented
 using SIMD, great, but that's an implementation detail. I can understand =

 close to the metal SIMD library and encourage the work. But if it isn't
 also going to be a vector library, if possible, it shouldn't use the vect=

 names.

Can you give me an example of a non-simd context where this is the case? Don't say shaders, because that is supported in hardware, and that's my point. Also there's nothing stopping a secondary library adding/emulating the additional types. They could work seamlessly together. flaot4 may come from std.simd, float3/float2 may be added by a further lib that simply extends std.simd. --20cf3005dc221eb12204bb631fb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 16 March 2012 22:39, Robert Jacques <span dir= =3D"ltr">&lt;<a href=3D"mailto:sandford jhu.edu">sandford jhu.edu</a>&gt;</= span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger &lt;<= a href=3D"mailto:see klickverbot.at" target=3D"_blank">see klickverbot.at</= a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Then you should to leave namespace room for that higher level library.<br> </blockquote> <br> What makes you thing that there would be only one such high-level library w= anting to define a floatN type?<br> </blockquote> <br></div> The fact that several people have proposed unifying the existing libraries = any putting them into phobos :)</blockquote><div><br></div><div>I personall= y can&#39;t see it happening. Above the most primitive level that I&#39;ve = tried to cover with std.simd, I think it&#39;ll be very hard to find agreem= ent on what that API should look like.</div> <div>If you can invent a proposal that everyone agrees on, I&#39;d be very = interested to see it. Perhaps if you extend the fairly raw and D-ish API th= at I&#39;ve tried to use in std.simd it could work, but I don&#39;t think m= any people will like using that in their code. I anticipate std.simd will b= e wrapped in some big bloated class by almost everyone that uses it, so why= bother to add the emulation at that level?</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"= im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef= t:1px #ccc solid;padding-left:1ex"> There is no such thing as a global namespace in D (well, one could probably= argue that the things defined in object are). Thus, I don&#39;t see a prob= lem with re-using a name in a third-party library, if its a good fit in bot= h places =E2=80=93 and you&#39;ll probably have a hard time coming up with = a better name for SIMD stuff than float4.<br> <br> If at some point you want to mix types from both modules, you could always = use static or renamed imports. For example, =C2=BBimport lowlevel =3D std.s= imd=C2=AB would give you =C2=BBlowlevel.float4 upVector;=C2=AB, which might= be clearer in the context of your application than any longer, pre-defined= name could ever be.<br> <br> True, we shouldn&#39;t generally pick very likely-to-collide names by defau= lt just because we can so, but denying the existence of the D module system= altogether is going to set us back to using library name prefixes everywhe= re, like in C (and sometimes C++) code.<br> <br> David<br> </blockquote> <br></div> Unrelated libraries using the same name is relatively painless. Highly rela= ted libraries that conflict, on the other hand, are generally painful. Yes,= there are a lot of mechanisms available to work around this, but selective= imports and renaming all add to the cognitive load of using and writing th= e code.<br> <br> To me float4 isn&#39;t a SIMD name; its a vector name and if it&#39;s imple= mented using SIMD, great, but that&#39;s an implementation detail. I can un= derstand a close to the metal SIMD library and encourage the work. But if i= t isn&#39;t also going to be a vector library, if possible, it shouldn&#39;= t use the vector names.<br> </blockquote></div><br><div>Can you give me an example of a non-simd contex= t where this is the case? Don&#39;t say shaders, because that is supported = in hardware, and that&#39;s my point.</div><div>Also there&#39;s nothing st= opping a secondary library adding/emulating the additional types. They coul= d work seamlessly together. flaot4 may come from std.simd, float3/float2 ma= y be added by a further lib that simply extends std.simd.</div> --20cf3005dc221eb12204bb631fb5--
Mar 16 2012
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 16 Mar 2012 16:45:05 -0500, Manu <turkeyman gmail.com> wrote:
 On 16 March 2012 22:39, Robert Jacques <sandford jhu.edu> wrote:
 On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <see klickverbot.at>
 wrote:
  On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:


[snip]
 Unrelated libraries using the same name is relatively painless. Highly
 related libraries that conflict, on the other hand, are generally painful.
 Yes, there are a lot of mechanisms available to work around this, but
 selective imports and renaming all add to the cognitive load of using and
 writing the code.

 To me float4 isn't a SIMD name; its a vector name and if it's implemented
 using SIMD, great, but that's an implementation detail. I can understand a
 close to the metal SIMD library and encourage the work. But if it isn't
 also going to be a vector library, if possible, it shouldn't use the vector
 names.

Can you give me an example of a non-simd context where this is the case? Don't say shaders, because that is supported in hardware, and that's my point. Also there's nothing stopping a secondary library adding/emulating the additional types. They could work seamlessly together. flaot4 may come from std.simd, float3/float2 may be added by a further lib that simply extends std.simd.

Shaders. :) Actually, float4 isn't supported in hardware if you're on NVIDIA. And IIRC ATI/AMD is moving away from hardware support as well. I'm not sure what Intel or the embedded GPUs do. On the CPU side SIMD support on both ARM and PowerPC is optional. As for examples, pretty much every graphics, vision, imaging and robotics library has a small vector library attached to it; were you looking for something else? Also, clean support for float3 / float2 / etc. has shown up in Intel's Larrabee and its Knight's derivatives; so, maybe we'll see it in a desktop processor someday. To say nothing of the 245-bit and 512-bit SIMD units on some machines. My concern is that std.simd is (for good reason) leaking the underlying hardware implementation (std.simd seems to be very x86 centric), while vectors, in my mind, are a higher level abstraction.
Mar 17 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
--bcaec517aca0baf8ee04bb7524d3
Content-Type: text/plain; charset=UTF-8

On 17 March 2012 20:42, Robert Jacques <sandford jhu.edu> wrote:

 On Fri, 16 Mar 2012 16:45:05 -0500, Manu <turkeyman gmail.com> wrote:

 Can you give me an example of a non-simd context where this is the case?

 point.
 Also there's nothing stopping a secondary library adding/emulating the
 additional types. They could work seamlessly together. flaot4 may come
 from
 std.simd, float3/float2 may be added by a further lib that simply extends
 std.simd.

Shaders. :) Actually, float4 isn't supported in hardware if you're on NVIDIA. And IIRC ATI/AMD is moving away from hardware support as well. I'm not sure what Intel or the embedded GPUs do. On the CPU side SIMD support on both ARM and PowerPC is optional. As for examples, pretty much every graphics, vision, imaging and robotics library has a small vector library attached to it; were you looking for something else?

GPU hardware is fundamentally different than CPU vector extensions. The goal is not to imitate shaders on the CPU. There are already other possibilities for that anyway. Also, clean support for float3 / float2 / etc. has shown up in Intel's
 Larrabee and its Knight's derivatives; so, maybe we'll see it in a desktop
 processor someday. To say nothing of the 245-bit and 512-bit SIMD units on
 some machines.

Well when that day comes, we'll add hardware abstraction for it. There are 2 that do currently exist, 3DNow, but that's so antiquated, I see no reason to support it. The other is the Gamecube, Wii, WiiU line of consoles; all have 2D vector hardware. I'll gladly add support for that the very moment anyone threatens to use D on a Nintendo system, but no point right now. float3 on the other hand is not supported on any machine, and it's very inefficient. Use of float3 should be discouraged at all costs. People should be encouraged to use float4's and pack something useful in W if they can. And if not, they should be aware that they are wasting 25% of their flops. I don't recall ever dismissing 256bit vector units. Infact I've suggested support for AVX is mandatory on plenty of occasions. I'm also familiar with a few 512bit vector architectures, but I don't think they warrant a language level implementation yet. Let's just work through what we have, and what will be used to start with. I'd be keen to see how it tends to be used, and make any fundamental changes before blowing it way out of proportion.
 My concern is that std.simd is (for good reason) leaking the underlying
 hardware implementation (std.simd seems to be very x86 centric), while
 vectors, in my mind, are a higher level abstraction.

It's certainly not SSE centric. Actually, if you can legitimately criticise me of anything, it's being biased AGAINST x86 based processors. I'm critically aware of VMX, NEON, SPU, and many architectures that came before. What parts of my current work in progress do you suggest is biased to x86 hardware implementation? From my experience, I'm fairly happy with how it looks at this point being an efficiency-first architecture-abstracted interface. As I've said, I'm still confident that people will just come along and wrap it up with what they feel is a simple/user-friendly interface anyway. If I try to make this higher-level/more-user-friendly, I still won't please everyone, and I'll sacrifice raw efficiency in the process, which defeats the purpose. How do you define vectors in your mind? --bcaec517aca0baf8ee04bb7524d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 17 March 2012 20:42, Robert Jacques <span dir= =3D"ltr">&lt;<a href=3D"mailto:sandford jhu.edu">sandford jhu.edu</a>&gt;</= span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Fri, 16 Mar 2012 16:45:05 -0500, Manu &lt;<a href=3D"m= ailto:turkeyman gmail.com" target=3D"_blank">turkeyman gmail.com</a>&gt; wr= ote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">Can you give me an e= xample of a non-simd context where this is the case?</div></blockquote><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> <div class=3D"im"> Don&#39;t say shaders, because that is supported in hardware, and that&#39;= s my<br> point.<br> Also there&#39;s nothing stopping a secondary library adding/emulating the<= br> additional types. They could work seamlessly together. flaot4 may come from= <br> std.simd, float3/float2 may be added by a further lib that simply extends<b= r> std.simd.<br> </div></blockquote> <br> Shaders. :) Actually, float4 isn&#39;t supported in hardware if you&#39;re = on NVIDIA. And IIRC ATI/AMD is moving away from hardware support as well. I= &#39;m not sure what Intel or the embedded GPUs do. On the CPU side SIMD su= pport on both ARM and PowerPC is optional. As for examples, pretty much eve= ry graphics, vision, imaging and robotics library has a small vector librar= y attached to it; were you looking for something else?<br> </blockquote><div><br></div><div>GPU hardware is fundamentally different th= an CPU vector extensions. The goal is not to=C2=A0imitate=C2=A0shaders on t= he CPU. There are already other possibilities for that anyway.</div><div><b= r></div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Also, clean support for float3 / float2 / etc. has shown up in Intel&#39;s = Larrabee and its Knight&#39;s derivatives; so, maybe we&#39;ll see it in a = desktop processor someday. To say nothing of the 245-bit and 512-bit SIMD u= nits on some machines.<br> </blockquote><div><br></div><div>Well when that day comes, we&#39;ll add ha= rdware abstraction for it. There are 2 that do currently exist, 3DNow, but = that&#39;s so antiquated, I see no reason to support it. The other is the G= amecube, Wii, WiiU line of consoles; all have 2D vector hardware. I&#39;ll = gladly add support for that the very moment anyone threatens to use D on a = Nintendo system, but no point right now.</div> <div><br></div><div>float3 on the other hand is not supported on any machin= e, and it&#39;s very inefficient. Use of float3 should be discouraged at al= l costs. People should be encouraged to use float4&#39;s and pack something= useful in W if they can. And if not, they should be aware that they are wa= sting 25% of their flops.</div> <div><br></div><div>I don&#39;t recall ever dismissing 256bit vector units.= Infact I&#39;ve suggested support for AVX is mandatory on plenty of occasi= ons. I&#39;m also familiar with a few 512bit vector architectures, but I do= n&#39;t think they warrant a language level implementation yet. Let&#39;s j= ust work through what we have, and what will be used to start with. I&#39;d= be keen to see how it tends to be used, and make any fundamental changes b= efore blowing it way out of=C2=A0proportion.</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex">My concern is that std.simd= is (for good reason) leaking the underlying hardware implementation (std.s= imd seems to be very x86 centric), while vectors, in my mind, are a higher = level abstraction.<br> </blockquote></div><br><div>It&#39;s certainly not SSE centric. Actually, i= f you can=C2=A0legitimately=C2=A0criticise me of anything, it&#39;s being b= iased AGAINST x86 based processors. I&#39;m critically aware of VMX, NEON, = SPU, and many architectures that came before.</div> <div>What parts of my current work in progress=C2=A0do you suggest=C2=A0is = biased to x86 hardware implementation? From my experience, I&#39;m fairly h= appy with how it looks at this point being an efficiency-first architecture= -abstracted interface.</div> <div><br></div><div>As I&#39;ve said,=C2=A0I&#39;m still confident that peo= ple will just come along and wrap it up with what they feel is a simple/use= r-friendly interface anyway. If I try to make this higher-level/more-user-f= riendly, I still won&#39;t please everyone, and I&#39;ll sacrifice raw effi= ciency in the process, which defeats the purpose.</div> <div><br></div><div>How do you define vectors in your mind?</div> --bcaec517aca0baf8ee04bb7524d3--
Mar 17 2012