Phoebe/parallelism test/rayon par iter only #2552
Draft
Conversation
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
For testing/benchmarking purposes. One theory about our performance is that we're spending a lot of time context-switching between Tokio and Rayon threads. This build will be used in the first of a series of experiments to investigate that overhead. In this patch, we just do sequential evaluation on the Tokio worker threads where the rest of our code runs, instead of sending stuff to Rayon. Rayon use is mostly, but not entirely, removed from Core. The two next steps I am interested in: - Use parallelism, but on Tokio workers rather than Rayon threads. I.e. replace `par_iter`, `fold` and `reduce_with` calls with Tokio-isms, instead of this patch's `std::iter::Iterator` versions. - (Not discussed in meeting) continue using `par_iter` and friends, but invoke the "outer loop" from Tokio threads. I.e. retain use of `par_iter`, `fold` and `reduce_with`, but remove calls to `rayon::scope` or `rayon::spawn`.
…test/sequential-eval-incr
This experiment is intended to test the theory that our synchronization overhead is coming from moving work off the "main thread" to Rayon workers via `scope` and `spawn`, not from `par_iter` parallel iteration. If that is the case, we should see synchronization overhead (i.e. `futex_wait` time) decreased similar to the previous experiment relavite to the control, but also see improved CPU utilization across multiple cores.
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.
For testing/benchmarking purposes. Follow-up to #2543 .
This experiment is intended to test the theory that our synchronization overhead is coming from moving work off the "main thread" to Rayon workers via
scopeandspawn, not frompar_iterparallel iteration. If that is the case, we should see synchronization overhead (i.e.futex_waittime) decreased similar to the previous experiment relavite to the control, but also see improved CPU utilization across multiple cores.