Skip to content

Allows limiting the amount of worker threads and sets the default max to 4 - #355

Open
luponix wants to merge 1 commit into
overload-development-community:mainfrom
luponix:ready-for-pr/worker-threads
Open

Allows limiting the amount of worker threads and sets the default max to 4#355
luponix wants to merge 1 commit into
overload-development-community:mainfrom
luponix:ready-for-pr/worker-threads

Conversation

@luponix

@luponix luponix commented Aug 14, 2026

Copy link
Copy Markdown
Member

Unity 2017 implemented a very early version of the job scheduling system.
The Engine prepares as many worker threads as there are virtual cores (-1) to take care of parallelizable engine work.
Jobs go into a global lock free queue and then then the main thread wakes up a number of worker threads to take care of them.
It signals this by using semaphores.

Unfortunately it has some weak points:

  • The main thread is the one paying for the synchronization overhead and can become the main block.
  • The more cores there are available the higher the cost of synchronizing the action of assigning/removing tasks
  • Workers threads can steal the tasks of others threads

So in order for a worker thread to be a net performance gain tasks need to be time intensive enough to overcome the synchronization overhead and that overhead grows further with rising core counts.

This patch adds a command line argument:
-worker-cpus <n> limits the amount of reported cores to [1..n..virtual_core_count]
-worker-cpus 0 disables the clamp entirely

Tests with a 13700k with 24 virtual cores:
In a real multiplayer match with 4 bots, started from a second machine,
i measured a 34% increase in average framerate (393 -> 527) and up to 86% improved 1% lows when reducing the amount of reported virtual cores to 6.

In very populated matches with 10 players framerates no longer significantly dropped with each player which used to reduce my framerate from 550 to less than 300.

The best frametimes (Avg+1%+0.1%) were measured when reducing the amount of worker threads to 0.

And this behaves similarly between Windows/Linux, Intel-/AMD-CPUs.

The only unknown is at which point CPU's have low enough cores and low enough single core effectiveness that handling work in worker threads becomes effective again with the additional factor of limited laptop CPU's.
(or non multiplayer scenarios)

That is why i think making the limit configurable instead of disabling
and setting a default of 4 should net most people a decent improvement if they are CPU bottlenecked
while likely (untested) also keeping us well above the floor where worker threads might be a benefit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant