Allows limiting the amount of worker threads and sets the default max to 4 - #355
Open
luponix wants to merge 1 commit into
Open
Allows limiting the amount of worker threads and sets the default max to 4#355luponix wants to merge 1 commit into
luponix wants to merge 1 commit into
Conversation
…and clamps the default to 4
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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 0disables the clamp entirelyTests 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