On 02/06/2011 02:58 PM, Iain Buclaw wrote: > == Quote from Brad Roberts ([email protected])'s article >> I'd be happy to have gcc finding vectorization opportunities, but there's no > need to add this sort of thing to the >> language. This already has a hook to call a library function: >> float[4] a = [1,2,3,4], b = [5,6,7,8], c; >> c[] = a[] + b[]; > > Aye, and 9 times out of 10 I would agree with this thinking also. > > The pros to hashing out GCC Vector intrinsics to the D frontend though are > that > the GCC backend has much more creative control over the codegen. Inlining and > optimising the intrinsics in a far better way than optimising the overhead of > an > external library call. > > Baring in mind that DMD's array libraries are already extremely performant > anyway, > I honestly don't see the harm if it makes the poignant speed freaks happy. > > Regards
Yes, and I am definitely a "speed freak", but I have good reason: in my field, 3D rendering performance is extremely important. If I can write a few classes in D that can get me to very optimized SSE code on x86(-64) for most vector/point/color operations, for example, that can make or break my ability to get anyone to use my renderer *at all*. In D I can easily do the version(gnu) thing to make the program 100% cross-platform for the cases where I don't have the intrinsics. I would love it if the array-wise operations were able to automatically just boil down to the intrinsics, but in order to make it fast enough they must always be 16-byte aligned, pass float[4] by SSE register where possible, etc, etc. Someday, the compiler hopefully will just do that, but it doesn't always do it today (or really at all, in my tests of just the float[4] static arrays). -Mike
