-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimization coding pass over AudioMixerSlavePool and AvatarMixerSlavePool pt. 2. #1361
base: master
Are you sure you want to change the base?
Conversation
…educe spurious wakes
…mutexes to reduce lock contention.
…n managing slaves and shared data
…which hopefully stays up just from handshake agreements?)
Hey, if anyone wants to use std::shared_mutex, there's a polyfill in the commits (that was later yanked out) ;-) |
The following links are available: build (macOS-latest, full) build (ubuntu-18.04, full)
build (windows-latest, full) |
- changed "slave" to "worker" when dealing with classes in this file - moved the "data" struct to be a private member instead of a base class
Made suggested changes to this PR:
Attempted to factor out common code to a template base class but... can't do that and still use Qt |
The following links are available:
build (macOS-latest, full) build (windows-latest, full) build (macOS-latest, client) |
The following links are available:
build (macOS-latest, full) build (windows-latest, full) build (macOS-latest, client) |
{ | ||
Lock poolLock(_data.poolMutex); | ||
if (_data.numFinished < _data.numThreads) { | ||
_data.poolCondition.wait(poolLock, [&] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm…is it possible that all the threads will finish and notify between line 188 above and here? so this wait would never finish?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh, I thought about that this morning. The most recent commit now has all "condition.notify" calls holding the corresponding lock when calling it (thus forcing the notify to be before line 192 or after line 194) and the "if" statement wrapping all "condition.wait" calls bypasses it if the conditions for it to be notified already exist.
Added commit: renamed _pool to _data as suggested. |
The following links are available: build (macOS-latest, full) build (ubuntu-18.04, full)
build (windows-latest, full) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me, definitely want to stress test this with a bunch of people on a server and do another perf analysis to see if this made a difference
… as expected and verify the invariants
I managed to piece together a linux debugging environment and debugged it enough to no longer assert (note to self: deleting assert commands is a great way to remove those pesky asserts). Anyhow, really hoping this is the last patch necessary in order to successfully smoketest this. Also hoping to have a chance to flatten these test commits (there's an awful lot of them) although I understand if that doesn't happen. |
The following links are available: build (macOS-10.15, full) build (ubuntu-18.04, full)
build (windows-latest, full) build (self-hosted_debian-11_aarch64, full)
|
I just gave it a try, and nothing is crashing right now, I'm able to connect, but only audio mixer starts. Other types of assignment clients don't start. |
I'm sorry. I ran assignment server with wrong command line parameters. Everything seems to work correctly now, but CPU usage is still very high even when no client is connected. |
Heh, finally got it! So I guess the question is what the profiler is saying about this now. |
Congratulations! |
CPU use seems to be significantly lower now compared to master when built with the same compiler flags - it drops almost 2 times when no user is logged in.
And for avatar mixer:
|
Audio mixer uses about 32% of a core right now when no one is logged in, and avatar mixer uses about 15% with compiler flags as in PR 1424. I suggest pulling changes from master to make comparisons easier. |
The weird thing is that high CPU usage disappears completely on PR 1429. I have no idea why. |
We tested it with Kalila and PR 1429 indeed seems to solve high CPU usage completely. It dropped to 3% for audio mixer and 3% for avatar mixer when nobody is logged in. |
Okay kewl! I'm gonna want to flatten all those commits I made while testing this (because ew), but other than that it sounds like we've cleared the "at least as good as master" bar. |
Okay I looked at the history and... it may not be as bad as I thought it was. I'll squish it if it makes sense to others, otherwise I'll say this is good to merge. |
sorry if I’m missing it in the above comments: did this PR have a measurable difference then? if this isn’t an improvement, maybe we don’t need to merge it? |
With current version it does have a measurable improvement, but I suggest to wait with testing it until PR 1429 is merged. I will benchmark it again then and see if it also improves things or not. |
The following links are available: build (ubuntu-18.04, full)
build (macOS-10.15, client) build (windows-latest, full) build (self-hosted_debian-11_aarch64, full)
|
The following links are available: build (ubuntu-18.04, full)
build (macOS-10.15, full) build (windows-latest, full) |
Needs another QA pass to confirm whether or not it performs better than current master. |
Hello! Is this still an issue? |
This is an optimization pass over the mutex logic in AudioMixerSlavePool and AvatarMixerSlavePool (which is effectively the same code).
This is a continuation of the changes in #1358 , with more of a focus on contracts and invariants and effectively no use of mutexes. This should (almost by definition) have reduced lock contention, but "thread-safety through the use of code comments" may have negative side effects. I don't know which of these PRs will end up being used (perhaps a mixture of both?)
Additional changes made to this PR:
Testing is almost identical to #1358 :