Faster Lua VM Released

Updates Announcements
#83

The second one wouldn’t work as variable names are no longer present in Luau.

1 Like
#84

Is this also an issue for Server-Side code?

Maybe Index type with ‘name’ nil value instead?

#85

Yes. No variable names are present anywhere in the new VM.

1 Like
#86

This seems good enough for me, I suppose–“attempt to index nil with ‘bar’” should be good enough to figure out where the actual issue is. Thanks for the speedy response!

5 Likes
#88

I think I found a bug @zeuxcg

Here’s a simple repro:

print("A", assert(1))
print("B", (assert(1)))

image

Oddly, reversing the statement order seems to fix it.

print("B", (assert(1)))
print("A", assert(1))

image

It seems to only affect the first assert expression that could potentially apply a variable number of arguments to a function call.

I found this when one of my plugins errored while using rawset with an assert:

rawset(self, k, assert(v))

image

It doesn’t look like it affects the live game and I can only repro it on the studio window I’ve had open since this morning, but I can get the code above to repro consistently in my command line right now.

VM optimizations might get complicated when assert could potentially return a tuple due to setfenv, or when the supplied number of arguments is unknown e.g. assert(foo()).

As a side note for assert optimizations, I’ve found that the most performant way to make assertions is to convert this:

local foo = assert(bar)
assert(bar)

into this (respectively):

local foo = bar or assert(nil)
if not bar then assert(nil) end

Of course this comes at a cost to readability, so my game’s compiler converts it automatically before I publish.

2 Likes
#89

I can only repro it on the studio window I’ve had open since this morning, but I can get the code above to repro consistently in my command line right now.

There was this bug report from a while ago:

The flag that caused this was reverted:

I can confirm that this doesn’t happen anymore on a freshly opened studio session.

1 Like
#90

I’ve been waiting for this update for some time, thanks ROBLOX Devs.

#91

With the optimization that we had to roll back (which will come back in a few weeks after the fix), free-standing assertion statements that return nothing are very cheap so you don’t have to do this conversion anymore I think.

That is, the optimal code would be

local foo = expr
assert(foo) -- or assert(foo, "something terrible happened")

Unfortunately, computed assertion message will still be costly, so something like

local foo = bar.baz
assert(foo, "something terrible happened with " .. bar)

is still going to be expensive, but that’s hard to fix without introducing debug.assert or some such.

7 Likes
#93

Great work to the people who made this. This is pretty revolutionary; will the VM ever be open sourced though? :thinking: This could be very useful on projects outside of roblox, too. My discord bot uses Lua, and though it’s not necessary to be as fast as a live game, it could still be implemented.

#94

I see increased security as one of the biggest benefits from this update. Can’t wait to see how it plays out honestly.

#95

If you’re using Discordia and Luvit to run your bot, that runs on LuaJIT meaning it’ll almost certainly be faster than Luau because of the JIT.

#96

Oh, so Luau isn’t faster than LuaJIT? I haven’t learned enough about Luau to understand exactly how it works. I know LuaJit was pretty dang fast though. I assumed Roblox was using LuaJit before Luau.

And yes my bot uses Luvit & discordia

#97

Luau is regrettably not even close to being as fast as LuaJIT with the JIT enabled, let alone faster. That’s to be expected though because JIT compilation is absurdly fast. Rather than go into why they didn’t ever and still aren’t using LuaJIT, I’ll just link you to Zeuxcg’s in-depth explanation.

That being said, Luau is extremely fast. It runs on par with LuaJIT with the JIT compiler turned off. So I’m not saying it’s slow by any means. I’m just saying it’s not anywhere near LuaJIT’s sometimes-near-C speed.

Though I am interested in a stand-alone binary release for Luau, especially once Typed Lua becomes a thing. It would be nice to be able to run and test code outside of Roblox (or even use Typed Lua for projects outside of Roblox :open_mouth:).

1 Like
#98

A Luau language server would be nice…

#99

While I am aware of JIT being disabled on Apple based products for security reasons, I do remember that oretty much every other platform Roblox is on supports it on some way. Android has it by default, just like all supported Windows versions. While I’m not familiar with console development, I do know that PS4 and XBox support it in .NET and Mono, so whatever Roblox is using could potentially access JIT.

#100

Note also that JIT as implemented in LuaJIT is prone to frequent deoptimizations or, like LuaJIT calls it, trace aborts. It can be amazingly fast on stream processing code, but on regular code the gains are likely to be less impressive. The JIT designs we have in mind - not sure yet when/if this would happen - are very different from what LuaJIT does, for better or for worse.

5 Likes
#101

This is really exciting, and I am glad this is released. Been looking forward to this.

2 Likes
#102

The idea of potential JIT in the future is exciting even if it may never come to pass. If the designs you have in mind are less finicky, it’s probably for the better.

Is there any chance of us getting some sort of standalone version of Luau in the future? It’s probably too thoroughly ingrained inside of Roblox for that to be practical, and I’m not sure if you’d even be interested in doing that, but I thought I would ask just in case.

#103

Yeah we have a plan for this. Probably won’t happen this year though.

2 Likes
#104

The new Lua VM sounds great! Looking forward to making scripts run a lot faster, etc! Keep up the great work, Roblox!

Now I can brag to random people that the Lua VM I’m using is faster than theirs and they might not have a clue. >.<