The EDGE Language: Extended General Einsums for Graph Algorithms

TL;DR

EDGE (Extended General Einsums) introduces a unified tensor-algebra notation to express graph algorithms, enabling a declarative description of computations and a separation of concerns between what to compute and how to compute it. By extending Einsums with Map, Reduce, and Populate actions, rank-variable expressions, and a cascade/iteration mechanism, EDGE generalizes graph processing beyond traditional semirings and graph-linear algebra approaches. The framework provides formal data- and iteration-space semantics, plus an execution model that allows algebraic manipulations to derive algorithmic variants (e.g., BFS, SSSP, connected components) and accelerates exploration of mapping/format/architecture backends. This design aims to facilitate precise comparisons, portable implementations, and automated discovery of new graph algorithms through algebraic transformations, with potential applicability beyond graphs to broader tensor-algebra workloads.

Abstract

In this work, we propose a unified abstraction for graph algorithms: the Extended General Einsums language, or EDGE. The EDGE language expresses graph algorithms in the language of tensor algebra, providing a rigorous, succinct, and expressive mathematical framework. EDGE leverages two ideas: (1) the well-known foundations provided by the graph-matrix duality, where a graph is simply a 2D tensor, and (2) the power and expressivity of Einsum notation in the tensor algebra world. In this work, we describe our design goals for EDGE and walk through the extensions we add to Einsums to support more complex operations common in graph algorithms. Additionally, we provide a few examples of how to express graph algorithms in our proposed notation. We hope that a single, mathematical notation for graph algorithms will (1) allow researchers to more easily compare different algorithms and different implementations of a graph algorithm; (2) enable developers to factor complexity by separating the concerns of what to compute (described with the extended Einsum notation) from the lower level details of how to compute; and (3) enable the discovery of different algorithmic variants of a problem through algebraic manipulations and transformations on a given EDGE expression.

Figures (15)

• Figure 1: Uncompressed 2D tensors, $A$ and $B$, where locations containing zero are empty. This also shows the tensor data spaces of $A$ and $B$, which are the set of data values at each coordinate of each tensor.
• Figure 2: Fibertree representations of the uncompressed tensors in Figure \ref{['fig:uncompressed']}.
• Figure 3: A directed graph, $G$, and some representations. The matrix values contain the edge ID, while the vertices are labelled alphabetically.
• Figure 4: The example graph in Figure \ref{['fig:exgraph']} as two different fibertrees.
• Figure 5: Our view of the complex design space in tensor algebra. Shaded boxes indicate processes (searching the space), white/black boxes indicate inputs/outputs to the system. Given a problem, a tensor algebra implementation must try to optimize across the possible data formats, possible algebraic variants of the computation, and the mapping space, as well as selecting the best architecture. Tools tend to either model performance (for domain-specific accelerators), or generate platform-specific code. The results may be used to search for better points in the implementation space.