Been waiting for this for a long time. I managed to greatly increase execution speed of my custom pathfinding with the previous preview, but the stability was questionable. Can’t wait to see how it will perform now.
17 Likes
YES, I waited SO LONG for this, I have so many funny ideas for optimization and speed now.
Last time I did a experiment with 3000 zombie AI in a server it worked mostly fine for me but anyone who joined the game with a older PC would just straight up freeze or their FPS would get smacked down to 2 FPS.
This update is a gift, multi-threading, finally games can be much faster and more efficient with their code.
20 Likes
Would definitely appreciate an official tutorial, use cases and best practices.
This new technology is great but can be very dangerous too if not utilize correctly.
Some examples:
- How many Actors should average game have based on average user device’s computing power
- How many Actors are too many
Also typo @EthicalRobot
41 Likes
I hope people make examples on how to use this properly and what you can do with it. because i’m not really clear on it’s benefits
11 Likes
While I find this extremely hard to understand, I understand what it is, and plan on learning it.
This is gonna be great for performance on multiple, multiple games if they utilize it. We’ll just have to wait, I guess.
8 Likes
It allows execution of multiple tasks in parallel, thus performing them at the same time. There are multiple issues with this.
First of all, different threads will finish at different times depending on the workload. This can cause inconsistencies and you’ll have to yield the rest of the code until the working threads finish to avoid missing information.
Next up, multiple threads can access and write the same information. Most other languages introduce mutex, while Luau has task.synchronize. When called, it makes the thread run as a coroutine.
Finally, you can’t just slap :ConnectParallel everywhere and expect it to work. Working with threads is a messy process which will either result an inefficient and buggy mess, or a considerable speed up.
In short, imagine distributing workload in a team. Right now it’s as if one person does everything. They can only perform one task at a time. It’s slow, but with little room for error. Parallelizing is the same as distributing work among a large team. It might not look like much at first, but the members are stupid and need every little detail explained to them.
37 Likes
Isnt that like creating a new coroutine, or using spawn()?
2 Likes
WRT means “with regard to”, but you’re right I should have spelled this out.
14 Likes
Threads created through coroutine or spawn don’t run in parallel, they run in sequence.
6 Likes
Has an optimal number of threads/VMs that can be deployed in a server to maximize their utilization/performance potential been calculated yet? Or is this dynamic according to where the game is hosted (silicon lottery et al)?
1 Like
We have some tunable values we hope to adjust find the sweet spot for VMs/thread. We have started with some value that make sense, but when we have more content to test on this will continue to improve.
5 Likes
GetService and FindService currently aren’t considered thread safe, is that intentional or a bug?
Also, is findFirstChild different from FindFirstChild in its thread safety?
(i renamed Workspace to a)
This is intentional, as the Service you get would be by definition outside of the Actor. This is something we will be looking to open up more in future releases.
1 Like
findFirstChild lowercase is deprecated, so we didn’t add the ThreadSafe tag to it. Please use the uppercase version.
5 Likes
Your puny engine restrictions have no power over me!
Script called Heartbeat:
game["Run Service"].Heartbeat:connect(function()
local ti = tick()
print("Start Heartbeat")
repeat until tick() - ti > 0.01
print("End Heartbeat")
end)
Local script called Renderstepped
game["Run Service"].RenderStepped:connect(function()
print("------------------")
task.desynchronize()
task.synchronize()
local ti = tick()
print("Start RenderStepped")
repeat until tick() - ti > 0.01
print("End RenderStepped")
end)
That being said, are there plans to add another event to Runservice to allow the execution of serial lua before parallel lua within the same frame?
2 Likes
This is something we have been talking about as it would be nice to set things up, let the parallel phase run, and then use the results all in one frame. How we will enable this hasn’t been decided yet however.
9 Likes
Coroutines emulate threads by placing tasks in a queue. It will resume a task if all other tasks are yielding, so only one task can run at a time.
1 Like
I hope this will scale with the amount of players or in some other way. A server with around 10 players might not even need multi-threading, but it is a must on servers with over 50 players. Also, some genres like RTSs would benefit much more than more casual ones.
I’ve made some upgrades to my parallel terrain generator since the previous revision.
It’s hard to really show it off in one clip though, best to check it out for yourself!
ParallelTerrain.rbxl (55.4 KB)
Hopefully I can test this in a live game soon.
55 Likes
good stuff. ive been wondering what this actor stuff that ive been seeing around was. finally the uncomfortable feeling of crunching a lot of numbers in a synchronous thread is gone, at least partially. the explanation was a little confusing, though; why is writing to instances restricted? id think that as soon as an instance is written to that write would be visible to other scripts like normal. if this isnt the case, why? if it is the case, whats the problem?