3 ms·

> LuaJITted Lua code runs at 80% (on average, sometimes faster!) of the compiled C version of the same algorithm, typically Cannot confirm this. It might be tr

by Rochus 1y ago

> LuaJITted Lua code runs at 80% (on average, sometimes faster!) of the compiled C version of the same algorithm, typically Cannot confirm this. It might be true on selected micro benchmarks. Here are the results of the Are-we-fast-yet benchmark suite, which includes a decent set of benchmarks challenging CPU, cache and memory access: https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf https://github.com/rochus-keller/Oberon/blob/master/testcase.... On average, the C and C++ implementations are five times faster than LuaJIT. > There are also some neat languages that compile to (transpile to?) Lua Here is a comprehensive list: https://github.com/hengestone/lua-languages https://github.com/hengestone/lua-languages. Lanuages like Oberon or Luon directly compile to LuaJIT bytecode (i.e. not to Lua).

Symmetry 1y ago
The code in Are-we-fast-yet has been heavily optimized. It might still be true that naive LuaJIT can run almost as fast as Naive C.
- Rochus 1y ago
  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/guidelines.md https://github.com/smarr/are-we-fast-yet/blob/master/docs/gu...).
  - pmarreck 1y ago
    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 1y ago
      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_vs_2023_results.pdf http://software.rochus-keller.ch/are-we-fast-yet_LuaJIT_2017... and http://software.rochus-keller.ch/are-we-fast-yet_Lua_results_2024-06-20.pdf http://software.rochus-keller.ch/are-we-fast-yet_Lua_results....
      - pmarreck 1y ago
        This actually gave me an idea that I'm going to build out

by Rochus 1y ago

Symmetry 1y ago

The code in Are-we-fast-yet has been heavily optimized. It might still be true that naive LuaJIT can run almost as fast as Naive C.

Rochus 1y ago
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/guidelines.md https://github.com/smarr/are-we-fast-yet/blob/master/docs/gu...).
- pmarreck 1y ago
  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 1y ago
    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_vs_2023_results.pdf http://software.rochus-keller.ch/are-we-fast-yet_LuaJIT_2017... and http://software.rochus-keller.ch/are-we-fast-yet_Lua_results_2024-06-20.pdf http://software.rochus-keller.ch/are-we-fast-yet_Lua_results....
    - pmarreck 1y ago
      This actually gave me an idea that I'm going to build out