Item — HN Reader

Interesting results. Particularly they barely found a speed-up of newer compared to older LuaJIT versions (rather the contrary). Maybe they should have used the Are-we-fast-yet suite instead of the (random looking) set of microbenchmarks. I did measurements of Lua and LuaJIT some time ago based on Are-we-fast-yet and saw significant differences in LuaJIT performance (see http://software.rochus-keller.ch/are-we-fast-yet_LuaJIT_2017...).

I also compared different PUC Lua versions in an earlier measurement (see http://software.rochus-keller.ch/are-we-fast-yet_lua_results...) and found similar significant differences between versions.

2 comments

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 am currently implementing a personal programming language on top of luajit. Have you found that generating bytecode is actually faster (compile time and more importantly runtime) than just generating Lua (like Moonscript and Fennel does)?

Cool. It's still a great backend, even for a statically typed language, and the FFI and debugger features are very useful. Mono is yet another great backend which in addition supports multiple threads and has the higher performance, but with a (slightly) higher footprint. I have used both in different projects (see e.g. https://github.com/rochus-keller/Oberon or https://github.com/rochus-keller/Luon), and currently I'm even implementing a LuaJIT bytecode generator for my Micron intermediate language which uses LuaJIT essentially as a kind of C interpreter, even with my own native stack and GC (https://github.com/rochus-keller/Micron).

The reason why I switched from generating Lua source code to LuaJIT bytecode in 2019 was mostly the higher flexibility. I could better avoid operations not yet supported by the tracer, and some language features of Oberon+ didn't match well to Lua. And adding line information for debugging was much easier. And it was a fun project and the bytecode was well documented. It's certainly also a bit faster, but I haven't done specific measurements.

Thanks again for this.

My goals are:

Deep copy value passing semantics by default (with outs for hotpath and some optimization).

Persistence by default using SQLite. (Again, opt out for hot paths).

Lua tables, but callable. Also every object is a continuation. Optimizations for js are float64 arrays with the 0 index holding some meta stuff - but semantically just objects and messages.

No variables, just fields.

Fields can be thought of as canned message responses. Fallthrough is “call”.

When you consider SQLite, you might want to get around SQL for impedance and performance reasons. There is a robust and decently fast key/value store in the backend. I used it in some of my projects (e.g. https://github.com/rochus-keller/udb used e.g. in https://github.com/rochus-keller/crossline/). Depending on read/write frequency, lmdb or tidesdb might be a better fit.

This is cool. I wonder if WASM would work here as a target for the k/v store.

Is V8 faster than Luajit now? That is surprising to me.

V8 was significantly faster than LuaJIT when I did measurements in 2021 (see https://github.com/rochus-keller/Oberon/blob/master/testcase..., didn't measure it since). Sure there are microbenchmarks where LuaJIT performs equally well or even faster, but overall (geomean of factors) V8 was 2.5 times faster. This comes with a price though. If you're interested in performance, Mono was equally fast as V8 in my measurements but much leaner, and more flexible with a well-documented bytecode, or use a LuaJIT or Mono backend for the development environment and offer a C transpiler for maximum performance at runtime.

Thank you. I am planning to argent Lua and Js(browser), and my (very much LLM assisted) demo already is with x2 range of js.

I guess in my head, I really liked the idea of the simplicity and size of Lua/luajit - but maybe for people like me, who have no hope of designing competitive JITs, the future is just to spit out JavaScript.

Your work has been an inspiration to me for quite a long time but the way.

Thanks, great that the work is useful.