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.
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! )
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.
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'm aware of the early difference between compiled and interpreted languages. Luau has to be interpreted to meet its security goals, and I'm asking with similar goals in mind, so I guess I'm starting from that significant limitation.
All of these introduce guards in with JIT or inline cache, preferable to have no guard at all
This isn't unique to dynamic languages, see C++ map having a layer of indirection forced to support pointer lifetimes of access living past inserts. Whereas Rust doesn't allow borrowing past that, & Go doesn't allow taking address of map value
Other examples: C optimizations having to worry about pointer aliasing. Or Go interfaces having to box everything. It used to have small value types be able to avoid boxing for interface value, but dropped when switching to precise GC
bstsb•3mo ago
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