Signals do work; just treat the value sent as though it was sent through a remote and that it is a copy of the original (e.g. the table a thread receives has a different reference than the one sent).
4 Likes
Just to make sure since this wasnât specified in the release notes, since RBXScriptSignal/Once is going to be added, are you guys planning on adding RBXScriptSignal/OnceParallel?
3 Likes
Honestly, there is no ârightâ way to do this. From my experimentation thus far, you can use AttributeChangedSignals to store information on individual actor instances and listen for them in the âmainâ (serial) thread and the actor scripts (parallel). You can fire these signals from the Actor VM and have the main thread pick them up and access any memory that has been defined in the main thread. You can then update the attributes of your Actors defined in the main thread and these will replicate back into the VM spaceâs of the Actors.
However, be warned - this be the land of race conditions and data hazards once you open up the possibility of multiple threads accessing the same âsharedâ memory space at the same time. Iâm not sure if this is intentional or not since Actors are meant to be in their own memory spaces. But, you can actually use Instance:SetAttribute() from within a ConnectParallel() call in order to trigger these events from within your VM and have them communicate back with the main thread without having to sync at all. I was totally wrong about this, resynchronizing is required!!!
I hope they keep this in since I was just about to put in my own semaphores and mutexs which would allow for some really sick IPC.
Example of multiple threads accessing same memory space
As you can see, youâre not guaranteed any coherency when goofing around with parallelism at all, guess this is why a lot of functions are not thread safe at all 
.
3 Likes
Thatâs clever, and might be of use if Im doing something complex that results in a small value being determined. Thereâs no way if youâre populating a giant table right? I tried firing a bindableevent with the table and that ended up taking longer to complete than generating the data itself
1 Like
One of the benefits of parallelism is that you can actually do two things at once! With my current method, one Actor must wait for another actor to finish before it is allowed to look at the table in the main thread. However, thereâs nothing stopping me from just putting some semaphores and mutexes in place which allow two processes to access the same table at once in a âsafeâ way.
So, create the table and process it at the same time. Kind of hard to pull off in a way that doesnât cause really weird problems. But, itâd be the fast way to do what youâre suggesting (at least from what Iâm understanding).
Iâd steer clear of bindable events. Each Actor will get itâs own personal copy of the BE youâre attempting to fire so it wonât replicate back to the main thread, nor can you do cross-actor communication with them (could be totally wrong about this).
Another funny thing (as demonstrated in my prior post); Is that Actors (by design) communicate without any determinism whatsoever unless you specifically implement it as such yourself. This is called unbounded nondeterminism because an Actor could given a lot of things to process by other Actors and eventually those things will be processed, regardless of arrival time. It really depends on how your Actors are set up honestly.
Your best bet is to communicate as often as possible. Data taking too long to send when you send it in one huge chunk? Just drip feed it to the Actor that needs it in smaller chunks, theyâll all arrive eventually, even if other processes are accessing that same Actor. Data taking too long to generate? Iâm sure that Actor that needs it would be happy to process smaller chunks of it while the Actor thatâs generating it keeps generating it.
Hopefully Iâll have something to demonstrate what I mean soon. But, Iâm sure others could chime in and explain this stuff way better than my (likely) misinformed understanding of how Actors should/could/do work.
1 Like
How does this affect code that is running on the server? I have a game that runs some extremely extensive processes (to the point that I have to implement waiting to prevent CPU locking) for full map saving and loading of a large map.
In my specific case:
- Would implementing parallel Lua this mean that the CPU no longer locks for my operations, as a theoretically more efficient backend could handle prioritizing the main thread over the saving systemâs thread(s)?
- Would doing so actually improve the performance in some meaningful way? Currently, the runtime of a full map save is around ~88-92 seconds with a fair amount of intentionally added delay in order to prevent the playerâs experience from being heavily affected.
I am glad to see this come out and personally know some people who have been waiting for this to optimize their CPU-intensive tasks. Very cool!
3 Likes
-
I wouldnât recommend âparallelizingâ your backend. Actors lack the concept of a global state so giving them the duty of processing âbackendâ things wouldnât work.
-
If saving your map is an operation that can be parallelized (split into asynchronous, purely local, and independent Actors) then yes! Map loading is likely to benefit from this because you can give Individual Actors the job of loading parts of the map in chunks/regions.
2 Likes
Iâm still entirely confused on how to use this. Does the actor need to clone and go into things that need to run it? Say I have several hundred parts that need to do some ray math, do I have to clone an actor into every single one or parent them under the actor? I tried looking for tutorials and examples but few pop up.
2 Likes
Do microprofilers currently support parallel Luau? it seems like my code isnât actually being ran in parallel despite them being under Actors:
4 Likes
Iâm having the same problem, I canât seem to get any code to actually run on separate threads even when the scripts are in separate actors and Iâve called task.desynchronize().
2 Likes
Why did you put up a picture of Massless?
1 Like
Pretty sure it was to show that the new documentation shows whether or not properties are read or write safe in parallel code.
2 Likes
Cool stuff but I am wondering:
Can you run multiple instances of a modulescript (constructor call with modul.new()) that have been required by one script in true parallel mode?
Since the script itself is the child of an actor, shouldnt all the instances created by this script run under the same actor and thus run in one thread on one core?
1 Like
Then the code would not parallelized - only run in another phase.
3 Likes
You are absolutely right XD I am not sure what I was thinking of lol
Sorry!
1 Like
If all of the objects are constructed by the same script, then they will be ran on the same thread.
1 Like
Light mode when? It hurts to read in dark mode.
2 Likes
Very exciting, but Iâm still waiting to be able to edit at least the position property in parallel. Hopefully thatâll be sooner rather than later.
Realistically though, how many resources does a game have - how many threads can a game run?
Also is this a LuaU feature or exclusive to Roblox? As I imagine LuaU extends Lua with libraries but it could never run 2 processes at once?
We donât know how many hardware threads Roblox offers per server, but it shouldnât matter. You can create as many threads you wish as long as theyâre utilized effectively (e.g. youâre not creating a thread every time you need to run a 0.05s math operation, nor do you create new threads every second), as long as you donât take it too far and make 1000+. You can have way more threads than there are hardware threads available (e.g. a 4-core CPU will have 8 hardware threads, but you can have 100 threads and the work will be distributed across the 8 hardware threads just fine).
Luauâs multithreading depends on the Actor system, which is only available on Roblox. Nor do I see any mention of multithreading on Luauâs Github. Hence, it is safe to say that Luau open-source still lacks multithreading. As for the future, the above replies from Roblox devs mentioned that they donât have any plans for making multithreading a code-only concept that doesnât need Actors, so I wouldnât expect the Luau open-source to get multithreading anytime soon.
1 Like