-
Notifications
You must be signed in to change notification settings - Fork 18
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
Add experimental task hints API, support for 2D splits #227
Conversation
Check-perf-impact results: (3b34e58e3c100f4c3541a1ed59580f72) ❓ No new benchmark data submitted. ❓ |
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.
clang-tidy made some suggestions
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.
Great work! I have a few comments/questions.
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.
Nice! That is an impressive amount of testing. Some code, especially split_2d
internals, is rather hard to understand though.
Task hints are a means of providing the runtime with additional information on how to process a task, allowing users to incorporate their domain knowledge. Crucially, hints are non-binding, i.e., the runtime might decide to not honor a hint (e.g. if a heuristic indicates a better way).
I noticed that |
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 great!
Task hints are a means of providing the runtime with additional information on how to process a task, allowing users to incorporate their domain knowledge. Crucially, hints are non-binding, i.e., the runtime might decide to not honor a hint (e.g. if a heuristic indicates a better way).
This adds two new task hints, `split_1d` and `split_2d`, which influence the way tasks are split into chunks. The latter uses a new splitting function of the same name; all splitting related functionality is moved into a separate file and tests for both 1D and 2D splitting are included.
Check-perf-impact results: (4c65f1399a47e0eb1340f63004745b17) ❓ No new benchmark data submitted. ❓ |
This adds a new
experimental::hint
API that can be used to provide the runtime with additional information on how to process a task. The first two hints we have areexperimental::hints::split_1d
andexperimental::hints::split_2d
. As a 1D split is currently the default, the former is a no-op. For the latter this introduces a newsplit_2d
function that attempts to produce a number of evenly sized chunks while satisfying the provided granularity constraints.The algorithm works by trying to find two factors for
num_chunks
, the number of requested chunks, that are as close tosqrt(num_chunks)
as possible while also producing the requested number of chunks, degrading to a 1D split in the worst case. Due to granularity constraints it is not always possible to produce the requested number of chunks however, in that case the algorithm will attempt to get as close as possible. Finding the factors requires at mostO(sqrt(num_chunks))
time.Given the two factors, the algorithm uses two heuristics to decide to which side of the domain they should be assigned:
Here's a visual representation of some of the 2D splits from the unit tests. Each split is labelled in the form
<size0>x<size1> ~ <granularity0>x<granularity1> | <num chunks>
. Red lines represent split constraints (i.e., individual red boxes can not be split further):