Returning large structs == bad

[downs]

Tim Burrell wrote:
> downs wrote:
>> Another interesting observation.
>>
>> If I change all my opFoo's to opFooAssign's, and use those instead, speed goes up from 16s to 13s; indicating that returning large structs (12 bytes/vector) causes a significant speed hit. Still not close to the C++ version though. The weird thing is that all those ops have been inlined (or so says the assembler dump). Weird.
>>
>>  --downs
> 
> Yeah, I was about to say the same.  See here:
> 
> http://paste.dprogramming.com/dpolmzhw
> 
> It's ugly, but no struct returning.
> 
> On my machine it's about a second slower than g++ (8.9s vs. 7.8s)
> compiled via:
> 
> gdc -fversion=Posix -fversion=Tango -O3 -fomit-frame-pointer -fweb
> -frelease -finline-functions
> 
> and
> 
> g++ -O3 -fomit-frame-pointer -fweb -finline-functions
> 
> There's probably some other optimizations that could be made.  But
> really I think this comes down to the compiler not being as mature.  The
> stuff that I did should all be done by an optimizing compiler.  You're
> basically tricking the compiler into moving less bits around.
> 
> Tim.

But even using your compiler flags, I'm still looking at 12.8s (D) vs 8.1s (C++) .. 11.4 (D) vs 7.8 (C++) using -march=nocona.

:ten minutes later:

... Okay, now I'm confused.
Your program is three seconds faster than my op*Assign version.
Is there a generic problem with operator overloading?

I rewrote my version for freestanding functions .. 9.5s :confused: Why do struct members (which are inlined, I checked) take such a speed hit?

Ah well. Let's hope LLVMDC does a better job .. someday.

 --downs