OOP, faster data layouts, compilers

bearophile bearophileHUGS at lycos.com
Fri Apr 22 14:41:21 PDT 2011


Sean Cavanaugh:

> In many ways the biggest thing I use regularly in game development that
> I would lose by moving to D would be good built-in SIMD support.  The PC
> compilers from MS and Intel both have intrinsic data types and
> instructions that cover all the operations from SSE1 up to AVX.  The
> intrinsics are nice in that the job of register allocation and
> scheduling is given to the compiler and generally the code it outputs is
> good enough (though it needs to be watched at times).

This is a topic quite different from the one I was talking about, but it's an interesting topic :-)

SIMD intrinsics look ugly, they add lot of noise to the code, and are very specific to one CPU, or instruction set. You can't design a clean language with hundreds of those. Once 256 or 512 bit registers come, you need to add new intrinsics and change your code to use them. This is not so good.

D array operations are probably meant to become smarter, when you perform a:

int[8] a, b, c;
a = b + c;

A future good D compiler may use just two inlined istructions, or little more. This will probably include shuffling and broadcasting properties too.

Maybe this kind of code is not as efficient as handwritten assembly code (or C code that uses SIMD intrinsics) but it's adaptable to different CPUs, future ones too, it's much less noisy, and it seems safer.

I think such optimizations are better left to the back-end, so lot of time ago I've asked it to LLVM devs, for future LDC:
http://llvm.org/bugs/show_bug.cgi?id=6956

The presence of such well implemented vector ops will not forbid another D compiler to add true SIMD intrinsics too.


> Unlike ASM, intrinsics can be inlined so your math library can provide a

DMD may eventually need this feature of the LDC compiler:
http://www.dsource.org/projects/ldc/wiki/InlineAsmExpressions

Bye,
bearophile


More information about the Digitalmars-d mailing list