[benchmark] Yield when time slice expires #19011
Conversation
Marking `Timer` and `SampleRunner` classes as `final` to make sure their methods use static dispatch.
It pays off of to be a nice process and yield the processor at regular intervals, to prevent having measured samples corrupted by preemptive multitasking. When the scheduled time slice (10ms on Mac OS) is probably about to expire during the next measurement, we voluntarily yield and resume the measurement within a fresh scheduler quantum. This cooperative approach to multitasking improves the sample quality and robustness of the measurement process.
palimondo
changed the title
|
Please review @eeckstein (@graydon ?) 🙏 |
|
Clever! Looks good to me. |
|
I'm unsure if I should hide this behind option or possibly make the |
|
To illustrate the effect of this change on a contended machine, this is a before and after example: |
|
@swift-ci smoke benchmark |
|
@swift-ci smoke test |
Build comment file:Build failed before running benchmark. |
|
@swift-ci smoke test |
|
@swift-ci smoke benchmark |
|
@swift-ci benchmark |
Build comment file:Build failed before running benchmark. |
1 similar comment
Build comment file:Build failed before running benchmark. |
|
@shahmishal Any idea why are these benchmark builds failing? |
|
This might be an issue on the master branch, not related to your changes. |
|
:-) I figured that much… I just thought there is some kind of a process for reverting a commit that breaks the build that would restore master to working order.… (in less than 6 hours since this started) Also it's a bit strange that smoke test passed and the issue is only with benchmark build... |
|
@swift-ci benchmark |
Build comment file:No performance and code size changesHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR. Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein). Hardware Overview |
It pays off of to be a nice process and yield the processor at regular intervals, to prevent having measured samples corrupted by preemptive multitasking.
When the scheduled time slice (10ms on Mac OS) is probably about to expire during the next measurement, we voluntarily yield and resume the measurement within a fresh scheduler quantum.
This cooperative approach to multitasking improves the sample quality and robustness of the measurement process.