Toward a more accurate understanding of the limits of the TLS execution paradigm

Ioannou, Nikolas; Singer, Jeremy; Khan, Salman; Xekalakis, Polychronis; Yiapanis, Paraskevas; Pocock, Adam; Brown, Gavin; Luján, Mikel; Watson, Ian; Cintra, Marcelo

doi:10.1109/iiswc.2010.5649169

Cited by 11 publications

(11 citation statements)

References 34 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Such dependences prevent parallel execution and would trigger a rollback and sequential execution of the given iterations. Limit studies on TLS [23] have shown that rollback events must be rare in order to obtain a speed-up from speculative parallel execution.…”

Section: F Frequency Of Sequential Iterationsmentioning

confidence: 99%

Variability of data dependences and control flow

Koch

Franke

2014

2014 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS)

View full text Add to dashboard Cite

Thread-level speculation and profile-guided parallelization techniques exploit the fact that many statically detected data and control flow dependences do not manifest themselves in every possible program execution. Instead, many of these maydependences only occur infrequently, e.g. for some corner cases, or not at all for any legal program input. While the effectiveness of dynamic parallelization techniques critically depends on the absence of such dependences, not much is known about their nature. In this paper, we present an empirical analysis and characterization of the variability of both data dependences and control flow across program runs. We run the CBENCH benchmark suite with 100 randomly chosen input data sets and record complete control and data flow traces. Based on these traces, we build a whole-program control and data flow graph (CDFG) for each run and compare the resulting graphs to obtain a measure of the variance in the observed control and data flow. We show that, on average, the cumulative profile information gathered with at least 55, and up to 100, different input data sets is needed to achieve full coverage of the data flow observed across all runs. For control flow, the figure stands at 46 and 100 data sets, respectively. This suggests that profile-guided parallelization needs to be applied with utmost care, as misclassification of sequential loops as parallel was observed even when up to 94 input data sets are used.

show abstract

Section: F Frequency Of Sequential Iterationsmentioning

confidence: 99%

Variability of data dependences and control flow

Koch

Franke

2014

2014 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS)

View full text Add to dashboard Cite

show abstract

“…For LeeRouter, the mainboard input dataset was used. Most of these applications are also used in previous TLS studies [Quiñones et al 2005;Oancea et al 2009;Tian et al 2010;Ioannou et al 2010].…”

Section: Evaluation Methodologymentioning

confidence: 95%

“…This solution represents a more compact way of memory representation compared to other solutions in the literature. We choose to experiment with only up to 32 threads and not more, motivated by the results in previous TLS limit studies (such as Ioannou et al [2010]) which indicate there is no significant benefit with higher number of threads. Of course this solution can be easily extended to support more threads.…”

Section: Data Structuresmentioning

confidence: 99%

“…However, no widely available architectures or compilers have incorporated TLS. Nonetheless, the published limit studies suggest that it could be profitable to use TLS Ioannou et al 2010], although we should focus on optimizing for small number of threads. Motivated by this potential, we have conducted experiments to verify whether this applies in a real machine, besides limit studies.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Optimizing software runtime systems for speculative parallelization

Yiapanis

Rosas-Ham

Brown

et al. 2013

ACM Trans. Archit. Code Optim.

Self Cite

View full text Add to dashboard Cite

Thread-Level Speculation (TLS) overcomes limitations intrinsic with conservative compile-time autoparallelizing tools by extracting parallel threads optimistically and only ensuring absence of data dependence violations at runtime. A significant barrier for adopting TLS (implemented in software) is the overheads associated with maintaining speculative state. Based on previous TLS limit studies, we observe that on future multicore systems we will likely have more cores idle than those which traditional TLS would be able to harness. This implies that a TLS system should focus on optimizing for small number of cores and find efficient ways to take advantage of the idle cores. Furthermore, research on optimistic systems has covered two important implementation design points: eager vs. lazy version management. With this knowledge, we propose new simple and effective techniques to reduce the execution time overheads for both of these design points.This article describes a novel compact version management data structure optimized for space overhead when using a small number of TLS threads. Furthermore, we describe two novel software runtime parallelization systems that utilize this compact data structure. The first software TLS system, MiniTLS, relies on eager memory data management (in-place updates) and, thus, when a misspeculation occurs a rollback process is required. MiniTLS takes advantage of the novel compact version management representation to parallelize the rollback process and is able to recover from misspeculation faster than existing software eager TLS systems.The second one, Lector (Lazy inspECTOR) is based on lazy version management. Since we have idle cores, the question is whether we can create "helper" tasks to determine whether speculation is actually needed without stopping or damaging the speculative execution. In Lector, for each conventional TLS thread running speculatively with lazy version management, there is associated with it a lightweight inspector. The inspector threads execute alongside to verify quickly whether data dependencies will occur. Inspector threads are generated by standard techniques for inspector/executor parallelization.We have applied both TLS systems to seven Java sequential benchmarks, including three benchmarks from SPECjvm2008. Two out of the seven benchmarks exhibit misspeculations. MiniTLS experiments report average speedups of 1.8x for 4 threads increasing close to 7x speedups with 32 threads. Facilitated by our novel compact representation, MiniTLS reduces the space overhead over state-of-the-art software TLS systems between 96% on 2 threads and 40% on 32 threads. The experiments for Lector, report average speedups of 1.7x for 2 threads (that is 1 TLS + 1 Inspector threads) increasing close to 8.2x speedups with 32 threads (16+16 threads). Compared to a well established software TLS baseline, Lector performs on average 1.7x faster for 32 threads and in no case (x TLS +x Inspector threads) Lector delivers worse performance than the baseline TLS with the equivalent nu...

show abstract

“…Its limits are evaluated in [13]. The Multiscalar architecture [22] represents an early implementation.…”

Section: Related Workmentioning

confidence: 99%

Limits of region-based dynamic binary parallelization

Koch

Franke

2013

SIGPLAN Not.

View full text Add to dashboard Cite

Efficiently executing sequential legacy binaries on chip multiprocessors (CMPs) composed of many, small cores is one of today's most pressing problems. Single-threaded execution is a suboptimal option due to CMPs' lower single-core performance, while multithreaded execution relies on prior parallelization, which is severely hampered by the low-level binary representation of applications compiled and optimized for a single-core target. A recent technology to address this problem is Dynamic Binary Parallelization (DBP), which creates a Virtual Execution Environment (VEE) taking advantage of the underlying multicore host to transparently parallelize the sequential binary executable. While still in its infancy, DBP has received broad interest within the research community. The combined use of DBP and thread-level speculation (TLS) has been proposed as a technique to accelerate legacy uniprocessor code on modern CMPs. In this paper, we investigate the limits of DBP and seek to gain an understanding of the factors contributing to these limits and the costs and overheads of its implementation. We have performed an extensive evaluation using a parameterizable DBP system targeting a CMP with light-weight architectural TLS support. We demonstrate that there is room for a significant reduction of up to 54% in the number of instructions on the critical paths of legacy SPEC CPU2006 benchmarks. However, we show that it is much harder to translate these savings into actual performance improvements, with a realistic hardware-supported implementation achieving a speedup of 1.09 on average.

show abstract

Toward a more accurate understanding of the limits of the TLS execution paradigm

Cited by 11 publications

References 34 publications

Variability of data dependences and control flow

Variability of data dependences and control flow

Optimizing software runtime systems for speculative parallelization

Limits of region-based dynamic binary parallelization

Contact Info

Product

Resources

About