Optimize Windows contention performance #455
Closed
Conversation
This file contains 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
The dispatch_cascade test is very slow on Windows right now (often taking 4-5 minutes to execute on my machine and sometimes locking it up entirely) because contention is not being handled correctly. `_dispatch_contention_usleep()` is expected to put the thread to sleep, but on Windows it spins on `QueryPerformanceCounter()`. This is causing a huge amount of starvation in the dispatch_cascade test. Implement it using `Sleep()`, and accordingly adjust `DISPATCH_CONTENTION_USLEEP_START` to be 1ms on Windows. Additionally, `_dispatch_contention_spins()` is currently implemented using the `rand_s()` function. This is slow (and experimentally seems to be slower than not randomizing the spin count at all!) because `rand_s()` guarantees cryptographic security, which is unnecessary for dispatch's use case. Replace it with a basic linear congruential generator (from K&R) since there isn't any other `rand_r()` equivalent. Based on the average wall clock times reported by bsdtestharness, this is around 35% faster on my PC (i7-8700K). These changes bring the runtime of the dispatch_cascade test down to around 1-2s at most for me. (It's even faster than this if stdout isn't a console window because that slows down the histogram display.)
|
Yeah, the problem is that the duration of Sleep is not precise enough to do the microsleep :-( |
|
@swift-ci please test |
7 similar comments
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test |
|
Closing because this is included in #453. |
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.
The dispatch_cascade test is very slow on Windows right now (often taking 4-5
minutes to execute on my machine and sometimes locking it up entirely) because
contention is not being handled correctly.
_dispatch_contention_usleep()is expected to put the thread to sleep, but onWindows it spins on
QueryPerformanceCounter(). This is causing a huge amountof starvation in the dispatch_cascade test. Implement it using
Sleep(), andaccordingly adjust
DISPATCH_CONTENTION_USLEEP_STARTto be 1ms on Windows.Additionally,
_dispatch_contention_spins()is currently implemented using therand_s()function. This is slow (and experimentally seems to be slower thannot randomizing the spin count at all!) because
rand_s()guaranteescryptographic security, which is unnecessary for dispatch's use case. Replace it
with a basic linear congruential generator (from K&R) since there isn't any
other
rand_r()equivalent. Based on the average wall clock times reported bybsdtestharness, this is around 35% faster on my PC (i7-8700K).
These changes bring the runtime of the dispatch_cascade test down to around 1-2s
at most for me. (It's even faster than this if stdout isn't a console window
because that slows down the histogram display.)