core.simd woes

F i L witte2008 at gmail.com
Tue Oct 2 09:00:55 PDT 2012


Manu wrote:
> These are indeed common gotchas. But they don't necessarily 
> apply to D, and
> if they do, then they should be bugged and hopefully addressed. 
> There is no
> reason that D needs to follow these typical performance 
> patterns from C.
> It's worth noting that not all C compilers suffer from this 
> problem. There
> are many (most actually) compilers that can recognise a struct 
> with a
> single member and treat it as if it were an instance of that 
> member
> directly when being passed by value.
> It only tends to be a problem on older games-console compilers.
>
> As I said earlier. When I get back to finishing srd.simd off (I 
> presume
> this will be some time after Walter has finished Win64 
> support), I'll go
> through and scrutinise the code-gen for the API very 
> thoroughly. We'll see
> what that reveals. But I don't think there's any reason we 
> should suffer
> the same legacy C by-value code-gen problems in D... (hopefully 
> I won't eat
> those words ;)


Thanks for the insight (and the code examples, though I've been 
researching SIMD best-practice in C recently). It's good to know 
that D should (hopefully) be able to avoid these pitfalls.

On a side note, I'm not sure how easy LLVM is to build on Windows 
(I think I built it once a long time ago), but recent performance 
comparisons between DMD, LDC, and GDC show that LDC (with LLVM 
3.1 auto-vectorization and not using GCC -ffast-math) actually 
produces on-par-or-faster binary compared to GDC, at least in my 
code on Linux64. SIMD in LDC is currently broken, but you might 
consider using that if you're having trouble keeping a D release 
compiler up-to-date.


More information about the Digitalmars-d mailing list