This is amaizing!
Though, I’m now wondering how task.spawn() works. I Believed it was like multithreading but does the addition of actors mean that task.spawn() was just a mean of running multiple parts of the code at once?
task.spawn() was never multithreaded, it was always run serially, just “outside” of the script you run it in
5 Likes
We still dont have a state object that can cross VM states 
I wonder if there’s some performance challenge for why this hasn’t been added yet.
4 Likes
I’m excited for a larger rollout as more features become useable in parralel! Is there a rough timeline of what will come (I’m not expecting one, but if there is one that would be nice)?
3 Likes
Almost. Syncrhonize will switch you out of parallel, desynchronize will switch you into parralel.
Each Actor can run on its own in true parralel unlike lua threads (aka coroutines) which are not actually parallel and don’t ever run at the same time. They only mimic running in parallel by running only sections of code at a time, then switching to run other code (e.g. other scripts, or Roblox code) when you yield inside of them.
But, not everything can happen in parallel, because some stuff is unsafe to be used multiple times at once (stuff could write the same little pieces of memory over eachother and then end up creating a mess), so you have to switch between running in parallel and in sync.
Code that’s in sync might still run in a different thread but this is the same performance as running only in one thread, because code can only run in sequence. So we have to desynchronize and that will let our code run on its own.
-- We can do any normal stuff here like any old script
task.desynchronize() -- Start running in parralel
-- Now we can only do stuff that is safe (You should read the article linked in the OP for what that means)
-- We can do any code in parallel here so it can run at the same exact time as other code
task.synchronize() -- Now we wait until we are back in sync with the rest of Roblox so we aren't running parallel anymore
-- Now we can do anything normally again
11 Likes
Disappointed in the ‘full’ release not having read/write abilities given that’s honestly the main importance of it.
13 Likes
Now that I understand a little more, I have a little question.
Will some Roblox functions get updated so they are Safe? I noticed a lot of stuff is considered Unsafe.
4 Likes
I have been waiting since the end of December 2020 for this to come out, and I am absolutely excited to use this. Especially for implementing complex in-game A.I. that can run performantly.
Only real issue is with required modules that are mutable as detailed in previous posts and in the documentation, but it’s something I can live with. Hope to see that get resolved in some way.
Could we receive some sort of documentation on how communication between Actors is intended to work? For example, let’s say you have an Actor which repeatedly requests batches of tasks as it is ready to process. How should you go about this? Or should you instead create new copies with stuff pre-set on them as properties/attributes instead of communicating? And in that case, how do you tell a scheduler that an Actor is done with its task?
BindableEvents/BindableFunctions don’t reliably work cross-Actor because different VMs will not send these things back and forth even when synchronized (from my experimentation)
The only thing I can come up with for communication is to set attributes but this doesn’t really feel correct. Otherwise, there seems not to exist any way to set states or send information in and out of actors which I feel limits their use cases.
21 Likes
Is it possible to use actors inside of plugins, when the game is not running? I have processing tools that divide into Actors beautifully, but I don’t want to have to run the game…
Is there somewhere that the actor should be parented to for it to execute?
4 Likes
Out of curiosity, what happened to RBLXScriptSignal:ConnectParallel()? Is that included on this release, or dropped entirely? If it’s included, does it work the same as how they are described in Parallel Luau Developer Preview - Updates / Announcements - DevForum | Roblox and Parallel Lua Beta - Updates / Announcements - DevForum | Roblox?
Hell yeah!
I was planning to run my AntiCheat in parallel so this is awesome news!
3 Likes
During the last RDC, it was announced that actors as they are, weren’t the full picture for parallel luau, it was said that you would be able to parallelize your code fearlessly in a way like coroutines. Where on the roadmap is this planned? And out of curiosity, any insights as to what is currently blocking the implementation?
I imagine that regardless of the implementation, we are going to have to rely on some form of message passing via actors that have their own memory so that threads won’t have access to shared garbage collected tables.
16 Likes
can you explain how Paralled Luau will help with complex in-game ai. just curious
After a long-awaited release, we finally got it!
1 Like
Being able to run the behavior for each AI in separate actors will allow them all to run parallel.
Complex AI is hard to pull off due to performance issues when it comes to running tons of AI at once, especially if they need to perform complex calculations. Being able to run them across multiple threads in parallel will go a long way.
3 Likes
Cool feature, yet in it’s current state it is impractical and unusable, not sure why this was even released?
8 Likes
Long Awaited, I’m going to start experimenting with this right now.
1 Like
It’s also called the ‘full release’, but the most needed things(read/write) are unsafe and not released on it. This is bad practice by Roblox.
3 Likes
I’m not sure we ever promised this? Actors are fundamentally the right model for us for when you need DM access. We’re exploring some alternative ways to start code that doesn’t need full DM access but it’s unclear as of yet as to how this would work.
What might have been said at RDC, which is still true, is that today there’s a relatively small subset of engine functionality that is accessible from actors during parallel execution. This is a limitation of the engine, not a limitation of the scripting layer, and we’re looking at some drastic changes in the DM implementation to enable access to changing DM structure/properties in parallel, but those changes would require time, so for now the read/write split will likely persist for the most part.
8 Likes