Why is D slower than LuaJIT?

[Brad Roberts]

On Wed, 22 Dec 2010, Andrei Alexandrescu wrote:

> On 12/22/10 11:06 PM, Andreas Mayer wrote:
> > Andrei Alexandrescu Wrote:
> > 
> > > Andreas, any chance you could run this on your machine and compare it
> > > with Lua? (I don't have Lua installed.) Thanks!
> > 
> > Your version: 40 ms (iota and baseline give the same timings)
> > LuaJIT with map calls removed: 21 ms
> > 
> > Interesting results.
> 
> Cool, thanks. I also tested against this C++ baseline:
> 
> #include <stdio.h>
> 
> int main() {
>      const double limit = 10000000.0;
>      double result = 0.0;
>      for (double i = 0; i != limit; ++i) {
>        result += i;
>      }
>      printf("%f\n", result);
> }
> 
> The baseline (compiled with -O3) runs in 21 ms on my machine, which means (if
> my and Andreas' machines are similar in performance) that Lua has essentially
> native performance for this loop and D has an issue in code generation that
> makes it 2x slower. I think this could be filed as a performance bug for dmd.
> 
> I'm thinking what to do about iota, which has good features but exacts too
> much cost on tight loop performance. One solution would be to define iota to
> be the simple, forward range that I defined as Iota2 in my previous post.
> Then, we need a different name for the full-fledged iota (random-access, has
> known length, iterates through the same numbers forward and backward etc).
> Ideas?
> 
> 
> Andrei

Since the timing code isn't here, I'm assuming you guys are doing the 
testing around the whole app.  While that might be interesting, it's 
hiding an awfully large and important difference, application startup 
time.

C has very little, D quite a bit more, and I don't know what Lua looks 
like there.  If the goal is to test this math code, you'll need to 
separate the two.

At this point, I highly suspect you're really measuring the runtime costs.