[OpenMP] New taskgraph runtime implementation - #194047
Conversation
Created using spr 1.3.5
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
Created using spr 1.3.5
Created using spr 1.3.5
|
Is there any way that I can jump between PRs in this stack? |
|
#188765 has a list of the first few (they're consecutive), but other than that, not sure! Perhaps that's a drawback of SPR? |
|
You might want to consider adding such a list in the description of each PR; otherwise IMHO it is hard to track the order and understand what is going on here. |
|
Stack as of now: |
Created using spr 1.3.5
|
FYI: this one looks like it needs some changes -- the irreducible-graph handling code is likely to radically change. So don't put too much review effort into that part just yet. Thanks! |
This patch contains the bulk of the new runtime support for taskgraph record/replay. Key points are as follows. The task/taskdata structures and the dependencies between them are duplicated whilst recording a taskgraph, keeping the existing runtime dependency handling unaffected by the taskgraph implementation -- e.g. during runtime execution, it is valid for output dependencies can be dropped as soon as the producing task completes. This separation is intended to eliminate a class of race conditions, where tasks which complete unpredictably might or might not be marked as having a subsequent task depending on them. The dependencies between tasks in a taskgraph are processed by static analysis: the high-level process is akin to turning data dependencies between tasks into control-flow dependencies. This is done by building a set of successors and predecessors for each recorded task, then decomposing the resulting DAG into parallel and sequential regions. In the (presumed relatively unlikely, in real-world code) case that the graph is irreducible, a further set of analyses and transformations is done, and the parallel-sequential decomposition is run again. The output of this process is a set of nested kmp_taskgraph_region structures -- parallel or sequential (with some number of children), or nodes representing a single task. The two phases alternate until we obtain a single, top-level region. Replaying a taskgraph processed in this way on the CPU involves another set of linked structures, of type kmp_taskgraph_exec_descr. These form a kind of trace of a traversal over the kmp_taskgraph_region structure, so that a pointer to a kmp_taskgraph_exec_descr is somewhat equivalent to a "program counter". Recorded taskgraphs are located directly by using a handle passed in from the user's compiled program, rather than using a linked list or hashtable to find taskgraph records to replay keyed by an index. commit-id:47e383a2 Pull Request: #194047
|
The stacked-PR tool I'm using for this stack did something weird: this one is #216324 now. |
3 participants
This patch contains the bulk of the new runtime support for taskgraph
record/replay.
Key points are as follows.
The task/taskdata structures and the dependencies between them are
duplicated whilst recording a taskgraph, keeping the existing runtime
dependency handling unaffected by the taskgraph implementation --
e.g. during runtime execution, it is valid for output dependencies can
be dropped as soon as the producing task completes. This separation
is intended to eliminate a class of race conditions, where tasks which
complete unpredictably might or might not be marked as having a subsequent
task depending on them.
The dependencies between tasks in a taskgraph are processed by static
analysis: the high-level process is akin to turning data dependencies
between tasks into control-flow dependencies. This is done by building
a set of successors and predecessors for each recorded task, then
decomposing the resulting DAG into parallel and sequential regions. In the
(presumed relatively unlikely, in real-world code) case that the graph
is irreducible, a further set of analyses and transformations is done,
and the parallel-sequential decomposition is run again.
The output of this process is a set of nested kmp_taskgraph_region
structures -- parallel or sequential (with some number of children),
or nodes representing a single task. The two phases alternate until we
obtain a single, top-level region.
Replaying a taskgraph processed in this way on the CPU involves another
set of linked structures, of type kmp_taskgraph_exec_descr. These form
a kind of trace of a traversal over the kmp_taskgraph_region structure,
so that a pointer to a kmp_taskgraph_exec_descr is somewhat equivalent
to a "program counter".
Recorded taskgraphs are located directly by using a handle passed in
from the user's compiled program, rather than using a linked list or
hashtable to find taskgraph records to replay keyed by an index.
commit-id:47e383a2