[Rochus]

Have a look at the results and the code; there are benchmarks in the suite where the (ideomatic) C/C++ implementation is "only" twice as fast as the corresponding (idiomatic) Lua implementation, but on average (geomean of all factors) it's about five times as fast. The guidelines of the benchmark are pretty strict to enable fair comparisons (see https://github.com/smarr/are-we-fast-yet/blob/master/docs/gu...).

[pmarreck]

I looked at the docs. This seems to be comparing against Lua, which is why I specifically said LuaJIT

This is quite a distinction to be made. Can you clarify?

Directly from their guidelines page:

    Lua
    
    We write code compatible with Lua 5.1, 5.2 and 5.3.
    Smalltalk/Ruby symbols are represented as normal strings.
    We use Lua 1-based array and the length operator #.
    We use single object when a class is not required.
    Bitwise operators with various Lua versions is a nightmare.
    We use luacheck as a linter.

If they are writing code compatible with Lua 5.2 or 5.3, then that cannot be LuaJIT, which is ONLY compatible with Lua 5.1. (Unless they mean that they JUST write 5.1 code, which due to backwards compatibility is runnable on 5.2 and 5.3? It's unclear from here.)

[Rochus]

It's essentially written in Lua 5.1 with specific alternative implementations of mandelbrot and hashindextable for Lua 5.3 selectable by the test runner. But this doesn't matter much because my reference is LuaJIT. I have also compared different LuaJIT and also PUC Lua implementations, see http://software.rochus-keller.ch/are-we-fast-yet_LuaJIT_2017... and http://software.rochus-keller.ch/are-we-fast-yet_Lua_results....

[pmarreck]

This actually gave me an idea that I'm going to build out