Technical Perspective:: From Think Parallel to Think Sequential

Abstract

In recent years, the database and distributed systems communities have built a wide variety of runtime systems and programming models for largescale computing over graphs. Such “big graph processing systems” [1, 2, 4, 5, 7] o support highly scalable parallel execution of graph algorithms — e.g., computing shortest paths, graph centrality, connected components, or perhaps even graph clusters. As described in the excellent survey by Yan et al [6], most big graph processing systems require the programmer to adopt a vertex-centric or block-centric programming model. For the former, code only “sees” the state at one vertex, receives messages from other vertices, and can send messages to other vertices. Under the latter, code manages a set of vertices within a subgraph (“block”) and can communicate with the code managing other blocks. In “From think Parallel to Think Sequential,” Fan and colleagues argue that vertexand blockcentric programming models are not natural for programmers trained to think sequentially. Instead, they argue that a more intuitive programming model can be developed out of several very simple primitives that can be composed to do incremental computation (as has also been studied in more general “big data” systems [4, 3]). The authors propose four elegant building blocks: (1) a partial evaluation function, (2) an incremental update handling function, (3) mechanisms for updating and sharing parameters in global fashion, and (4) an aggregate function for when multiple workers are updating the same parameter. They build the GRAPE GRAPh Engine system, which implements this programming model, and they show that it provides excellent performance for a variety of graph algorithms. The paper presents a compelling case that, at least for certain classes of algorithms, the simple primitives may be both more natural and more amenable to optimization than standard vertex-centric approaches.