Support for gcc vector attributes, SIMD builtins
Mike Farnsworth
mike.farnsworth at gmail.com
Sun Feb 6 15:07:15 PST 2011
On 02/06/2011 02:58 PM, Iain Buclaw wrote:
> == Quote from Brad Roberts (braddr at puremagic.com)'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
More information about the D.gnu
mailing list