Why is this D code slower than C++?

[Dave]

Bill Baxter wrote:
> Bradley Smith wrote:
>> Thanks for all the suggestions. It helps, but not enough to make the D 
>> code faster than the C++. It is now 2.6 times slower. The render times 
>> are now approx. 13 sec for raytracer_d and approx. 5 sec for 
>> raytracer_cpp.
>>
>> Here are the changes I've made. Attached is the new code.
>>
>>   Call RegisterClass outside of assert. (Broken if -release used)
>>   Apply -release option. (Increases speed in an unknown way)
>>   Converted templates to regular functions. (Templates not being inlined)
>>   Manually inlined DOT function. (Function not being inlined)
> 
> You left out changing Intersect's Ray argument to be inout.  And 
> generally all Ray (and possibly vector3 parameters) to be inout to avoid 
>  the cost of copying them on the stack.
> 
> Also converting vector expressions like
>       vector3 v = a_Ray.origin - m_Centre;
> to
>       vector3 v = a_Ray.origin;
>       v -= m_Centre;
> 
> makes a difference.  Changing that one line in the Sphere.Intersect 
> routine changes my runtime from 12.2 to 14.3 sec.
> 
> Interestingly the same sort of transformation to the C++ code didn't 
> seem to make much difference.  It could be related in part to the C++ 
> vector parameters on the operators all taking const vector& (references) 
> vs the D ones being just plain vector3.  Chaging all the operators in 
> the D version to inout may help speed too.
> 
> With those changes on my Intel Xeon 3.6GHz CPU the run times are about 
> 10.1 sec vs 12.2 sec.  D still not as fast as the C++, but close.
> 
> --bb

One more thing to try (now that auto classes are allocated on the stack) is to convert the structs 
to classes and pass those around. Of course you can't return those from things like opSub(), so 
you'd have to always use opXxxAssign(), etc. I haven't gone over the code in detail, so maybe this 
is not really feasible but maybe worth a shot?

IIRC, one of the problems with using 'inout' as function params. is that those are excluded from 
consideration for in-lining with the current D compiler front-end.