Luau's performance
5 comments
·October 23, 2025Rochus
eterm
The thing that sticks out at me most on that table is "Mandelbrot" being such an outlier, has the LuaJIT implementation been checked over?
Looking at the code, it looks like the Mandelbrot algorithm has a version-switcher, so does that mean LuaJIT is going down the < 5.3 path?
( Sorry, this isn't my area of expertise, I'm just trying to make sense of the table! )
Rochus
> has the LuaJIT implementation been checked over
Just re-checked that I inserted the Luau Mandelbrot results in the correct cell.
> does that mean LuaJIT is going down the < 5.3 path?
Yes.
bjoli
It is obviously a choice why isn't done, but with static modules you can know whether * is overloaded. That will improve procuedure calls by a lot, almist always. sure, with polymorphic finctions you can get a bit of the way using inline caches, but in my experience knowing the callee is always going to be a speedup.
bstsb
i use luau a lot as part as my Roblox development work, it's pretty fast for its main use case.
there are people a lot more knowledgeable about this topic so i won't pretend to know this is possible, but could a versioning flag similar to the !native flag be added? it would allow both for backwards compatibility and better optimizations, although i know it might add complexity where it's not needed
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.