Skip to content
Snippets Groups Projects
Select Git revision
  • hpvm-release-epochs
  • main default
  • hpvm-release-epochs0
  • v2.0
  • v2.0rc
  • v1.0
  • v0.5
7 results
Blame Permalink
hpvm-specification.md 17.23 KiB

Table of Contents

HPVM Abstraction

An HPVM program is a combination of host code plus a set of one or more distinct dataflow graphs. Each dataflow graph (DFG) is a hierarchical graph with side effects. The DFG must be acyclic. Nodes represent units of execution, and edges between nodes describe the explicit data transfer requirements. A node can begin execution once a data item becomes available on every one of its input edges. Repeated transfer of data items between nodes (if more inputs are provided) yields a pipelined execution of different nodes in the graph. The execution of a DFG is initiated and terminated by host code that launches the graph. Nodes may access globally shared memory through load and store instructions (side-effects).

Dataflow Node

A dataflow node represents unit of computation in the DFG. A node can begin execution once a data item becomes available on every one of its input edges.

A single static dataflow node represents multiple dynamic instances of the node, each executing the same computation with different index values used to uniquely identify each dynamic instance w.r.t. the others. The dynamic instances of a node may be executed concurrently, and any required synchronization must imposed using HPVM synchronization operations.

Each dataflow node in a DFG can either be a leaf node or an internal node. An internal node contains a complete DFG, called a child graph, and the child graph itself can have internal nodes and/or leaf nodes.

Internal nodes only create the structure of the child graph, and cannot include actual computation.

Leaf nodes contain code expressing actual computations. Leaf nodes may contain instructions to query the structure of the underlying DFG, and any non host side HPVM operation for synchronization and memory allocation.

Note that the graph is fully interpreted at compile-time and cannot be modified at runtime except for the number of dynamic instances, which can be data dependent.

Dataflow Edge

A dataflow edge from the output out of a source dataflow node Src to the input in of a sink dataflow node Dst describes the explicit data transfer requirements. Src and Dst node must belong to the same child graph, i.e. must be children of the same internal node.

An edge from source to sink has the semantics of copying the specified data from the source to the sink after the source node has completed execution. The pairs (Src, out) and (Dst, in), representing source and sink respectively, must be unique w.r.t. every other edge in the same child graph, i.e. two dataflow edges in the same child graph cannot have the same source or destination.

A static edge also represents multiple dynamic instances of that edge between the dynamic instances of the source and the sink nodes.

An edge can be instantiated at runtime using one of two replication mechanisms:

  • All-to-all, where all dynamic instances of the source node are connected to all dynamic instances of the sink node, thus expressing a synchronization barrier between the two groups of nodes, or
  • One-to-one, where each dynamic instance of the source node is connected to a single corresponding instance of the sink node. One-to-one replication requires that the grid structure (number of dimensions and the extents in each dimension) of the source and sink nodes be identical.