Why is D slower than LuaJIT?

[spir]

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?

Dunno why D seems slow. But Lua is a very fast dynamic language, very simple & rather low level (both on language & implementation sides). Benchmark trials in Lua often run much faster than python or ruby equivalents (often 10 X). Depending on the domain, LuaJIT often adds a speed factor of an order of magnitude. This alltogether brings comparable performance to some compiled languages using high-level features such as virtual funcs, GC,... higher-order funcs, ranges ;-)

denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com