“More cores!” is a growing trend in consumer CPUs. It’s always bothered me that I can’t take advantage of this in Lua. I’m suggesting multiple Lua VM’s that communicate using BindableEvents/BindableFunctions as an IPC. Each instance of Lua could run on its own core for huge performance gains. There could be an API for spawning a script potentially in its own VM on a different core, or this could just be utilized by CoreScripts.
Some use-cases:
CoreScripts could run on their own core.
More core game code can be moved from C++ to Lua without performance problems.
Lua animation systems for things like characters, weather or foliage could be given instructions over bindables and run on their own core.
This could open many doors for the future of ROBLOX programming. I’m not sure how much of the API an extra Lua_State on its own core would be able to interact with, but I’d love to know what the client team thinks @zeuxcg@CodeWriter
If we went down the lua multithreading road we probably wouldn’t want to expose the number of cores the user has. The best interface would be the developer telling roblox to spawn x function in another vm, and then roblox figuring out if it should do that or just spawn it in the same vm.
This is not just nescessary - it is mandatory for further development of Roblox. Just because Roblox hasn’t made this step already, we’re not seeing games like phantom forces or mad paintball 2 being available on ALL platforms.
Whatever the means, if Roblox doesn’t find ways to quadruple client general code performance, the game development advancements will stay frozen for the next couple of years.
This really won’t help as much as you think. These extra threads wouldn’t really be able to access the datamodel in any appreciable way and could only be used for heavy background processing.
Most games really don’t do a lot of heavy background processing.
I think this is a decent idea and stuff like LOVE2D is already doing this.
But, it’s not as useful as you guys might think. Only one of the Lua threads would only be able to access the data model. I suppose you could implement Lua mutex locks, but that essentially makes you single threaded.
If this were to happen, you’d end up with like one thread accessing ROBLOX APIs and the rest just doing raw calculations in Lua. I really don’t think there’s many games out there that would benefit from this.
This thread addresses a legitimate issue, which is that Lua is really slow.
Multithreading is not a solution. The absolute best-case scenario is that your code gets 2-4x higher throughput in some limited cases, but throughput != speed. Games tend to be control-flow heavy and hard to parallelize, which is why you don’t even really see that many AAA games using multiple cores effectively.
LuaJIT completely solves the problem and does so invisibly, but that’s for another feature request.
A good way to argue for that change would be to show actual instances where your game is having performance troubles caused by Lua.
This is hard. We’d be able to expose almost no API and communicating between Lua states will be very hard and involve pretty expensive operations that could make the point moot. The value of threading is generally either tasks where you have a tiny input, tiny output, and lots of processing inside, or environments where you have low-overhead low-friction cross-thread communication. Lua can do neither, and if there are tasks with tiny input&output and lots of processing inside, the better way seems to be to identify tasks that are common and expose them as API - that gets way more efficient than Lua anyway.
We can’t run LuaJIT in JIT mode on basically all platforms where it would be beneficial so that’s out.
We are working on a lot of performance improvements in the Lua binding layer so that calling ROBLOX APIs becomes faster, and will be focusing a bit on Lua performance as well.
Not really. Lua basically works like Python in this respect. A lot of things in Lua would break if Lua threads started concurrently mutating objects, even if they never mutated the same object (and if they did we’d be exposing ourselves to unfixable ways to accidentally crash the client which is not a world we want to be in)