Can High Throughput Atone for High Latency in Compiler-Generated Protocol Code?

Abstract

Abstract. High-level concurrency constructs and abstractions have several well-known software engineering advantages when it comes to programming concurrency protocols among threads in multicore applications. To also explore their complementary performance advantages, in ongoing work, we are developing compilation technology for a high-level coordination language, Reo, based on this language's formal automaton semantics. By now, as shown in our previous work, our tools are capable of generating code that can compete with carefully hand-crafted code, at least for some protocols. An important prerequisite to further advance this promising technology, now, is to gain a better understanding of how the significantly different compilation approaches that we developed so far, which vary in the amount of parallelism in their generated code, compare against each other. For instance, to better and more reliably tune our compilers, we must learn under which circumstances parallel protocol code, with high throughput but also high latency, outperforms sequential protocol code, with low latency but also low throughput.In this paper, we report on an extensive performance comparison between these approaches for a substantial number of protocols, expressed in Reo. Because we have always formulated our compilation technology in terms of a general kind of communicating automaton (i.e., constraint automata), our findings apply not only to Reo but, in principle, to any language whose semantics can be defined in terms of such automata.

Partially distributed coordination with Reo and constraint automata

“…We report on these new experiments elsewhere [33]. An important difference between our new experiments and the experiments reported in this paper is that we statically fixed the clock frequency in our new experiments, thereby effectively disabling Turbo Boost.…”

Composing Constraint Automata, State-by-State

“…Recently, we reported on a number of experiments with our ca-based Reoto-Java compiler [11]. In these experiments, we indeed observed exponential resource consumption for computing exponentially-sized grand compositions.…”

“…Based on earlier preliminary observations [11], we present a careful analysis of the previously stated problem. Essentially, as we shortly explain in more detail, our existing approach for computing grand compositions sometimes involves the computation of exponentially many "intermediatelyreachable-but-finally-unreachable" states in "intermediate compounds", which become unreachable only in the "final compound".…”

“…As such, cas constitute a compositional formal semantics of Reo. Both verification and compilation tools for Reo leverage this compositionality (e.g., [3,4,10,11,13]); the combination of such tools facilitates a correctness-by-construction approach to component-based software-engineering-one of the hallmarks in Sifakis' rigorous system design.…”

Coordinating Multicore Computing

“…This single thread executes a big state machine, free of other threads to synchronize its behavior with. -g hi 2 -Improving throughput [45,47,48,51] Although g hi 1 reduces firing latency, it does so at the cost of reduced firing throughput: by computing one big automaton out of multiple small automata, g hi 1 effectively serializes all parallelism among those small automata. If those small automata have heavy synchronization interdependencies, this is desirable, but if the small automata are more "loosely coupled", such sequentialization may unnecessarily reduce throughput.…”