Why is D slower than LuaJIT?

[Andreas Mayer]

Gary Whatmore Wrote:

> Andreas Mayer 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);
> 
> First note: this is a synthetic toy benchmark. Take it with a grain of salt. It represent in no way the true state of D.

True enough. Yet it doesn't make me very optimistic what the final performance tradeoff would be as long as you use high level abstractions. Sure, with D you can always go on the C or even assembly level.

> Your mp3 player or file system was doing stuff while executing the benchmark. You probably don't know how to run the test many times and use the average/minimum result for both languages. For example D does not have JIT startup cost so take the minimum result for D, JIT has varying startup speed so take the average or slowest result for Luajit. Compare these. More fair for native code D.

Both benchmarks were run under the same conditions. Once the executables were inside the disk cache, the run times didn't vary much. Plus this benchmark already is unfair against LuaJIT: the startup time and the time needed for optimization and code generation are included in the times I gave. The D example on the other hand doesn't include the time needed for compilation. The D compiler needs 360 ms to compile this example. If the comparison were fair and included compilation time in the D timings, D would lose even more.

> My guesses are:
> 
> 1) you didn't even test this and didn't use optimizations. -> User error

I enabled all dmd optimizations I was aware of. Maybe I forgot some?

> 2) whenever doing benchmarks you must compare the competing stuff against all D compilers, cut and paste the object code of different compilers and manually build the fastest executable.

That seems like an unreasonable task. Writing the code in assembler would be simpler. But I'm using a high level language because I want to use high level abstractions. Like map and reduce, instead of writing assembler.

> 3) you didn't use inline assembler or profiler for D

See 2).

> 4) you were using unstable Phobos functions. There is no doubt the final Phobos 2.0 will beat Luajit. D *is* a compiler statical language, Luajit just a joke.

I used the latest dmd release (and that is very new).

As you can see, LuaJIT beats D by far. I wouldn't call it a joke.

If a joke beats D, then what is D? This way of argumentation doesn't sound very advantageous for you.

> 5) you were using old d runtime garbage collector. One fellow here made a precise state of the art GC which beats even Java's 20 year old GC and C#. Patch your dmd to use this instead.

There shouldn't be any GC activity. Ranges work lazily. They don't allocate arrays for the data they are working on.

You can post a package with "bleeding edge" dmd and Phobos sources with updated GC and so on. Then I could try that.

> 
> Not intending to start a religious war but if your native code runs slower than *JIT* code, you're doing something wrong. D will always beat JIT. Lua is also a joke language, D is for high performance servers and operating systems. In the worst case, disassemble the luajit program, steal its codes and write it using inline assembler in D. D must win these performance battles. It's technically superior.

But D didn't win. Not here. And what was I doing wrong? Please point out. I posted this because I was surprised myself and I thought "that can't be".