Performance debugging shared memory multiprocessor programs with MTOOL

Goldberg, A. J.; Hennessy, John L.

doi:10.1145/125826.126075

Cited by 38 publications

(25 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Tools for shared-memory systems [3,24] tend to focus on an explicit threading (e.g., Pthreads, WinAPI threads, etc.). MPI and explicit-threading programs statically partition their work into threads and then map each thread to a core.…”

Section: Related Workmentioning

confidence: 99%

The Cilkview scalability analyzer

Leiserson

2010

Proceedings of the Twenty-Second Annual ACM Symposium on Parallelism in Algorithms and Architectures

View full text Add to dashboard Cite

The Cilkview scalability analyzer is a software tool for profiling, estimating scalability, and benchmarking multithreaded Cilk++ applications. Cilkview monitors logical parallelism during an instrumented execution of the Cilk++ application on a single processing core. As Cilkview executes, it analyzes logical dependencies within the computation to determine its work and span (criticalpath length). These metrics allow Cilkview to estimate parallelism and predict how the application will scale with the number of processing cores. In addition, Cilkview analyzes scheduling overhead using the concept of a "burdened dag," which allows it to diagnose performance problems in the application due to an insufficient grain size of parallel subcomputations.Cilkview employs the Pin dynamic-instrumentation framework to collect metrics during a serial execution of the application code. It operates directly on the optimized code rather than on a debug version. Metadata embedded by the Cilk++ compiler in the binary executable identifies the parallel control constructs in the executing application. This approach introduces little or no overhead to the program binary in normal runs.Cilkview can perform real-time scalability benchmarking automatically, producing gnuplot-compatible output that allows developers to compare an application's performance with the tool's predictions. If the program performs beneath the range of expectation, the programmer can be confident in seeking a cause such as insufficient memory bandwidth, false sharing, or contention, rather than inadequate parallelism or insufficient grain size.

show abstract

Section: Related Workmentioning

confidence: 99%

The Cilkview scalability analyzer

Leiserson

2010

Proceedings of the Twenty-Second Annual ACM Symposium on Parallelism in Algorithms and Architectures

View full text Add to dashboard Cite

show abstract

“…However, tuning the memory behavior of large programs is a complex task requiring detailed information on the program's access patterns. Some performance monitoring systems (such as MTOOL [3,4]) give only code oriented information indicating the amount of memory overhead in particular loops or procedures. This information is useful for initial queries about application behavior; however, it is often not detailed enough to help the user fix the application's performance bottlenecks.…”

Section: In: Proc 1993 Acm Sigmetrics Conference On Measurement and mentioning

confidence: 99%

“…For the benchmarks studied here, this reduces MemSpy's overhead to a factor of 3 to 8. With execution time overheads in this range, MemSpy's performance becomes competitive with other tools [4] that present less detailed statistics.…”

Section: In: Proc 1993 Acm Sigmetrics Conference On Measurement and mentioning

confidence: 99%

“…First, the samples gathered may not be representative of the full trace. This error is common to all forms of sampling, including the program counter sampling already used in a number of performance monitoring systems [1,3,4,5]. This sort of error can generally be controlled by taking a number of samples over the course of the program's execution.…”

Section: Trace Sampling Backgroundmentioning

confidence: 99%

“…

AbstractRecently there has been a surge of interest in developing performance debugging tools to help programmers tune their applications for better memory performance [2,4,10]. These tools vary both in the detail of feedback provided to the user, and in the runtime overhead of using them.

…”

mentioning

confidence: 99%

See 2 more Smart Citations

Effectiveness of trace sampling for performance debugging tools

Martonosi

Gupta

Anderson

1993

SIGMETRICS Perform. Eval. Rev.

View full text Add to dashboard Cite

Recently there has been a surge of interest in developing performance debugging tools to help programmers tune their applications for better memory performance [2,4,10]. These tools vary both in the detail of feedback provided to the user, and in the runtime overhead of using them. MemSpy [10] is a simulation-based tool which gives programmers detailed statistics on the memory system behavior of applications. It provides information on the frequency and causes of cache misses, and presents it in terms of source-level data and code objects with which the programmer is familiar. However, using MemSpy increases a program's execution time by roughly 10 to 40 fold. This overhead is generally acceptable for applications with execution times of several minutes or less, but it can be inconvenient when tuning applications with very long execution times.This paper examines the use of trace sampling techniques to reduce the execution time overhead of tools like MemSpy. When simulating one tenth of the references, we find that MemSpy's execution time overhead is improved by a factor of 4 to 6. That is, the execution time when using MemSpy is generally within a factor of 3 to 8 times the normal execution time. With this improved performance, we observe only small errors in the performance statistics reported by MemSpy. On moderate sized caches of 16KB to 128KB, simulating as few as one tenth of the references (in samples of 0.5M references each) allows us to estimate the program's actual cache miss rate with an absolute error no greater than 0.3% on our five benchmarks. These errors are quite tolerable within the context of performance debugging. With larger caches we can also obtain good accuracy by using longer sample lengths. We conclude that, used with care, trace sampling is a powerful technique that makes possible performance debugging tools which provide both detailed memory statistics and low execution time overheads.

show abstract

Synthetic‐perturbation techniques for screening shared memory programs

et al. 1994

View full text Add to dashboard Cite

The synthetic‐perturbation screening (SPS) methodology is based on an empirical approach; SPS introduces artificial perturbations into the MIMD program and captures the effects of such perturbations by using the modern branch of statistics called design of experiments. SPS can provide the basis of a powerful tool for screening MIMD programs for performance bottlenecks. This technique is portable across machines and architectures, and scales extremely well on massively parallel processors. The purpose of this paper is to explain the general approach and to extend it to address specific features that are the main source of poor performance on the shared memory programming model. These include performance degradation due to load imbalance and insufficient parallelism, and overhead introduced by synchronizations and by accessing shared data structures. We illustrate the practicality of SPS by demonstrating its use on two very different case studies: a large image understanding benchmark and a parallel quicksort.

show abstract

Performance debugging shared memory multiprocessor programs with MTOOL

Cited by 38 publications

References 10 publications

The Cilkview scalability analyzer

The Cilkview scalability analyzer

Effectiveness of trace sampling for performance debugging tools

Synthetic‐perturbation techniques for screening shared memory programs

Contact Info

Product

Resources

About