Full Release of Parallel Luau V1

Updates Announcements
#26

Disappointed in the ‘full’ release not having read/write abilities given that’s honestly the main importance of it.

13 Likes
#27

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
#28

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.

#29

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
#30

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
#31

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?

#32

Hell yeah!
I was planning to run my AntiCheat in parallel so this is awesome news!

3 Likes
#33

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
#34

can you explain how Paralled Luau will help with complex in-game ai. just curious

#35

After a long-awaited release, we finally got it!

1 Like
#36

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
#38

Cool feature, yet in it’s current state it is impractical and unusable, not sure why this was even released?

8 Likes
#39

Long Awaited, I’m going to start experimenting with this right now.

1 Like
#40

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
#41

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
#42

Yeah, there’s going to be more documentation / tutorials on this feature in the future. Additionally, while right now it’s difficult to communicate between Actors realistically (the feature works best when you can split isolated units of work into actors), we’re working on additional features for message passing and sharing data that will make this much easier / practical. So effectively what we have released is “parallel scripting V1”, with V2 already being worked on.

It’s included into the release and works the same way as described previously. It looks like the documentation for this is currently missing, as per above we’re working on backfilling the documentation for this feature.

18 Likes
#43

Thanks for the request! You’re right, there’s no reason for GetPlayers to be marked as Unsafe. Unfortunately we have to manually audit and annotate each function that can be used in parallel, and we missed this - we’ll fix it!

12 Likes
#44

Absolutely awesome system! I’ve been using it for a long time in my game, and I’m glad it’s evolved into something that can be officially used in-experience.
My main qualms with this though is that despite it’s promising functionality, the learning curve seems to be overly steep, and even now I’m not sure how it works. I was able to get ahold of Elttob’s code which allows you to directly run modules in parallel, which I found to be a way easier system than what’s currently offered with Actors. For reference, here is my modified version of the Parallel module:

local RunService = game:GetService("RunService")

local Parallel = {}

local workers = {}
local waitQueue = {}

local numRunning = 0

local workerFolder = Instance.new("Folder")
workerFolder.Name = "__ParallelWorkers"
workerFolder.Parent = game:GetService("Players").LocalPlayer.PlayerScripts

local actorTemplate = script.ClientWorker

local function getFreeWorker()
	for _, worker in ipairs(workers) do
		if worker.available then
			return worker
		end
	end

	local newActor = actorTemplate:Clone()
	newActor.Parent = workerFolder

	local newWorker = {
		run = require(newActor.WorkerMain),
		available = true
	}

	table.insert(workers, newWorker)
	return newWorker
end

function Parallel.runParallel(functionModule, ...)
	local worker = getFreeWorker()
	numRunning += 1
	worker.available = false

	worker.run(functionModule, ...)

	worker.available = true
	numRunning -= 1

	if numRunning == 0 then
		for _, thread in next, waitQueue do
			task.spawn(thread)
		end
		table.clear(waitQueue)
	end
end
function Parallel.waitForThreads()
	if numRunning ~= 0 then
		table.insert(waitQueue, coroutine.running())
		coroutine.yield()
	end
end

return Parallel

Thanks to it, I was able to very easily setup my code to run in parallel by just separating the code I was interested in parallelizing into a separate module, and calling Parallel.runParallel(Module).

6 Likes
#45

Yup, we’re aware of these limitations (in addition to the aforementioned sparsity of documentation that’s being worked on!). Briefly, there’s two modes in how the system can be used:

  • Each isolated entity, like an NPC / car / etc., gets an Actor with a bunch of scripts inside it that can subscribe to parallel events / use task.synchronize / etc. The use of Actors is important here because they delineate DataModel access, which is going to be important in the future once we start allowing changing DataModel in parallel.

  • A script isn’t really related to a specific subtree of the DataModel and just needs to perform some work independently; however, due to the existing interface, it needs to use the Actors which can be awkward compared to the first category of use cases.

We’re looking into whether we can solve the second use case more ergonomically, but it is a little difficult to solve it “perfectly”, so we’re hoping that in the meantime helper libraries can be used for such ad-hoc parallelism.

13 Likes
#46

I’m not sure we ever promised this?

I remember things incorrectly, mb, it wasn’t from RDC, I am getting a secondary source from someone who had a conversation with yourself about this. And the following was something like:

“Parallel Luau’s current implementation isn’t the full picture. Eventually you should be able to spawn parallel threads in the same way that you spawn coroutines, traditional module architecture is something we want to accommodate. Cloning scripts and parenting to special instances is just how it is for now.”

What I think the problem is with Actors right now is that they are coupled to the datamodel, as you mentioned. I believe Actors in their current implementation have a valid use case and should stay as they are, however I want a different way to create threads in a pure luau environment that are isolated from the main thread’s memory and communicate via message passing. But unlike actors, they would not create an associated actor in the datamodel since managing instances can be annoying.

10 Likes