Prometheus: scalable and accurate emulation of task-based applications on many-core systems

Kestor, Gokcen; Gioiosa, Roberto; Chavarŕıa-Miranda, Daniel

doi:10.1109/ispass.2015.7095816

Cited by 8 publications

(12 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our task replay engine shares some similarities with Prometheus [24] and TaskSim [30]. Both tools enable the accurate simulation of task-based codes by either, in the case of Prometheus, constructing a TDG and simulating hardware contention, or, in the case of TaskSim, gathering execution traces.…”

Section: Related Workmentioning

confidence: 99%

Isoefficiency in Practice

et al. 2017

View full text Add to dashboard Cite

Task-based programming offers an elegant way to express units of computation and the dependencies among them, making it easier to distribute the computational load evenly across multiple cores. However, this separation of problem decomposition and parallelism requires a sufficiently large input problem to achieve satisfactory efficiency on a given number of cores. Unfortunately, finding a good match between input size and core count usually requires significant experimentation, which is expensive and sometimes even impractical. In this paper, we propose an automated empirical method for finding the isoefficiency function of a taskbased program, binding efficiency, core count, and the input size in one analytical expression. This allows the latter two to be adjusted according to given (realistic) efficiency objectives. Moreover, we not only find (i) the actual isoefficiency function but also (ii) the function one would yield if the program execution was free of resource contention and (iii) an upper bound that could only be reached if the program was able to maintain its average parallelism throughout its execution. The difference between the three helps to explain low efficiency, and in particular, it helps to differentiate between resource contention and structural conflicts related to task dependencies or scheduling. The insights gained can be used to co-design programs and shared system resources.

show abstract

Section: Related Workmentioning

confidence: 99%

Isoefficiency in Practice

et al. 2017

View full text Add to dashboard Cite

show abstract

“…By assigning more work to leaf tasks, the implementation in Figure 2b needs fewer tasks to perform fib (4) fib (3) fib (2) fib (1) fib (0) fib (1) fib (1) fib (0) fib ( (4) fib (3) fib (2) fib (2) fib ( the same computation. We observe that the inner tasks in Figure 3a, enclosed in the red dashed-boxes, are aggregated into larger tasks in Figure 3b.…”

Section: A Motivational Examplementioning

confidence: 99%

“…Rather than performing the task aggregation on the application code, which is time-consuming and impractical, we first extract the application DAG from the application execution. This operation is input-dependent, but it is performed automatically by a tracing tool [4] that intercepts the programming model keywords and generates an annotated DAG. Each spawned task, continuation task and sync task map into a DAG node and it is annotated with the execution time measured by the tracing tool.…”

Section: B Redefining Task Size Of Existing Applicationsmentioning

confidence: 99%

“…Each spawned task, continuation task and sync task map into a DAG node and it is annotated with the execution time measured by the tracing tool. As reported in [4], the tracing tool overhead is minimal and it is generally enough to fix the input and trace the application once, similarly to profiling benchmarks with representative inputs provided with other benchmark suites. Figure 4 shows the algorithm steps performed to aggregate leaf tasks into larger computation tasks.…”

Section: B Redefining Task Size Of Existing Applicationsmentioning

confidence: 99%

“…Our aggregation algorithm maintains the correct semantics and parallelization strategy of an application and produces DAGs that are equivalent to those produced by an application explicitly programmed with coarser-grained tasks. 2) We use Prometheus [4], a system emulator for task-based application to analyze the implications of larger task granularities and the impact of scheduling overheads on systems with up to 1,024 cores. 3) We present a comprehensive and systematic sensitivity study of varying application task granularity and runtime scheduler overheads.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

On the Application Task Granularity and the Interplay with the Scheduling Overhead in Many-Core Shared Memory Systems

Akhmetova

Kestor

Gioiosa

et al. 2015

2015 IEEE International Conference on Cluster Computing

Self Cite

View full text Add to dashboard Cite

Task-based programming models are considered one of the most promising programming model approaches for exascale supercomputers because of their ability to dynamically react to changing conditions and reassign work to processing elements. One question, however, remains unsolved: what should the task granularity of task-based applications be? Finegrained tasks offer more opportunities to balance the system and generally result in higher system utilization. However, they also induce in large scheduling overhead. The impact of scheduling overhead on coarse-grained tasks is lower, but large systems may result imbalanced and underutilized.In this work we propose a methodology to analyze the interplay between application task granularity and scheduling overhead. Our methodology is based on three main points: 1) a novel task algorithm that analyzes an application directed acyclic graph (DAG) and aggregates tasks; 2) a fast and precise emulator to analyze the application behavior on systems with up to 1,024 cores; 3) a comprehensive sensitivity analysis of application performance and scheduling overhead breakdown. Our results show that there is an optimal task granularity between 1.2x10 4 and 10x10 4 cycles for the representative schedulers. Moreover, our analysis indicates that a suitable scheduler for exascale task-based applications should employ a best-effort local scheduler and a sophisticated remote scheduler to move tasks across worker threads.

show abstract