Are-we-fast-yet

I think in many ways on par or ahead of other mainstream system programming languages. https://github.com/rochus-keller/Are-we-fast-yet/blob/main/F...

That's cool. Did you compare performance with the PUC Lua VM versions (which are register based as well)? Personally, I find the Are-we-fast-yet suite very useful and usually migrate the suite to my languages to compare the implementations (see e.g. https://github.com/rochus-keller/are-we-fast-yet/).

Here is the repository with the benchmarks: https://github.com/rochus-keller/are-we-fast-yet/ And here is a repository with a compiler backend to generate LuaJIT bytecode and other useful tools: https://github.com/rochus-keller/ljtools/

I don't know. Unfortunately we don't have an Oberon compiler doing similar optimization as e.g. GCC, so we can only speculate. I did measurements some time ago to compare a typical Oberon compiler on x86 with GCC and the performance was roughly equivalent to that of GCC without optimizations (see https://github.com/rochus-keller/Are-we-fast-yet/tree/main/O...). The C++ type system is also pretty strict, and on the other hand it's possible and even unavoidable in the Oberon system 3 to do pointer arithmetics and other things common in C behind the compiler's back (via the SYSTEM module features which are not even type safe). So the original Oberon syntax and semantics is likely not on the sweet spot of systems programming. With my Micron (i.e. Micro Oberon, see https://github.com/rochus-keller/micron/) language currently in development I t

See e.g. https://github.com/rochus-keller/Oberon or https://github.com/rochus-keller/Are-we-fast-yet/blob/main/O....

There are some results in the repository, e.g. one I published recently: https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L... Or here: https://github.com/rochus-keller/Oberon/blob/master/testcase... The main repository only recently added a C++ implementation, but it was significantly slower than mine when I check last time (see https://github.com/smarr/are-we-fast-yet/issues/80). I mostly use the benchmarks to check how my compilers do compared to the big ones, or how the technologies I'm interested in evolve.

I was actually surprised to see nearly a factor ten between C99 and LuaJIT. In previous measurements (on x86, see e.g. https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L...) there was rather a factor five. So either GCC 12.2 produces much faster code than GCC 4.8, or LuaJIT 2.1 got much slower, or the C99 version of Are-we-fast-yet is much better supported by the CPU cache of the T480 than my previous EliteBook 2530. I don't think that the x86 vs x86_64 makes such a difference (at least I didn't observe this in many other experiments).

Here are some measurement results based on the Are-we-fast-yet benchmark suite: https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L... Luau in interpreter mode is pretty much as fast as LuaJIT 2.1 in interpreter mode. Luau with (partial) native compilation is factor 1.6 slower than LuaJIT 2.1 in JIT mode. I used Luau with the -g0 -O2 --codegen options (didn't add --!native to the code though), which according to my understanding automatically selects the "profitable" functions for native compilation.

Meanwhile I conducted performance measurements myself, based on the Are-we-fast-yet benchmark suite. Here are the results: https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L... Luau in interpreter mode is pretty much as fast as LuaJIT 2.1 in interpreter mode. Luau with (partial) native compilation is factor 1.6 slower than LuaJIT 2.1 in JIT mode. I used Luau with the -g0 -O2 --codegen options (didn't add --!native to the code though).