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.
Thank you, I kept waiting for a chart or some numbers that never came. Per usual, we are talking about orders of magnitude difference compared to actually high performing code. Another word for that is "slow". Just worlds apart in expectations.
Of course the lesson is when it comes to performance, it's extremely hard to make up with tuning what you lose in language design. You can optimize the work all you want but nothing beats designing it so that you don't have to do a good chunk of it in the first place.
I’ve always been curious how Roblox games are deployed and managed. Is each instance of a game executed in a docker container, and the luau code isolated that way or is there some multi-tenant solution?
They run the game servers in Docker. Doing multi-tenant is a weaker security boundary and makes it easier to steal places from other users, which Roblox takes pretty seriously when places represent all the time invested by game studios and millions of dollars in revenue.
I haven't used Roblox but Lua has the ability to create sandboxes to run user code. You expose only the functionality you allow to the user code, usually block I/O, and any unsafe functions. https://luau.org/sandbox
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.
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
i'm impressed how much the runtime is optimized across so many layers - pretty rare to see an interpreted language push this far without a JIT. Do you see this approach eventually rivaling JIT performance for real world workloads, esp where predictability matters?
[+] [-] Rochus|5 months ago|reply
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.
[+] [-] eterm|5 months ago|reply
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! )
[+] [-] ModernMech|5 months ago|reply
Of course the lesson is when it comes to performance, it's extremely hard to make up with tuning what you lose in language design. You can optimize the work all you want but nothing beats designing it so that you don't have to do a good chunk of it in the first place.
[+] [-] le-mark|5 months ago|reply
[+] [-] chc4|5 months ago|reply
[+] [-] chadcmulligan|5 months ago|reply
[+] [-] bjoli|5 months ago|reply
[+] [-] bstsb|5 months ago|reply
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
[+] [-] ramanvarma|5 months ago|reply