Studio still uses the default 8 workers
While In game its only using 3 workers
3 Likes
afaik this is the timeline of events for the worker count.
A year ago: Server worker capped at 2, Client Capped at 8.
A few months ago: Mobile Clients decreased 8 → 2
Recently: Mobile Clients Increase 2 → 3. Desktop decrease 8 → 3
2 Likes
This is false. It was always capped at 8 for client and 2 for server. Now the client has reduced down to 3. It does not matter what cores/threads your CPU has.
Studio is still at 8 as Haotian said.
1 Like
I believe this post is talking about a cap on Server workers, however what does not make much sense is that there is the hard cap for Client workers is at 3 instead of the usual 8.
Thanks for the report! I filed a ticket in our internal database and we’ll follow up when we have an update for you.
7 Likes
Hello, sorry for the bump. Is there any update on this? I have a heavy actor-focused system that is affected by this.
5 Likes
Hey, please get back to us with an answer; my rendering solution is viable under Studio with 8 workers but the live client being limited to 3 kills any potential performance I can gain from this.
I already have optimised the screen space to the point that I am rendering 1 out of 8 pixels every frame with minimal artifacting, and I intend to create optimisations / caches in other spaces, but for as long as this worker limit is in place on my 16 core CPU, I will never be able to push the full potential of what I am working on.
I also believe this worker limit is why a lot of folks simply don’t bother getting involved with Parallel Luau, despite the obvious potential.
6 Likes
I ran into this same issue. This is a huge blocker for my game as I need to be able to properly utilize parallel luau for my performance intensive application. Please fix!!
2 Likes
Honestly idk why Roblox doesnt dynamically adjust max worker count and just put that value in the Stats service,this way folks who have 2 cores like me wont bring down people who have more and want to utilize them fully
Since there are 4 vms per core and each core can be represented as a worker, that means to get the number of vms you simply have to do StatsService.MaxWorkerCount * 4 (if this is implemented)
Sorry to bump this again, but I’m actually measuring 6 workers being available on mobile for some reason. It seems like the cap might not be active on mobile? But, on desktop, I can validate that there does seem to be an artificial limit of 3 workers (my macbook has 10 cores but can only use 3 for actors in game, 8 in studio).
1 Like
Hey, it’s been 4 months since this faulty behaviour has been reported with no explanation as to why the behaviour of this system changed unexpectedly.
This is a follow up to my last update request 2 weeks ago.
Would really appreciate if you gave us an update on fixing this issue.
4 Likes
sorry to bump but has this been fixed? if this is intentional this will make parallel lua virtually useless
3 Likes
I’ll just link this reply I made on one of my threads
Please revert this change, parallel lua was already rarely worth doing, now it’s even worse
2 Likes
It probably is. Happened the same day mobile thread count went up to 3.
1 Like
@Ro_JJam could you forward this bug to someone? It seems to be quite a big issue.
If it’s intentional, I hope people know it’s negatively impacting many.
2 Likes
I’ve shared my thoughts about this issue in this post.
With the incredible lack of communications surrounding this topic it in-fact does the inverse and communicates a lot.
If it’s for security, or for other internal reasons in which staff are not allowed to discuss, then we will not be seeing this limit increase in the future; Parallel Luau allows developers to create their own software solutions to other things that Roblox can’t appropriately express policy on in a way that allows them to effectively automate it.
It would be incredibly helpful for Roblox to respond as to why this limit is in place and does not seem to be changing as there seems to be a lot of us with our projects in limbo waiting for clarification on this issue.
2 Likes
Hey, I asked them about it and this issue is on their radar and they’re still working on improving parallelism, but I guess they don’t have anything concrete to give you all yet. I was told that in the future, the worker count won’t be a fixed number and will be tied to the number of CPU cores but there’s no timeline for that. I think it’s likely that the issue might be rooted in the engine, which takes a long time to fix.
9 Likes
Thanks a bunch for looking into it, the effort as well.
It’s good to know they’re aware and it will likely be uncapped eventually. The issue itself being complex and/or difficult to change is understandable, though not the best news for some.
Glad to hear this is being heard somewhere, scaling workers with CPU cores would be great to see but it’s a bit concerning that there’s nothing further on fixing this issue in the meantime. This issue is actually just a FastFlag setting (DFIntRuntimeConcurrency). Changing it works as expected, setting it to 8 resulted in 8 worker threads, and very large numbers seem to already get capped by the engine.
According to the FastFlag tracker, the flag was created in June last year (set to 2), then raised to 3 in October. I don’t think the limit worked properly around this time, as I remember having 8 workers in the client in October. It seems that this was fixed (unfortunately…) sometime in November. Then, on March 18th, the flag was set to be platform specific, although for some reason this change left PCDesktopClient and MacDesktopClient at 3 despite Studio being set to 8 on the same platforms.
Would it be possible to raise this value before the new core-based worker allocation is available? This is genuinely crippling for quite a few experiences (and has been for months now), which is very frustrating when it’s just a FastFlag setting.
1 Like
Thank you very much for getting word on this; it means a lot for you to ask about internally to see what’s going on so we can get a glimpse and anticipate the trajectory of a certain feature.
While unfortunate (yet understandable) that there’s no concrete dates, at least now we know that the worker count will eventually be tied to the host’s core/thread count.
This will give me motivation for working back on my renderer, knowing that the required performance will be possible in the not-so-distant future.
Thanks!
1 Like