Re: SIMD benchmark

Timon Gehr wrote: The parameter is just squared and returned? No, sorry that code is all screwed up and missing a step. My Matrix multiply code looks like this: auto transform(U)(Matrix4!U m) if (isImplicitlyConvertible(U, T)) { return Matrix4 ( Vector4 ( (m.x.x*x.x) + (m.

Re: SIMD benchmark

On Wednesday, 18 January 2012 at 01:50:00 UTC, Timon Gehr wrote: Anyway, I was after a general matrix*matrix multiplication, where the operands can get arbitrarily large and where any potential use of __restrict is rendered unnecessary by array vector ops. Here you go. But I agree there are

Re: SIMD benchmark

On 01/18/2012 02:32 AM, F i L wrote: Timon Gehr wrote: Are they really a general solution? How do you use vector ops to implement an efficient matrix multiply, for instance? struct Matrix4 { float4 x, y, z, w; auto transform(Matrix4 mat) { Matrix4 rmat; float4 cx = {mat.x.x, mat.y.x, mat.z.x

Re: SIMD benchmark

Timon Gehr wrote: Are they really a general solution? How do you use vector ops to implement an efficient matrix multiply, for instance? struct Matrix4 { float4 x, y, z, w; auto transform(Matrix4 mat) { Matrix4 rmat; float4 cx = {mat.x.x, mat.y.x, mat.z.x, mat.w.x};

Re: SIMD benchmark

On 01/18/2012 02:04 AM, Walter Bright wrote: On 1/17/2012 4:19 PM, Peter Alexander wrote: So, my original point still stands, you can't vectorise this function: void foo(int[] a, int[] b, int[] c) { foreach (i; 0..256) a[i] = b[i] + c[i]; } Those slices are allowed to overlap, so this cannot b

Re: SIMD benchmark

On 1/17/2012 4:19 PM, Peter Alexander wrote: So, my original point still stands, you can't vectorise this function: void foo(int[] a, int[] b, int[] c) { foreach (i; 0..256) a[i] = b[i] + c[i]; } Those slices are allowed to overlap, so this cannot be automatically vectorised (without inlining t

Re: SIMD benchmark

On 17/01/12 11:34 PM, Walter Bright wrote: On 1/17/2012 3:23 PM, Peter Alexander wrote: On 17/01/12 10:55 PM, Walter Bright wrote: On 1/17/2012 1:47 PM, Peter Alexander wrote: On 17/01/12 9:24 PM, Walter Bright wrote: On 1/17/2012 1:20 PM, Peter Alexander wrote: As Manu said, you need someth

Re: SIMD benchmark

On 1/17/2012 3:23 PM, Peter Alexander wrote: On 17/01/12 10:55 PM, Walter Bright wrote: On 1/17/2012 1:47 PM, Peter Alexander wrote: On 17/01/12 9:24 PM, Walter Bright wrote: On 1/17/2012 1:20 PM, Peter Alexander wrote: As Manu said, you need something like __restrict (or a linear type system

Re: SIMD benchmark

On 17/01/12 10:55 PM, Walter Bright wrote: On 1/17/2012 1:47 PM, Peter Alexander wrote: On 17/01/12 9:24 PM, Walter Bright wrote: On 1/17/2012 1:20 PM, Peter Alexander wrote: As Manu said, you need something like __restrict (or a linear type system) to solve this problem. No, you don't. It c

Re: SIMD benchmark

On 1/17/2012 1:47 PM, Peter Alexander wrote: On 17/01/12 9:24 PM, Walter Bright wrote: On 1/17/2012 1:20 PM, Peter Alexander wrote: As Manu said, you need something like __restrict (or a linear type system) to solve this problem. No, you don't. It can be done with a runtime check, like array

Re: SIMD benchmark

On 17/01/12 9:24 PM, Walter Bright wrote: On 1/17/2012 1:20 PM, Peter Alexander wrote: As Manu said, you need something like __restrict (or a linear type system) to solve this problem. No, you don't. It can be done with a runtime check, like array bounds checking is done. So you'd change it

Re: SIMD benchmark

On 1/17/2012 1:20 PM, Peter Alexander wrote: As Manu said, you need something like __restrict (or a linear type system) to solve this problem. No, you don't. It can be done with a runtime check, like array bounds checking is done.

Re: SIMD benchmark

On 16/01/12 10:36 PM, Iain Buclaw wrote: On 16 January 2012 21:57, Peter Alexander wrote: On 16/01/12 8:56 PM, Iain Buclaw wrote: On 16 January 2012 19:25, Walter Bright wrote: On 1/16/2012 11:16 AM, Iain Buclaw wrote: But don't worry, I'm not planning on working on that at the moment

Re: SIMD benchmark

On 1/17/2012 5:20 AM, Martin Nowak wrote: Mmh, there was something keeping me from specializing templates, https://github.com/D-Programming-Language/dmd/pull/396 :). But right now I'd rather like to finish the shared library merging. I agree.

Re: SIMD benchmark

On 1/17/2012 2:43 AM, Manu wrote: On 17 January 2012 12:33, Walter Bright mailto:newshou...@digitalmars.com>> wrote: On 1/17/2012 12:17 AM, Manu wrote: What protects these ranges from being overlapping? A runtime check, like array bounds checking. Awesome. How does this map

Re: SIMD benchmark

On Tue, 17 Jan 2012 11:53:35 +0100, Walter Bright wrote: On 1/17/2012 2:04 AM, Martin Nowak wrote: I was about to rewrite it at some point. https://gist.github.com/1235470 I think you've got an innovative and clever solution. I'd like to see you finish it! Mmh, there was something ke

Re: SIMD benchmark

On 1/17/2012 2:04 AM, Martin Nowak wrote: I was about to rewrite it at some point. https://gist.github.com/1235470 I think you've got an innovative and clever solution. I'd like to see you finish it!

Re: SIMD benchmark

On 17 January 2012 11:48, Martin Nowak wrote: > On Tue, 17 Jan 2012 09:20:43 +0100, Manu wrote: > > On 17 January 2012 05:55, bearophile wrote: >> >> Walter: >>> >>> > But don't worry, I'm not planning on working on that at the moment :-) >>> >>> Until better optimizations are implemented, I

Re: SIMD benchmark

On 17 January 2012 12:33, Walter Bright wrote: > On 1/17/2012 12:17 AM, Manu wrote: > >> What protects these ranges from being overlapping? >> > > A runtime check, like array bounds checking. > Awesome. How does this map to pointer dereferencing?

Re: SIMD benchmark

On 1/17/2012 12:17 AM, Manu wrote: What protects these ranges from being overlapping? A runtime check, like array bounds checking.

Re: SIMD benchmark

On 17 January 2012 08:17, Manu wrote: > On 17 January 2012 03:56, Iain Buclaw wrote: >> >> On 16 January 2012 22:36, Iain Buclaw wrote: >> > On 16 January 2012 21:57, Peter Alexander >> > wrote: >> >> On 16/01/12 8:56 PM, Iain Buclaw wrote: >> >>> >> >>> On 16 January 2012 19:25, Walter Bright

Re: SIMD benchmark

On Tue, 17 Jan 2012 09:42:12 +0100, Don Clugston wrote: On 16/01/12 17:51, Martin Nowak wrote: On Mon, 16 Jan 2012 17:17:44 +0100, Andrei Alexandrescu wrote: On 1/15/12 12:56 AM, Walter Bright wrote: I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. Anyhow, it's good e

Re: SIMD benchmark

On Tue, 17 Jan 2012 09:20:43 +0100, Manu wrote: On 17 January 2012 05:55, bearophile wrote: Walter: > But don't worry, I'm not planning on working on that at the moment :-) Until better optimizations are implemented, I see a "simple" optimization for vector ops. When the compiler knows a

Re: SIMD benchmark

On 16/01/12 17:51, Martin Nowak wrote: On Mon, 16 Jan 2012 17:17:44 +0100, Andrei Alexandrescu wrote: On 1/15/12 12:56 AM, Walter Bright wrote: I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. Anyhow, it's good enough now to play around with. Consider it alpha quality. E

Re: SIMD benchmark

On 17 January 2012 05:55, bearophile wrote: > Walter: > > > But don't worry, I'm not planning on working on that at the moment :-) > > Until better optimizations are implemented, I see a "simple" optimization > for vector ops. When the compiler knows an arrays are very small it unrolls > the oper

Re: SIMD benchmark

On 17 January 2012 03:56, Iain Buclaw wrote: > On 16 January 2012 22:36, Iain Buclaw wrote: > > On 16 January 2012 21:57, Peter Alexander > wrote: > >> On 16/01/12 8:56 PM, Iain Buclaw wrote: > >>> > >>> On 16 January 2012 19:25, Walter Bright > >>> wrote: > > On 1/16/2012 11:16 AM,

Re: SIMD benchmark

Walter: > But don't worry, I'm not planning on working on that at the moment :-) Until better optimizations are implemented, I see a "simple" optimization for vector ops. When the compiler knows an arrays are very small it unrolls the operation in-place: int n = 5; auto a = new int[n]; auto b

Re: SIMD benchmark

On 16 January 2012 22:36, Iain Buclaw wrote: > On 16 January 2012 21:57, Peter Alexander > wrote: >> On 16/01/12 8:56 PM, Iain Buclaw wrote: >>> >>> On 16 January 2012 19:25, Walter Bright >>>  wrote: On 1/16/2012 11:16 AM, Iain Buclaw wrote: >> >> But don't worry, I'm not

Re: SIMD benchmark

On Mon, 16 Jan 2012 20:25:28 +0100, Walter Bright wrote: On 1/16/2012 11:16 AM, Iain Buclaw wrote: But don't worry, I'm not planning on working on that at the moment :-) Leave that sort of optimisation for the backend to handle please. ;-) Of course. I suspect Intel's compiler does that

Re: SIMD benchmark

On 1/16/2012 2:06 PM, Manu wrote: Surely it would be possible for them to be overlapping slices? Not allowed, treated like array bounds checking.

Re: SIMD benchmark

On 16 January 2012 21:57, Peter Alexander wrote: > On 16/01/12 8:56 PM, Iain Buclaw wrote: >> >> On 16 January 2012 19:25, Walter Bright >>  wrote: >>> >>> On 1/16/2012 11:16 AM, Iain Buclaw wrote: >>> > > But don't worry, I'm not planning on working on that at the moment :-) >>>

Re: SIMD benchmark

On Mon, 16 Jan 2012 23:22:21 +0100, Simen Kjærås wrote: On Mon, 16 Jan 2012 23:06:12 +0100, Manu wrote: On 17 January 2012 00:03, Walter Bright wrote: On 1/16/2012 1:54 PM, Manu wrote: Unfortunately, if the function was this: void foo(int[] a, int[] b, int[] c) { for (i

Re: SIMD benchmark

On Mon, 16 Jan 2012 23:06:12 +0100, Manu wrote: On 17 January 2012 00:03, Walter Bright wrote: On 1/16/2012 1:54 PM, Manu wrote: Unfortunately, if the function was this: void foo(int[] a, int[] b, int[] c) { for (int i=0; i<256; i++) a[i] = b[i] + c[i]; } Then

Re: SIMD benchmark

On 17 January 2012 00:03, Walter Bright wrote: > On 1/16/2012 1:54 PM, Manu wrote: > >>Unfortunately, if the function was this: >> >>void foo(int[] a, int[] b, int[] c) { >> >> for (int i=0; i<256; i++) >>a[i] = b[i] + c[i]; >>} >> >>Then it can't vectorize due to ali

Re: SIMD benchmark

On 1/16/2012 12:22 PM, Manu wrote: Yes, my first thought when I saw this test was "why is it generating any code at all?".. But I tried to forget about that :) I am curious though, what is causing that code (on both sides) to not be eliminated? If I write that in C, I'm sure it would generate not

Re: SIMD benchmark

On 1/16/2012 1:54 PM, Manu wrote: Unfortunately, if the function was this: void foo(int[] a, int[] b, int[] c) { for (int i=0; i<256; i++) a[i] = b[i] + c[i]; } Then it can't vectorize due to aliasing. This is why D needs a __restrict attribute! ;) That's why

Re: SIMD benchmark

On 16 January 2012 23:57, Peter Alexander wrote: > On 16/01/12 8:56 PM, Iain Buclaw wrote: > >> On 16 January 2012 19:25, Walter >> Bright> >> wrote: >> >>> On 1/16/2012 11:16 AM, Iain Buclaw wrote: >>> >>> > But don't worry, I'm not planning on working on that at the moment :-) > >

Re: SIMD benchmark

On 16/01/12 8:56 PM, Iain Buclaw wrote: On 16 January 2012 19:25, Walter Bright wrote: On 1/16/2012 11:16 AM, Iain Buclaw wrote: But don't worry, I'm not planning on working on that at the moment :-) Leave that sort of optimisation for the backend to handle please. ;-) Of course. I susp

Re: SIMD benchmark

On 16 January 2012 19:25, Walter Bright wrote: > On 1/16/2012 11:16 AM, Iain Buclaw wrote: >>> >>> But don't worry, I'm not planning on working on that at the moment :-) >> >> Leave that sort of optimisation for the backend to handle please. ;-) > > > Of course. > > I suspect Intel's compiler does

Re: SIMD benchmark

On 16 January 2012 21:27, Michel Fortin wrote: > In fact, the optimization I'd expect the compiler to do in this case is > just wipe out all the code, as it does nothing other than putting a value > in a local variable which is never reused later. > Yes, my first thought when I saw this test was

Re: SIMD benchmark

On 2012-01-16 17:57:14 +, Andrei Alexandrescu said: On 1/16/12 11:32 AM, Michel Fortin wrote: Andrei's idea could be valid as an optimization when the compiler can see that all the operations can be performed with SIMD ops. In this particular case: if test1a(a) is inlined. But it can't wo

Re: SIMD benchmark

On 1/16/2012 11:16 AM, Iain Buclaw wrote: But don't worry, I'm not planning on working on that at the moment :-) Leave that sort of optimisation for the backend to handle please. ;-) Of course. I suspect Intel's compiler does that one, does gcc?

Re: SIMD benchmark

On 16 January 2012 18:59, Walter Bright wrote: > On 1/16/2012 8:48 AM, Andrei Alexandrescu wrote: >> >> My point was that the version using float arrays should opportunistically >> use >> hardware ops whenever possible. > > > Yes, you're right. The compiler can opportunistically convert a number o

Re: SIMD benchmark

On 1/16/2012 9:21 AM, Manu wrote: x64 can do the swapping too with no penalty, but that is the only architecture that can. Ah, that is a crucial bit of information.

Re: SIMD benchmark

On 1/16/2012 8:59 AM, Manu wrote: (also the float array is unaligned). Currently, it is 4 byte aligned. But the compiler could align freestanding static arrays on 16 bytes without breaking anything. It just cannot align: struct S { int a; float[4] b; } b on a 16 byt

Re: SIMD benchmark

On 1/16/2012 8:48 AM, Andrei Alexandrescu wrote: My point was that the version using float arrays should opportunistically use hardware ops whenever possible. Yes, you're right. The compiler can opportunistically convert a number of vector operations on static arrays to the SIMD instructions.

Re: SIMD benchmark

On 1/16/12 11:32 AM, Michel Fortin wrote: Andrei's idea could be valid as an optimization when the compiler can see that all the operations can be performed with SIMD ops. In this particular case: if test1a(a) is inlined. But it can't work if the float[4] value crosses a function's boundary. In

Re: SIMD benchmark

On 2012-01-16 16:59:44 +, Manu said: On 16 January 2012 18:48, Andrei Alexandrescu wrote: On 1/16/12 10:46 AM, Manu wrote: A function using float arrays and a function using hardware vectors should certainly not be the same speed. My point was that the version using float arrays sh

Re: SIMD benchmark

On 16 January 2012 19:01, Timon Gehr wrote: > On 01/16/2012 05:59 PM, Manu wrote: > >> On 16 January 2012 18:48, Andrei Alexandrescu >> > > >> >> >> wrote: >> >>On 1/16/12 10:46 AM, Manu wrote: >> >>A function using float arrays and a function

Re: SIMD benchmark

On 01/16/2012 05:59 PM, Manu wrote: On 16 January 2012 18:48, Andrei Alexandrescu mailto:seewebsiteforem...@erdani.org>> wrote: On 1/16/12 10:46 AM, Manu wrote: A function using float arrays and a function using hardware vectors should certainly not be the same speed.

Re: SIMD benchmark

On 16 January 2012 18:48, Andrei Alexandrescu wrote: > On 1/16/12 10:46 AM, Manu wrote: > >> A function using float arrays and a function using hardware vectors >> should certainly not be the same speed. >> > > My point was that the version using float arrays should opportunistically > use hardwa

Re: SIMD benchmark

On Mon, 16 Jan 2012 17:17:44 +0100, Andrei Alexandrescu wrote: On 1/15/12 12:56 AM, Walter Bright wrote: I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. Anyhow, it's good enough now to play around with. Consider it alpha quality. Expect bugs - but make bug reports, as

Re: SIMD benchmark

On 1/16/12 10:46 AM, Manu wrote: A function using float arrays and a function using hardware vectors should certainly not be the same speed. My point was that the version using float arrays should opportunistically use hardware ops whenever possible. Andrei

Re: SIMD benchmark

On 16 January 2012 18:17, Andrei Alexandrescu wrote: > On 1/15/12 12:56 AM, Walter Bright wrote: > >> I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. >> Anyhow, it's good enough now to play around with. Consider it alpha >> quality. Expect bugs - but make bug reports, as th

Re: SIMD benchmark

On 1/15/12 12:56 AM, Walter Bright wrote: I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. Anyhow, it's good enough now to play around with. Consider it alpha quality. Expect bugs - but make bug reports, as there's a serious lack of source code to test it with. -

Re: SIMD benchmark

32 bit SIMD for Linux is not implemented. It's all 64 bit platforms, and 32 bit OS X. On 1/16/2012 2:35 AM, Andre Tampubolon wrote: Well I only have 1 machine, a laptop running 64 bit Arch Linux. Yesterday I did a git pull, built both 32& 64 bit DMD, and this code compiled fine using those. Bu

Re: SIMD benchmark

Well I only have 1 machine, a laptop running 64 bit Arch Linux. Yesterday I did a git pull, built both 32 & 64 bit DMD, and this code compiled fine using those. But now, the 32 bit version fails. Walter Bright wrote: > On 1/16/2012 12:59 AM, Andre Tampubolon wrote: >> I just built 32& 64 bit DMD

Re: SIMD benchmark

On 1/16/2012 12:59 AM, Andre Tampubolon wrote: I just built 32& 64 bit DMD (latest commit on git tree is f800f6e342e2d9ab1ec9a6275b8239463aa1cee8) Using the 32-bit version, I got this error: Internal error: backend/cg87.c 1702 The 64-bit version went fine. Previously, both 32 and 64 bit versi

Re: SIMD benchmark

I just built 32 & 64 bit DMD (latest commit on git tree is f800f6e342e2d9ab1ec9a6275b8239463aa1cee8) Using the 32-bit version, I got this error: Internal error: backend/cg87.c 1702 The 64-bit version went fine. Previously, both 32 and 64 bit version had no problem. On 01/15/2012 01:56 PM, Walte

Re: SIMD benchmark

On 15 January 2012 19:01, bearophile wrote: > Iain Buclaw: > >> Correction, 1.5x speed up without, 20x speed up with -O1, 30x speed up >> with -O2 and above.  My oh my... > > Please, show me the assembly code produced, with its relative D source :-) > > Bye, > bearophile For those who can't read

Re: SIMD benchmark

On 15 January 2012 19:01, bearophile wrote: > Iain Buclaw: > >> Correction, 1.5x speed up without, 20x speed up with -O1, 30x speed up >> with -O2 and above.  My oh my... > > Please, show me the assembly code produced, with its relative D source :-) > > Bye, > bearophile D code: import core.

Re: SIMD benchmark

Iain Buclaw: > Correction, 1.5x speed up without, 20x speed up with -O1, 30x speed up > with -O2 and above. My oh my... Please, show me the assembly code produced, with its relative D source :-) Bye, bearophile

Re: SIMD benchmark

On 1/15/2012 10:10 AM, Iain Buclaw wrote: Correction, 1.5x speed up without, 20x speed up with -O1, 30x speed up with -O2 and above. My oh my... Woo-hoo!

Re: SIMD benchmark

On 15 January 2012 20:10, Iain Buclaw wrote: > On 15 January 2012 16:59, Iain Buclaw wrote: > > On 15 January 2012 06:56, Walter Bright > wrote: > >> I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. > >> Anyhow, it's good enough now to play around with. Consider it alpha >

Re: SIMD benchmark

On 1/15/2012 3:49 AM, Peter Alexander wrote: Actually, looking at the auto-tester, I'm not alone. Just seems to be OSX though. Yeah, it's just OSX. I had the test for that platform inadvertently disabled, gak.

Re: SIMD benchmark

On 15 January 2012 16:59, Iain Buclaw wrote: > On 15 January 2012 06:56, Walter Bright wrote: >> I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. >> Anyhow, it's good enough now to play around with. Consider it alpha quality. >> Expect bugs - but make bug reports, as there's

Re: SIMD benchmark

On 15 January 2012 06:56, Walter Bright wrote: > I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. > Anyhow, it's good enough now to play around with. Consider it alpha quality. > Expect bugs - but make bug reports, as there's a serious lack of source code > to test it with.

Re: SIMD benchmark

On 15/01/12 6:56 AM, Walter Bright wrote: I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. Anyhow, it's good enough now to play around with. Consider it alpha quality. Expect bugs - but make bug reports, as there's a serious lack of source code to test it with. You sure yo

Re: SIMD benchmark

On 1/14/2012 10:56 PM, Walter Bright wrote: as there's a serious lack of source code to test it with. Here's what there is at the moment. Needs much more. https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/testxmm.d