Re: SIMD support...

+1 On Wed, Jan 18, 2012 at 4:35 AM, Simen Kjærås wrote: > On Tue, 17 Jan 2012 13:52:01 +0100, David wrote: > > Am 16.01.2012 23:28, schrieb Simen Kjærås: >> >>> To make it all the easier for those who want to make games in D? >>> >> >> Then they can get my lib easily from bitbucket. >> > > Or a

Re: SIMD support...

On Tue, 17 Jan 2012 13:52:01 +0100, David wrote: Am 16.01.2012 23:28, schrieb Simen Kjærås: To make it all the easier for those who want to make games in D? Then they can get my lib easily from bitbucket. Or any one of a 100 other places, with incompatible implementations? Vectors and mat

Re: SIMD support...

Am 16.01.2012 23:28, schrieb Simen Kjærås: To make it all the easier for those who want to make games in D? Then they can get my lib easily from bitbucket. IMO, we should have vectors, matrices, quaternions and all those other neat things easily accessible in the language (dual quaternions?

Re: SIMD support...

On 17 January 2012 14:43, David wrote: > Am 17.01.2012 05:31, schrieb Kiith-Sa: > > David wrote: >> >> Am 16.01.2012 03:54, schrieb JoeCoder: >>> On 1/15/2012 1:42 PM, Walter Bright wrote: > > A nice vector math library for D that puts us competitive will be a > nice >

Re: SIMD support...

Am 17.01.2012 05:31, schrieb Kiith-Sa: David wrote: Am 16.01.2012 03:54, schrieb JoeCoder: On 1/15/2012 1:42 PM, Walter Bright wrote: A nice vector math library for D that puts us competitive will be a nice addition to Phobos. The gl3n library might be something good to build on: https://b

Re: SIMD support...

On 1/16/2012 7:21 PM, Danni Coy wrote: (dual quaternions? Are they used in games?) yes While the GPU tends to do this particular step of the work, the answer in general is 'definitely'. One of the most immediate applications of dual quats was to improve the image quality of joints

Re: SIMD support...

David wrote: > Am 16.01.2012 03:54, schrieb JoeCoder: >> On 1/15/2012 1:42 PM, Walter Bright wrote: >>> >>> A nice vector math library for D that puts us competitive will be a nice >>> addition to Phobos. >> >> The gl3n library might be something good to build on: >> https://bitbucket.org/dav1d/gl

Re: SIMD support...

> > (dual quaternions? Are they > used in games?) > > yes

Re: SIMD support...

On 16 January 2012 22:32, JoeCoder wrote: > On 1/16/2012 4:26 PM, David wrote: >> >> Why does phobos, the std. lib, need a vector-lib? I haven't seen any >> other language with something like gl3n in the std. > > > I guess this depends on the goals for phobos.  Is it minimal, or batteries > includ

Re: SIMD support...

On 1/16/2012 4:26 PM, David wrote: Why does phobos, the std. lib, need a vector-lib? I haven't seen any other language with something like gl3n in the std. I guess this depends on the goals for phobos. Is it minimal, or batteries included? As for not seeing it in other languages, I don't th

Re: SIMD support...

On Mon, 16 Jan 2012 22:26:55 +0100, David wrote: Am 16.01.2012 03:54, schrieb JoeCoder: On 1/15/2012 1:42 PM, Walter Bright wrote: A nice vector math library for D that puts us competitive will be a nice addition to Phobos. The gl3n library might be something good to build on: https://b

Re: SIMD support...

On 1/16/2012 1:26 PM, David wrote: PS:// I already talked with Manu about this topic, and I don't wait too long, gl3n will have core.simd support soon. Awesome. I was hoping that adding simd support would have a an "enabling" effect for a lot of great library improvements!

Re: SIMD support...

Am 16.01.2012 03:54, schrieb JoeCoder: On 1/15/2012 1:42 PM, Walter Bright wrote: A nice vector math library for D that puts us competitive will be a nice addition to Phobos. The gl3n library might be something good to build on: https://bitbucket.org/dav1d/gl3n It looks to be a continuation

Re: SIMD support...

On Monday, 16 January 2012 at 19:27:16 UTC, F i L wrote: Whoops! opBinary should be opOpAssign in my examples. wait... no, opBinary was the right one... i'm confusing myself here :D

Re: SIMD support...

Whoops! opBinary should be opOpAssign in my examples.

Re: SIMD support...

On Monday, 16 January 2012 at 17:57:38 UTC, suicide wrote: Here is mine: http://suicide.zoadian.de/ext/math/geometry/vector.d i haven't tested (not even compiled) it yet. It needs polishing, but i have not much time to work on it atm. But you may use it as you wish ;) Any suggestions/improveme

Re: SIMD support...

On 1/16/2012 5:06 AM, Marco Leise wrote: I bet there are more programs that could benefit from SSE than is obvious or code that could be rewritten in way, that multiple data sets can be processed simultaneous. I think there's quite a bit more, it's just that using SIMD instructions has histori

Re: SIMD support...

Here is mine: http://suicide.zoadian.de/ext/math/geometry/vector.d i haven't tested (not even compiled) it yet. It needs polishing, but i have not much time to work on it atm. But you may use it as you wish ;) Any suggestions/improvement is welcome. Greetings, Felix Am 16.01.2012, 04:00 Uhr

Re: SIMD support...

Am 15.01.2012, 11:45 Uhr, schrieb Manu : On 15 January 2012 08:16, Sean Cavanaugh wrote: On 1/15/2012 12:09 AM, Walter Bright wrote: On 1/14/2012 9:58 PM, Sean Cavanaugh wrote: MS has three types, __m128, __m128i and __m128d (float, int, double) Six if you count AVX's 256 forms. On 1/

Re: SIMD support...

On 1/15/2012 6:54 PM, JoeCoder wrote: On 1/15/2012 1:42 PM, Walter Bright wrote: A nice vector math library for D that puts us competitive will be a nice addition to Phobos. The gl3n library might be something good to build on: https://bitbucket.org/dav1d/gl3n It looks to be a continuation o

Re: SIMD support...

On 1/15/2012 1:42 PM, Walter Bright wrote: A nice vector math library for D that puts us competitive will be a nice addition to Phobos. The gl3n library might be something good to build on: https://bitbucket.org/dav1d/gl3n It looks to be a continuation of the OMG library used by Deadlock, and

Re: SIMD support...

On 1/15/2012 3:02 AM, Manu wrote: On 15 January 2012 09:20, Sean Cavanaugh A nice vector math library for D that puts us competitive will be a nice addition to Phobos.

Re: SIMD support...

On 15 January 2012 09:20, Sean Cavanaugh wrote: > On 1/13/2012 7:38 AM, Manu wrote: > >> On 13 January 2012 08:34, Norbert Nemec > > wrote: >> >> >> This has already been concluded some days back, the language has a quite >> of types, just like GCC. >> > > So I

Re: SIMD support...

On 15 January 2012 08:16, Sean Cavanaugh wrote: > On 1/15/2012 12:09 AM, Walter Bright wrote: > >> On 1/14/2012 9:58 PM, Sean Cavanaugh wrote: >> >>> MS has three types, __m128, __m128i and __m128d (float, int, double) >>> >>> Six if you count AVX's 256 forms. >>> >>> On 1/7/2012 6:54 PM, Peter A

Re: SIMD support...

On 1/13/2012 7:38 AM, Manu wrote: On 13 January 2012 08:34, Norbert Nemec mailto:norb...@nemec-online.de>> wrote: This has already been concluded some days back, the language has a quite of types, just like GCC. So I would definitely like to help out on the SIMD stuff in some way, as I have

Re: SIMD support...

On 1/14/2012 2:11 AM, Mehrdad wrote: In case this is at all helpful... [see attached] Hope you like the new simd compiler stuff.

Re: SIMD support...

On 1/15/2012 12:09 AM, Walter Bright wrote: On 1/14/2012 9:58 PM, Sean Cavanaugh wrote: MS has three types, __m128, __m128i and __m128d (float, int, double) Six if you count AVX's 256 forms. On 1/7/2012 6:54 PM, Peter Alexander wrote: On 7/01/12 9:28 PM, Andrei Alexandrescu wrote: I agree wit

Re: SIMD support...

On 1/6/2012 7:58 PM, Manu wrote: On 7 January 2012 03:46, Vladimir Panteleev mailto:vladi...@thecybershadow.net>> wrote: I've never seen a memcpy on any console system I've ever worked on that takes advantage if its large registers... writing a fast memcpy is usually one of the first things we d

Re: SIMD support...

On 1/14/2012 9:58 PM, Sean Cavanaugh wrote: MS has three types, __m128, __m128i and __m128d (float, int, double) Six if you count AVX's 256 forms. On 1/7/2012 6:54 PM, Peter Alexander wrote: On 7/01/12 9:28 PM, Andrei Alexandrescu wrote: I agree with Manu that we should just have a single type

Re: SIMD support...

On 1/6/2012 9:44 AM, Manu wrote: On 6 January 2012 17:01, Russel Winder mailto:rus...@russel.org.uk>> wrote: As said, I think these questions are way outside the scope of SIMD vector libraries ;) Although this is a fundamental piece of the puzzle, since GPGPU is no use without SIMD type expressio

Re: SIMD support...

MS has three types, __m128, __m128i and __m128d (float, int, double) Six if you count AVX's 256 forms. On 1/7/2012 6:54 PM, Peter Alexander wrote: On 7/01/12 9:28 PM, Andrei Alexandrescu wrote: I agree with Manu that we should just have a single type like __m128 in MSVC. The other types and th

Re: SIMD support...

On 13 January 2012 08:34, Norbert Nemec wrote: > On 12.01.2012 23:10, Peter Alexander wrote: > >> On 12/01/12 8:13 PM, Norbert Nemec wrote: >> >>> Considering these hardware details of the SSE architecture alone, I fear >>> that portable low-level support for SIMD is very hard to achieve. If you

Re: SIMD support...

On 12.01.2012 23:10, Peter Alexander wrote: On 12/01/12 8:13 PM, Norbert Nemec wrote: Considering these hardware details of the SSE architecture alone, I fear that portable low-level support for SIMD is very hard to achieve. If you want to offer access to the raw power of each architecture, it m

Re: SIMD support...

On 12/01/12 8:13 PM, Norbert Nemec wrote: Considering these hardware details of the SSE architecture alone, I fear that portable low-level support for SIMD is very hard to achieve. If you want to offer access to the raw power of each architecture, it might be simpler to have machine-specific lang

Re: SIMD support...

On 1/12/2012 12:13 PM, Norbert Nemec wrote: A type v128 would not provide the necessary information for the compiler to produce the correct mov statements. There definitely must be a float4 and a double2 type to express these semantics. For integers, I am not quite sure. I believe that integer S

Re: SIMD support...

On 06.01.2012 02:42, Manu wrote: I like v128, or something like that. I'll use that for the sake of this document. I think it is preferable to float4 for a few reasons... I do not agree at all. That way, the type looses all semantic information. This is not only breaking with C/C++/D philosoph

Re: SIMD support...

On 11-01-2012 13:23, Piotr Szturmaj wrote: Danni Coy wrote: I was rather under that only the new html5 api would be available under windows 8 arm - that they were doing a iOS walled garden type thing with it - if true this could make things difficult... http://www.microsoft.com/presspass/exec/

Re: SIMD support...

Danni Coy wrote: I was rather under that only the new html5 api would be available under windows 8 arm - that they were doing a iOS walled garden type thing with it - if true this could make things difficult... http://www.microsoft.com/presspass/exec/ssinofsky/2011/09-13BUILD.mspx?rss_fdn=Custo

Re: SIMD support...

I was rather under that only the new html5 api would be available under windows 8 arm - that they were doing a iOS walled garden type thing with it - if true this could make things difficult... On Wed, Jan 11, 2012 at 9:42 PM, Piotr Szturmaj wrote: > Trass3r wrote: > >> On Friday, 6 January 2012

Re: SIMD support...

Trass3r wrote: On Friday, 6 January 2012 at 19:53:52 UTC, Manu wrote: Iain should be able to expose the vector types in GDC, and I can work from there, and hopefully even build an ARM/PPC toolchain to experiment with the library in a cross platform environment. On Windoze? You're a masochist ^

Re: SIMD support...

On Sun, 08 Jan 2012 18:56:04 +0100, Peter Alexander wrote: On 8/01/12 5:02 PM, Martin Nowak wrote: simdop will need more overloads, e.g. some instructions need immediate bytes. z = simdop(SHUFPS, x, y, 0); How about this: __v128 simdop(T...)(SIMD op, T args); These don't make a lot of sen

Re: SIMD support...

On 8 January 2012 19:56, Peter Alexander wrote: > These don't make a lot of sense to return as value, e.g. > > __v128 a, b; > a = simdop(movhlps, b); // ??? > > movhlps moves the top 64-bits of b into the bottom 64-bits of a. Can't be > done as an expression like this. > The conventional way is t

Re: SIMD support...

On 8/01/12 5:02 PM, Martin Nowak wrote: simdop will need more overloads, e.g. some instructions need immediate bytes. z = simdop(SHUFPS, x, y, 0); How about this: __v128 simdop(T...)(SIMD op, T args); These don't make a lot of sense to return as value, e.g. __v128 a, b; a = simdop(movhlps, b)

Re: SIMD support...

simdop will need more overloads, e.g. some instructions need immediate bytes. z = simdop(SHUFPS, x, y, 0); How about this: __v128 simdop(T...)(SIMD op, T args);

Re: SIMD support...

On 8 January 2012 11:56, a wrote: > On Sunday, 8 January 2012 at 01:48:34 UTC, Manu wrote: > >> On 8 January 2012 03:44, Walter Bright >> wrote: >> >> On 1/7/2012 4:54 PM, Peter Alexander wrote: >>> >>> I think it simply requires a lot of work in the compiler. >>> Not that much work.

Re: SIMD support...

On Sunday, 8 January 2012 at 01:48:34 UTC, Manu wrote: On 8 January 2012 03:44, Walter Bright wrote: On 1/7/2012 4:54 PM, Peter Alexander wrote: I think it simply requires a lot of work in the compiler. Not that much work. Most of it segues nicely into the previous work I did supportin

Re: SIMD support...

On 1/7/2012 6:32 PM, Peter Alexander wrote: On 64-bit, floats are stored in XMM registers (just as single scalars). Yes. I don't think it does any vectorization yet though. Right. It doesn't do that. It does mean that the register allocation of those registers is already complete though.

Re: SIMD support...

On 1/7/2012 5:32 PM, Manu wrote: Here are some points we discussed... how do we do these (efficiently) in a library? Another issue - matching the name mangling and parameter passing/return conventions of how other C/C++ compilers deal with vector types. That is currently not doable with a li

Re: SIMD support...

On 8/01/12 1:48 AM, Manu wrote: On 8 January 2012 03:44, Walter Bright mailto:newshou...@digitalmars.com>> wrote: On 1/7/2012 4:54 PM, Peter Alexander wrote: I think it simply requires a lot of work in the compiler. Not that much work. Most of it segues nicely into the previou

Re: SIMD support...

On 8/01/12 1:32 AM, Manu wrote: On 8 January 2012 02:54, Peter Alexander mailto:peter.alexander...@gmail.com>> wrote: I agree with Manu that we should just have a single type like __m128 in MSVC. The other types and their conversions should be solvable in a library with something lik

Re: SIMD support...

On 8 January 2012 03:44, Walter Bright wrote: > On 1/7/2012 4:54 PM, Peter Alexander wrote: > >> I think it simply requires a lot of work in the compiler. >> > > Not that much work. Most of it segues nicely into the previous work I did > supporting the XMM floating point code gen. > What is this

Re: SIMD support...

On 1/7/2012 4:54 PM, Peter Alexander wrote: I think it simply requires a lot of work in the compiler. Not that much work. Most of it segues nicely into the previous work I did supporting the XMM floating point code gen.

Re: SIMD support...

On 8 January 2012 02:54, Peter Alexander wrote: > I agree with Manu that we should just have a single type like __m128 in > MSVC. The other types and their conversions should be solvable in a library > with something like strong typedefs. > Walter put in a reasonable effort to sway me to his side

Re: SIMD support...

On 8/01/12 12:14 AM, Walter Bright wrote: On 1/7/2012 1:28 PM, Andrei Alexandrescu wrote: But most always it's NOT, and definitely not in the context of a complex data structure like a hash table. I also think that adding a hecatomb of built-in types and functions has smells, though to a good ex

Re: SIMD support...

On 7/01/12 9:28 PM, Andrei Alexandrescu wrote: What's built inside the compiler is like axioms in math, and what's library is like theorems supported by the axioms. A good language, just like a good mathematical system, has few axioms and many theorems. That means the system is coherent and expre

Re: SIMD support...

Walter: > I don't think that is entirely fair in regards to the SIMD stuff. It reminds > me > of after I spent a couple years at Caltech, where every class was essentially > a > math class. I think that in several (but not all) fields of science and technology your limits are often determine

Re: SIMD support...

On 1/7/2012 1:28 PM, Andrei Alexandrescu wrote: Having a pluggable interface so the implementation can be changed is all right, as long as the binary API does not change. If the binary API changes, then of course, two different libraries cannot be linked together. I strongly oppose any changes wh

Re: SIMD support...

On 1/7/12 12:48 PM, Walter Bright wrote: On 1/7/2012 8:10 AM, Don wrote: Moving AAs from a built-in to a library type has been an unmitigated disaster from the implementation side. And it has so far brought us *nothing* in return. Not "hardly anything", but *NOTHING*. I don't even have any idea

Re: SIMD support...

On 1/7/2012 8:10 AM, Don wrote: Moving AAs from a built-in to a library type has been an unmitigated disaster from the implementation side. And it has so far brought us *nothing* in return. Not "hardly anything", but *NOTHING*. I don't even have any idea of what good could possibly come from it.

Re: SIMD support...

On 01/07/12 17:10, Don wrote: > On 07.01.2012 04:18, Andrei Alexandrescu wrote: > Also consider how the hard-coding of associative arrays in >> an awkward interface inside the runtime has stifled efficient >> implementations, progress, and innovation in that area. Still a lot of >> work needed ther

Re: SIMD support...

On Saturday, 7 January 2012 at 16:55:00 UTC, Andrei Alexandrescu wrote: Well they are broken because the change has not been carried to completion. Here's my position: if we get a library implementation that works better than the compiler implementation, let's do it. If they are equal in use o

Re: SIMD support...

On 1/7/12 10:19 AM, Adam D. Ruppe wrote: On Saturday, 7 January 2012 at 16:10:32 UTC, Don wrote: Sorry Andrei, I have to disagree with that in the strongest possible terms. I would have mentioned AAs as a very strong argument in the opposite direction! Amen. AAs are *still* broken from this ch

Re: SIMD support...

On 1/7/12 10:10 AM, Don wrote: Sorry Andrei, I have to disagree with that in the strongest possible terms. I would have mentioned AAs as a very strong argument in the opposite direction! Moving AAs from a built-in to a library type has been an unmitigated disaster from the implementation side. A

Re: SIMD support...

On Saturday, 7 January 2012 at 16:10:32 UTC, Don wrote: Sorry Andrei, I have to disagree with that in the strongest possible terms. I would have mentioned AAs as a very strong argument in the opposite direction! Amen. AAs are *still* broken from this change. If you take a look at my cgi.d, you

Re: SIMD support...

On 07.01.2012 04:18, Andrei Alexandrescu wrote: On 1/6/12 5:52 PM, Walter Bright wrote: Support the 10 vector types as basic types, support them with the arithmetic infix operators, and use intrinsics for the rest of the operations. I believe this scheme: 1. will look better in code, and will b

Re: SIMD support...

On 01/06/12 21:16, Walter Bright wrote: > Aligning to non-powers of 2 will never work. As for other alignments, they > only will work if the underlying storage is aligned to that or greater. > Otherwise, you'll have to resort to the method outlined above. > > >> What about GCC? Will/does it sup

Re: SIMD support...

On 01/07/12 04:27, Martin Nowak wrote: > __v128 add(__v128 a, __v128 b) pure > { > __v128 res = a; > asm (res, b) > { > ADD res, b; > } > return res; > } > This is effectively achieves the same as writing this with intrinsics. > It also greatly improves the composition

Re: SIMD support...

On Sat, 07 Jan 2012 01:06:21 +0100, Walter Bright wrote: On 1/6/2012 1:43 PM, Manu wrote: There is actually. To the compiler, the intrinsic is a normal function, with some hook in the code generator to produce the appropriate opcode when it's performing actual code generation. On most co

Re: SIMD support...

On 1/6/12 5:52 PM, Walter Bright wrote: Support the 10 vector types as basic types, support them with the arithmetic infix operators, and use intrinsics for the rest of the operations. I believe this scheme: 1. will look better in code, and will be easier to use 2. will allow for better error de

Re: SIMD support...

On Friday, 6 January 2012 at 19:11:27 UTC, Brad Roberts wrote: On 1/6/2012 3:32 AM, Vladimir Panteleev wrote: On Friday, 6 January 2012 at 03:17:55 UTC, Walter Bright wrote: Something about the way you are posting is breaking the threading of these message threads. This is because the mailing

Re: SIMD support...

On 7 January 2012 03:46, Vladimir Panteleev wrote: > On Friday, 6 January 2012 at 20:26:37 UTC, Walter Bright wrote: > >> On 1/6/2012 11:16 AM, Brad Roberts wrote: >> >>> However, a counter example, it'd be a lot easier to write a memcpy >>> routine that uses them >>> without having to resort to a

Re: SIMD support...

On Friday, 6 January 2012 at 20:26:37 UTC, Walter Bright wrote: On 1/6/2012 11:16 AM, Brad Roberts wrote: However, a counter example, it'd be a lot easier to write a memcpy routine that uses them without having to resort to asm code under this theoretical model. I would seriously argue that i

Re: SIMD support...

On 7 January 2012 02:52, Walter Bright wrote: > MS also agree that the primitive __m128 is the right approach. I'm not >> basing my > > opinion on their judgement at all, I independently conclude it is the right >> approach, but it's encouraging that they agree... and perhaps they're a >> more >>

Re: SIMD support...

On 1/6/2012 4:12 PM, Manu wrote: Come on IRC? This requires involved conversation. I'm on skype. I'm sure you realise how much more work this is... Actually, not that much. Surprising, no? I already think I did the hard stuff already by supporting SIMD for float/double. Why would you

Re: SIMD support...

On 7 January 2012 00:38, Manu wrote: > On 7 January 2012 02:00, Walter Bright wrote: >> >> On 1/6/2012 12:45 PM, Manu wrote: >>> >>> In computer graphics it's common to work with float16's, a type not >>> supported by >>> >>> simd units. Pack/Unpack code involved detailed float/int interaction. >

Re: SIMD support...

On 7 January 2012 02:00, Walter Bright wrote: > On 1/6/2012 12:45 PM, Manu wrote: > >> In computer graphics it's common to work with float16's, a type not >> supported by > > simd units. Pack/Unpack code involved detailed float/int interaction. >> You might take a register of floats, then mask th

Re: SIMD support...

On 1/6/2012 4:15 PM, Manu wrote: And I agree this is exactly correct for the IA... and also why intrinsics must be used to do this work, not IA. Yup.

Re: SIMD support...

Walter: > I've worked a lot with large assembler programs. As you know, EAX has no > type. > The assembler code would constantly shift the type of things that were in > EAX, > sometimes a pointer, sometimes an int, sometimes a ushort, sometimes treating > a > pointer as an int, etc. I can un

Re: SIMD support...

On 7 January 2012 02:06, Walter Bright wrote: > On 1/6/2012 1:43 PM, Manu wrote: > >> There is actually. To the compiler, the intrinsic is a normal function, >> with >> some hook in the code generator to produce the appropriate opcode when >> it's >> performing actual code generation. >> On most

Re: SIMD support...

On 7 January 2012 01:52, Walter Bright wrote: > On 1/6/2012 1:32 PM, Manu wrote: > >> Yeah sure, but I don't think that's fundamentally correct, if you're >> drifting > > towards typing these things in the language, then you should also start >> considering cast mechanics... and that's a larger t

Re: SIMD support...

On 1/6/2012 1:43 PM, Manu wrote: There is actually. To the compiler, the intrinsic is a normal function, with some hook in the code generator to produce the appropriate opcode when it's performing actual code generation. On most compilers, the inline asm on the other hand, is unknown to the compi

Re: SIMD support...

On 1/6/2012 12:45 PM, Manu wrote: Here are some examples of tight interacting between int/float, and interacting ON floats with int operations... Naturally the examples I present will be wrapped as useful functions in libraries, but the primitive type shouldn't try and make this more annoying by

Re: SIMD support...

On 1/6/2012 1:32 PM, Manu wrote: On 6 January 2012 22:36, Walter Bright mailto:newshou...@digitalmars.com>> wrote: To me, the advantage of making the SIMD types typed are: 1. the language does typechecking, for example, trying to add a vector of 4 flo

Re: SIMD support...

On 7 January 2012 01:34, Walter Bright wrote: > On 1/6/2012 1:46 PM, Manu wrote: > >> For some reason Walter seems to have done a bit of a 180 in the last few >> hours ;) >> > > It must be the drugs! > That's what I was starting to suspect too! :P

Re: SIMD support...

On 7 January 2012 00:47, Iain Buclaw wrote: > On 6 January 2012 22:37, Manu wrote: > > On 6 January 2012 23:59, Iain Buclaw wrote: > >> > >> On 6 January 2012 19:53, Manu wrote: > >> > ...I'm using DMD on windows... x32. So this isn't ideal ;) > >> > Although with this change, Iain should be a

Re: SIMD support...

On 1/6/2012 1:46 PM, Manu wrote: For some reason Walter seems to have done a bit of a 180 in the last few hours ;) It must be the drugs!

Re: SIMD support...

On Friday, 6 January 2012 at 19:53:52 UTC, Manu wrote: Iain should be able to expose the vector types in GDC, and I can work from there, and hopefully even build an ARM/PPC toolchain to experiment with the library in a cross platform environment. On Windoze? You're a masochist ^^

Re: SIMD support...

On 6 January 2012 22:37, Manu wrote: > On 6 January 2012 23:59, Iain Buclaw wrote: >> >> On 6 January 2012 19:53, Manu wrote: >> > ...I'm using DMD on windows... x32. So this isn't ideal ;) >> > Although with this change, Iain should be able to expose the vector >> > types in >> > GDC, and I can

Re: SIMD support...

On 6 January 2012 23:59, Iain Buclaw wrote: > On 6 January 2012 19:53, Manu wrote: > > ...I'm using DMD on windows... x32. So this isn't ideal ;) > > Although with this change, Iain should be able to expose the vector > types in > > GDC, and I can work from there, and hopefully even build an ARM

Re: SIMD support...

On 6 January 2012 19:53, Manu wrote: > On 6 January 2012 21:34, Walter Bright wrote: >> >> On 1/6/2012 11:08 AM, Manu wrote: >>> >>> I think we should take this conversation to IRC, or a separate thread? >>> I'll generate some examples from VC for you in various situations. If you >>> can >>> wri

Re: SIMD support...

On 6/01/12 4:28 AM, Martin Nowak wrote: I also don't think that we can efficiently provide arbitrary alignment for stack variables. The performance penalty will kill your efforts. Gcc doesn't do it either. Vector registers are usually plentiful, so spilling to stack is rare. An (additional) pe

Re: SIMD support...

On 6 January 2012 23:23, Andrei Alexandrescu wrote: > On 1/6/12 1:11 PM, Walter Bright wrote: > >> On 1/6/2012 10:25 AM, Brad Roberts wrote: >> >>> How is making __v128 a builtin type better than defining it as: >>> >>> align(16) struct __v128 >>> { >>> ubyte[16] data; >>> } >>> >> >> Then the bac

Re: SIMD support...

On 6 January 2012 22:40, Martin Nowak wrote: > On Fri, 06 Jan 2012 20:00:15 +0100, Manu wrote: > > On 6 January 2012 20:17, Martin Nowak wrote: >> >> There is another benefit. >>> Consider the following: >>> >>> __vec128 addps(__vec128 a, __vec128 b) pure >>> { >>> __vec128 res = a; >>> >>>

Re: SIMD support...

On 6 January 2012 22:36, Walter Bright wrote: >To me, the advantage of making the SIMD types typed are: >> >>1. the language does typechecking, for example, trying to add a vector >> of 4 >>floats to 16 bytes would be (and should be) an error. >> >> >> The language WILL do that checki

Re: SIMD support...

On 1/6/12 1:11 PM, Walter Bright wrote: On 1/6/2012 10:25 AM, Brad Roberts wrote: How is making __v128 a builtin type better than defining it as: align(16) struct __v128 { ubyte[16] data; } Then the back end knows it should be mapped onto the XMM registers rather than the usual arithmetic set

Re: SIMD support...

On 6 January 2012 03:17, Walter Bright wrote: > Something about the way you are posting is breaking the threading of these > message threads. > I think it may have just been that one off post? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: SIMD support...

On 01/06/12 20:53, Manu wrote: > What about GCC? Will/does it support arbitrary alignment? For sane "arbitrary" values (ie powers of two) it looks like this: import std.stdio; struct S { align(65536) ubyte[64] bs; alias bs this; } pragma(attribute, noinline) void

Re: SIMD support...

On Fri, 06 Jan 2012 21:16:40 +0100, Walter Bright wrote: On 1/6/2012 11:53 AM, Manu wrote: ... this sounds bad. Shall I start another thread? ;) So you're saying it's impossible to align a stack based buffer to, say, 128 bytes... ? No, it's not impossible. Here's what you can do now: c

Re: SIMD support...

On 6 January 2012 21:21, Walter Bright wrote: > 1. the language does typechecking, for example, trying to add a vector of > 4 floats to 16 bytes would be (and should be) an error. > I want to sell you on the 'primitive SIMD regs are truly typeless' point. (which I thought you had already agreed

Re: SIMD support...

On Fri, 06 Jan 2012 20:00:15 +0100, Manu wrote: On 6 January 2012 20:17, Martin Nowak wrote: There is another benefit. Consider the following: __vec128 addps(__vec128 a, __vec128 b) pure { __vec128 res = a; if (__ctfe) { foreach(i; 0 .. 4) res[i] += b[i]; }

  1   2   >