D slower than C++ by a factor of _two_ for simple raytracer (gdc)

[downs]

bearophile wrote:
> downs:
>> My platform is GDC 4.1.2 vs G++ 4.1.1.
> 
> DMD doesn't optimize much for speed, and programs compiled with GDC aren't that far from DMD ones, I don't know why. I'd like GDC to emit C++ code (later to be compiled by GCC) so I can see the spots where it emits slow-looking C++ code.
> DMD isn't much good at inlining, etc, so probably your methods are all function calls, struct methods too.
> 
> If you translate your D raytracer to Java6 with HotSpot you will probably find that your D code is probably 20-50% slower than the Java one, despite the Java one being a bit higher level :-) (Thanks to HotSpot and the GC).
> 
> If you can stand the ugliness, you can probably reduce your running time by 10-15% using my TinyVector structs instead of your Vec struct, you can find them in my d libs: (V.2.70 at the moment, their development is going well, http://www.fantascienza.net/leonardo/so/libs_d.zip ). That TinyVector comes from extensive testing of mine. You probably may require 10-20 minutes of time to adapt your raytracer to using TinyVector, but it's not too much difficult. The result will be ugly...
> 
> Bye,
> bearophile

The weird thing is:
even if I inline the one spot where gdc ignores its opportunity to inline a function, so that I have the _same_ call-counts as G++ (as measured with -g -pg), even then, the D code is slower.
So it doesn't depend on missing inlining opportunities. Or am I missing something?

 --downs

PS: for reference, the missing bit is GDC not always inlining Sphere::ray_sphere. If you look, it's only ever called for cases where the final type is obvious.