Full Release of Parallel Luau V1

After months of iterating on the feature and with the help of the Roblox community, we are happy to announce that Parallel Luau has graduated to General Availability. This feature allows developers to break their experiences up into logical sets of actors, and was released first as a developer preview and then as a studio beta.

To get started with Parallel Luau, you can check out this article. In addition to this small tutorial, the API documentation now includes tags on every method and property.

Starting today, all methods that modify instances are marked unsafe, and no properties are marked safe to be written to in parallel. Over time we expect to slowly make more of our API methods thread-safe as we continue to improve the Roblox engine.

We are also exploring more APIs specifically targeted at parallel execution to make it easier to convert existing experiences to use actors as well as introduce new ways to communicate data between actors. Rest assured, this is just the first release. We will keep working on maximizing efficiency and ease of use of parallel script execution.

It has been amazing seeing all the things you have created during the beta period. We can’t wait to see these creations in their final form as live experiences.


Major Changes Since the Beta:

  • Scripts that call synchronize and desynchronize can change between states within the same frame. See details in the following section.

  • The debugger now works in script rooted under Actors, both in parallel and serial contexts.

  • require() is no longer allowed during the parallel phase. Require scripts you want to use first in a serial context.

  • Access to some properties in the RaycastParams and RaycastResult objects have been marked as unsafe. We hope to loosen this restriction in the future.

Multiple synchronize/desynchronize within the same frame

Some of the previous examples showed code to the effect of:

while true do
      task.desynchronize()
      dowork()
      task.synchronize()
end

… to do some work every frame. This will now result in the dowork() function being called multiple times per frame as the state transitions between parallel and serial do not require the engine to advance to the next frame. The task.wait() function can be used instead of task.synchronize() to wait one frame.

The number of transitions per frame is still limited, so code using the older paradigm will not crash your game, but will likely be inefficient and not do what you want.

256 Likes

This topic was automatically opened after 9 minutes.

Thank you! I can’t wait to see this in action!

8 Likes

(post deleted by author​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​)

13 Likes

This is awesome, however, it sucks that there isn’t an RBXL file in the parallel luau document, to actually show the use of it, and how you should actually put your actors.

44 Likes

I look forward to seeing this in action! Glad to see that Roblox is continuing to take thread security seriously.

2 Likes

Glad to see this finally arrive, however could the documentation/article on this be a little bit more informative? It barely has any information on the topic.

https://create.roblox.com/docs/scripting/scripts/parallel-scripting

26 Likes

Probably one of the most important releases Roblox had and will have for years. Would love to see developers naturally spreading out game workloads across multiple threads whenever possible.

2 Likes

Will Roblox start to move internal scripts running on lua over to parallel lua where possible?

3 Likes

Very confused on how to use this. Do I just parent the script to an Actor and do task.syncronize()?

4 Likes

So, is calling functions such as :FireServer() and :Destroy() safe?

Edit: Checked the old documentation instead of new one

1 Like

Not in parallel, if you look in the documentation site you will see they are marked UNSAFE.

8 Likes

This sounds cool and all and since it’s a β€œβ€β€œnew”"" feature there’s all the hype, but I have no clue how I’d use this; especially because so many things are unsafe. Can someone come up with a few examples?

11 Likes

Multi-threading in Roblox? les goooo.
Now I can finally make stupidly complex AI logic multi-threaded.

Or use it for something CPU intense like inverse kinematics.
Always wanted to see how that would go if offloaded to a different core.

1 Like

Will this open the door to making Roblox games with microservices, and eventually having worlds that far exceed today’s max-players-per-server? I hope it does. I’m not entirely sure what the current max-players bottleneck is, so I could be getting my hopes up for nothing. Either way, more efficiency is very cool!

Thank you, now I have a good excuse to buy a Xeon processor!

More seriously, will this help me out much? I have a quad-core processor with nice clock speeds but really bad per-core performance. (before you ask, it’s an AMD A12-9720P.) Will this give me better performance overall when using many Actors?

2 Likes

YES FINALLY
Ive been waiting for this, now I wont have to do the require () thing! :+1:

Docs: β€œFor best performance, use as many Actors as possible”
Me: used 200 actors split into chunks to create a raster image by raycasting many points in game. (completely adjustable idk)
Edit: was 400

2 Likes

Any chance that someone could look into whitelisting Players:GetPlayers(), it should be safe to call in parallel as it’s just like calling GetChildren and IsA to filter only players. Had a few pain points coding around GetPlayers in Parallel Lua so I just made my own function for now to get players.

Other than above, I’ve had a great experience working with Parallel Lua so far!

5 Likes

Is there a list of all Safe/ReadSafe/LocalSafe properties & functions? It would be nice to have a constructive list, so I don’t accidently fry anything

Also, the Docs Site is just plain unreadable

image

9 Likes