minivm VS LuaJIT

> I developed a unique way to write interpreters based on threaded code jumps and basic block versioning when I made MiniVM (https://github.com/FastVM/minivm). It was both larger and more dynamic than WebAssembly.

I'd be very interested to read more about this. It looks like you are using "one big function" with computed goto (https://github.com/FastVM/Web49/blob/main/src/interp/interp....). My experience working on this problem led me to the same conclusion as Mike Pall, which is that compilers do not do well with this pattern (particularly when it comes to register allocation): http://lua-users.org/lists/lua-l/2011-02/msg00742.html

I'm curious how you worked around the problem of poor register allocation in the compiler. I've come to the conclusion that tail calls are the best solution to this problem: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...

I made Web49 because there are not many good tools for WebAssembly out there. WABT is close, but the interpreter is too slow and the tools megabytes in size each. Wasm3 is a bit faster but only contains an interpreter, nothing else.

Tooling for WebAssembly is held mostly by the browser vendors. It is such a nice format to work with when one removes all the fluff. WebAssembly tooling should not take seconds to do what should take milliseconds, and it should be able to be used as a library, not just a command line program.

I developed a unique way to write interpreters based on threaded code jumps and basic block versioning when I made MiniVM (https://github.com/FastVM/minivm). It was both larger and more dynamic than WebAssembly. Web49 started as a way to compile WebAssembly to MiniVM, but soon pivoted into its own Interpreter and tooling. I could not be happier with it in its current form and am excited to see what else It can do, with more work.

Maybe take a look at MiniVM[0]? It was on HN a couple months ago[1].

[0]: https://github.com/fastvm/minivm

MiniVM: A zero-dependency cross-language runtime on par with LuaJIT and C\ (19 comments)

The disclaimer at the top of the benchmark section - https://github.com/FastVM/minivm#benchmarks - seemed pretty reasonable to me.

It's very clear that microbenchmarks don't tell the whole story, and that whole application benchmarks to give more real results will be desirable later.

I mean, I agree these benchmarks don't mean that much except for being a useful way to verify that the core code is working and reasonably performant - but they're up front about that fact so calling it 'benchmark-gaming' seems a trifle unfair.

I am using https://luajit.org/ in my GCC C++ project.

Can I use this faster Lua JIT in my project as a replacement? And if so, how so?

The existing luajit doesn't do v5.1, so it would be nice to use this newer engine at the newer baseline lua version level.

The commit history looks pretty active...

https://github.com/LuaJIT/LuaJIT/commits/v2.1/

If you absolutely want a performant scripting runtime, I'd recommend taking a look at LuaJit, DaScript or AngelScript.

This seems like an awesome way of writing faster interpreters – i.e. not in assembly, but in C++ snippets you stitch together with a tool.

I did peek at the deegen tool a bit, and it seems quite large? https://github.com/luajit-remake/luajit-remake/tree/master/d...

I would be interested in an overview of all the analysis it has to do, which as I understand is basically “automated Mike Pall”

FWIW I think this is the hand-written equivalent with LuaJIT’s dynasm tool: https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/vm_x64.dasc (just under 5000 lines)

Also there are several of these files with no apparent sharing, as you would get with deegen:

https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/vm_x86.dasc

https://github.com/LuaJIT/LuaJIT/blob/v2.1/src/vm_ppc.dasc

Note: this post is not related to the LuaJIT project, which lives at https://luajit.org. luajit.io, the domain of this post, is a personal blog.

OpenResty, a platform that allows scripting NGINX with the Lua programming language via LuaJIT

Lua is perfectly capable for providing scripting support, both to support mods, or to write gameplay logic. Because of that, it's used in plenty many places. The core engine code can be C/C++, and this is what something like Love2D does, for example. For performance, you can use LuaJIT, if vanilla lua doesn't do it for you.

Development has not stopped at all. What gave you that idea?