Why is D slower than LuaJIT?

[Steven Schveighoffer]

On Wed, 22 Dec 2010 17:04:21 -0500, Andreas Mayer <spam at bacon.eggs> wrote:

> To see what performance advantage D would give me over using a scripting  
> language, I made a small benchmark. It consists of this code:
>
>>    auto L = iota(0.0, 10000000.0);
>>    auto L2 = map!"a / 2"(L);
>>    auto L3 = map!"a + 2"(L2);
>>    auto V = reduce!"a + b"(L3);
>
> It runs in 281 ms on my computer.
>
> The same code in Lua (using LuaJIT) runs in 23 ms.
>
> That's about 10 times faster. I would have expected D to be faster. Did  
> I do something wrong?
>
> The first Lua version uses a simplified design. I thought maybe that is  
> unfair to ranges, which are more complicated. You could argue ranges  
> have more features and do more work. To make it fair, I made a second  
> Lua version of the above benchmark that emulates ranges. It is still 29  
> ms fast.
>
> The full D version is here: http://pastebin.com/R5AGHyPx
> The Lua version: http://pastebin.com/Sa7rp6uz
> Lua version that emulates ranges: http://pastebin.com/eAKMSWyr
>
> Could someone help me solving this mystery?
>
> Or is D, unlike I thought, not suitable for high performance computing?  
> What should I do?

Without any imperical testing, I would guess this has something to do with  
the lack of inlining for algorithmic functions.  This is due primarily to  
uses of enforce, which use lazy parameters, which are currently not  
inlinable (also, ensure you use -O -release -inline for the most optimized  
code).

I hope that someday this is solved, because it doesn't look very good for  
D...

-Steve