-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Concurrency] Fix task switch performance issue. #83327
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
Conversation
@swift-ci Please smoke test |
@swift-ci Please test |
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.
Thanks for the description what this change achieves, that does make sense.
I'm wondering if we could write some tests for just the C function mustSwitchToRun
since we could have this nicely covered when we're expected to switch... but now it's a bit untested and could regress easily 🤔
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.
How about we add an unit test in unittests
, similar to how unittests/Threading/
tests are set up and check for a bunch of serial/task executors passed to this func? This way we won't accidentally regress functionality here
When using the new custom default executors, sometimes we end up taking a long time to do a task switch. This is happening because the path the new code takes sometimes results in a concrete pointer to the default global executor being in the executor tracking information in `swift_task_switch()`, and if we try to switch to a `nil` task executor (which _also_ means the default global executor), we aren’t spotting that and we’re taking the slow path. Essentially, we want to take the fast path in cases where we switch from `nil` to the concrete default global executor and vice-versa. rdar://156701386
48a1165
to
395e405
Compare
@swift-ci Please smoke test |
@swift-ci please build toolchain Ubuntu 24.04 |
I just tested this branch locally and it produces the expected performance wins. A custom default executor is now capable of achieving nearly the identical performance of the built-in dispatch global executor. |
(Cherry picked #83391 here so we can test this). |
@swift-ci Please smoke test |
…ances If the conformance is abstract the witness table is specialized elsewhere - at the place where the concrete conformance is referenced. Fixes a compiler crash.
Remove some reference counting traffic by using `Unowned*Executor`s. Also, add a test to make sure we stay on the fast path. rdar://156701386
The test uses Dispatch, mainly for convenience, but that means it won't run everywhere. rdar://156701386
… link. We need to link `swift_getDefaultExecutor`, which is used from the C++ code. rdar://156701386
f07a094
to
85bb057
Compare
@swift-ci Please smoke test |
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.
Thanks for adding a test, looks good!
When using the new custom default executors, sometimes we end up taking a long time to do a task switch. This is happening because the path the new code takes sometimes results in a concrete pointer to the default global executor being in the executor tracking information in
swift_task_switch()
, and if we try to switch to anil
task executor (which also means the default global executor), we aren’t spotting that and we’re taking the slow path.Essentially, we want to take the fast path in cases where we switch from
nil
to the concrete default global executor and vice-versa.rdar://156701386