Generation and quantitative evaluation of dataflow clusters

Abstract

Multithreadedor hybrid von Neumann/dataflow execution models have an advantage over the fine-grain dataflow model in that they significantly reduce the run time overhead incurred by matching.In thw paper, we look at two issues related to the evaluation of a coarse-grain dataflow model of execution.The first issue concerns the compilation into a coarsegrain code from a fine-grain one. In this study, the concept of coarse-grain code is captured by clusters which can be thought of se mini-dataflow graphs which execute strictly, deterministically and without blocking.We look at two bottom-up algorithms: the basic block and the dependence sets methods, to partition dataflow graphs into clusters. The second issue is the actual performance of the clusterbaaed execution se several architecture parameters are varied (e.g. number of processors, matching cost, network latency, etc.). From the extensive simulation data we evaluate (1) the potential speedup over the fine-grain execution and (2) the effects of the various architecture parameters on the coarse-grain execution time, allowing us to draw conclusions on their effectiveness.The results indicate that even with a simple bottom-up algorithm for generating clusters, cluster execution offers a good speedup over the fine-grain execution over a wide range of architectures.They also indicate that coarse-grain execution is scalable, tolerates network latency and high matching cost well; it can benefit from a higher output bandwidth of a processor and finally, a simple superscalar processor with the issue rate of two is sufficient to exploit the internal parallelism of a cluster.

P2G: A Framework for Distributed Real-Time Processing of Multimedia Data

“…It has also been considered by Roh et al [32], where they have performed simulations on parallel scheduling decisions for instruction sets of a functional language. Simple workloads are mapped to various simulated architectures, using a "mergeup" algorithm, which is equivalent to our LLS, and "mergedown" algorithm, which is equivalent to our HLS.…”

Resource Management in Dataflow-Based Multithreaded Execution

“…The thread size, however, is limited by the last two objectives. In fact, it was reported in [15] that blind efforts to increase the thread size, even when they satisfy the nonblocking and parallelism objectives, can result in a decrease in overall performance. Larger threads tend to have larger numbers of inputs and can result in a larger input latency, defined as the time delay between the arrival of the first token to a thread instance and that of the last token, at which time the thread can start executing [16].…”

Generation, Optimization, and Evaluation of Multithreaded Code

“…Several projects use bottom-up, multithreaded code generation strategies based on dataflow graphs [16,32,13,37,27]. Most of these schemes generate sequential threads for programs written in Id [23], a nonstrict language.…”

“…Most of these schemes generate sequential threads for programs written in Id [23], a nonstrict language. The nonstrict semantics of Id requires a more careful partitioning strategy than what is required under the strict semantics of Sisal [18] to avoid deadlock [21,27].…”

“…Due to the third objective, a thread will typically be much smaller than a loop or function body, as memory reads must be turned into split-phase transactions. In addition, even when the nonblocking and parallelism objectives are satisfied, blind efforts to increase the thread size can result in a decrease in overall performance [27]. Larger threads tend to have a larger number of inputs which can result in a larger input latency.…”