IMSuite: A benchmark suite for simulating distributed algorithms

Abstract

Considering the diverse nature of real-world distributed applications that makes it hard to identify a representative subset of distributed benchmarks, we focus on their underlying distributed algorithms. We present and characterize a new kernel benchmark suite (named IMSuite) that simulates some of the classical distributed algorithms in task parallel languages. We present multiple variations of our kernels, broadly categorized under two heads: (a) varying synchronization primitives (with and without fine grain synchronization primitives); and (b) varying forms of parallelization (data parallel and recursive task parallel). Our characterization covers interesting aspects of distributed applications such as distribution of remote communication requests, number of synchronization, task creation, task termination and atomic operations. We study the behavior (execution time) of our kernels by varying the problem size, the number of compute threads, and the input configurations. We also present an involved set of input generators and output validators.

Efficient lock‐step synchronization in task‐parallel languages

“…We performed the evaluation using the iterative kernels of IMSuite . These kernels (listed in Figure ) encode some of the popular distributed algorithms in use, ie, breadth first search (Bellman and Ford (BF) and Dijkstra (DST)), committee creation, leader election (David Peleg (DP), Hirschberg and Sinclair (HS), and Lann, Chang and Roberts (LCR)), maximal independent set, minimum spanning tree, Byzantine consensus (BY), dominating set, and vertex coloring.…”

“…As a consequence of the overheads discussed above, many times, we have found that programs written using Clock‐async‐finish (though arguably more readable) have a prohibitively high performance penalty as compared to their counterparts written using only async‐finish constructs. For example, compared to four kernels from the IMSuite benchmarks that use a significant number of atomic and clock‐operations, their async‐finish counterparts run on average (geometric mean) 16.46× faster on a 16‐core Intel machine (See Figure A). A similar observation can be made in the context of the IMSuite kernels and HJ phasers (similar to X10 clocks).…”

“…For example, compared to four kernels from the IMSuite benchmarks that use a significant number of atomic and clock‐operations, their async‐finish counterparts run on average (geometric mean) 16.46× faster on a 16‐core Intel machine (See Figure A). A similar observation can be made in the context of the IMSuite kernels and HJ phasers (similar to X10 clocks). As shown in Figure B, the same four HJ kernels written with phasers ran on average (geometric mean) 4.25× slower than their async‐finish counterparts on the same 16‐core Intel system.…”

Habanero-Java library

“…In addition to micro-benchmarks for async-finish style programs, it also include benchmarks for phasers, futures, DDFs, and actors. Some Java programs (Java Grande Forum [17], Shootout [1]) and benchmark suites (IMSuite [22], STAMP [10]) have also been ported to HJlib. Applications such as LULESH [26] and some of PBBS [39] applications have also been ported to HJlib from their native implementations.…”

Untitled

“…We explain the same using a motivating example. Figure 1(a) shows a code snippet in X10 of the MST (builds a minimum spanning tree) kernel from IMSuite [14]; the setChildSignal function checks if any child can start processing in parallel. A child ready to start processing would have already set its corresponding element in the distributed Boolean array this.setCheck.…”