📄 http:^^www.cs.wisc.edu^~paradyn^papers.html
字号:
Date: Tue, 05 Nov 1996 00:26:37 GMTServer: NCSA/1.5Content-type: text/htmlLast-modified: Thu, 26 Sep 1996 18:02:09 GMTContent-length: 23629<head><title>Paradyn Project Papers</title></head><body><!WA0><IMG SRC="http://www.cs.wisc.edu/~paradyn/paradyn.wide.gif" ALT="Paradyn Logo" ALIGN=MIDDLE><H1>Paradyn Project Papers</H1><P>The papers listed on this page have been produced by the Paradyn Project.<P>You can retrieve a PostScript copy of any of the papers listed byclicking on the paper's title. For this to work automatically, you must havea PostScript previewer on your system.In a few cases, the document is in HTML.<hr><P><!WA1><A HREF="ftp://grilled.cs.wisc.edu/technical_papers/overview.ps.Z"><H3>The Paradyn Parallel Performance Measurement Tools</H3></A>Barton P. Miller, Mark D. Callaghan, Jonathan M. Cargille, Jeffrey K. HollingsworthR. Bruce Irvin, Karen L. Karavanic,Krishna Kunchithapadam, and Tia Newhall.IEEE Computer 28, 11 (November 1995).Special issue on performance evaluation tools for parallel and distributed computer systems.<P><em>Note: this paper contains several color postscript pages. Itshould print acceptably on b/w printers.</em><P>Paradyn is a performance measurement tool for parallel and distributedprograms.Paradyn uses several novel technologies so that itscales to long running programs (hours or days)and large (thousand node) systems,and automates much of the search for performance bottlenecks.It can provide precise performance data down to the procedure andstatement level.<P>Paradyn is based on a dynamic notion of performance instrumentation andmeasurement.Unmodified executable files are placed into execution and thenperformance instrumentation is inserted into the applicationprogram and modified during execution.The instrumentation is controlled by the Performance Consultant module,that automatically directs the placement of instrumentation.The Performance Consultanthas a well-defined notion of performance bottlenecks and programstructure, so that it can associate bottlenecks with specific causes andspecific parts of a program.Paradyn controls its instrumentation overhead by monitoring the cost ofits data collection, limiting its instrumentation to a (user controllable)threshold.<P>The instrumentation in Paradyn can easily be configured to accept newoperating system, hardware, and application specific performance data.It also provides an open interface for performance visualization,and a simple programming library to allow these visualizations to interfaceto Paradyn.<P>Paradyn can gather and present performance data in terms of high-levelparallel languages (such as data parallel Fortran) and can measure programson massively parallel computers, workstation clusters, and heterogeneouscombinations of these systems.<P><!WA2><A HREF="http://www.cs.wisc.edu/~paradyn/dyninstAPI.html"><H3>Dynamic Instrumentation API (proposed)</H3></A>Jeffrey K. Hollingsworth, Barton P. Miller(1996).<P><!WA3><A HREF="ftp://grilled.cs.wisc.edu/technical_papers/costmodel.ps.Z"><H3>An Adaptive Cost Model for Parallel Program Instrumentation</H3></A>Jeffrey K. Hollingsworth and Barton P. Miller.Europar '96 (Lyon, France, August 1996).<P>Software based instrumentation is frequently used to measure theperformance of parallel and distributed programs. However, usingsoftware instrumentation can introduce serious perturbation of theprogram being measured. In this paper we present a new data collectioncost system that provides programmers with feedback about the impactdata collection is having on their application. In addition, we introducea technique that permits programmers to define the perturbation theirapplication can tolerate and then we are able to regulate the amount ofinstrumentation to ensure that threshold is not exceeded. We alsodescribe an implementation of the cost model and presents results fromusing it to measure the instrumentation overhead for several realapplications.<P><P><!WA4><A HREF="ftp://grilled.cs.wisc.edu/technical_papers/dyninst.ps.Z"><H3>Dynamic Program Instrumentation for Scalable Performance Tools</H3></A>Jeffrey K. Hollingsworth, Barton P. Miller, and Jon Cargille.SHPCC (Knoxville TN, May 1994) <P>In this paper, we present a new technique called dynamicinstrumentation that provides efficient, scaleable, yet detaileddata collection for large-scale parallel applications. Ourapproach is unique because it defers inserting any instrumentationuntil the application is in execution. We can insert or changeinstrumentation at any time during execution. Instrumentation isinserted by modifying the application's binary image. This permitsus to insert only the instrumentation that is necessary for thecurrent analysis being performed or visualization presented. As aresult, our technique collects several orders of magnitude lessdata than traditional data collection approaches. We haveimplemented a prototype of our dynamic instrumentation on theThinking Machines CM-5, and present results for several realapplications. In addition, we include recommendations to operatingsystem designers, compiler writers, and computer architects aboutthe features necessary to to permit efficient monitoring oflarge-scale parallel systems.<P><!WA5><A HREF="ftp://grilled.cs.wisc.edu/technical_papers/w3search.ps.Z"><H3>Dynamic Control of Performance Monitoring on Large Scale Parallel Systems</H3></A>Jeffrey K. Hollingsworth and Barton P. Miller.International Conference on Supercomputing (Tokyo, July 19-23, 1993).<P>Performance monitoring of large scale parallel computers creates adilemma: we need to collect detailed information to find performancebottlenecks, yet collecting all this data can introduce serious datacollection bottlenecks. At the same time, users are being inundatedwith volumes of complex graphs and tables that require a performanceexpert to interpret. We present a new approach called theW cubed Search Model, that addresses both these problems bycombining dynamic on-the-fly selection of what performance data tocollect with decision support to assist users with the selection andpresentation of performance data. Our goal is to provide users withanswers to their performance questions and at the same timedramatically reduce the volume of performance data we need to collect.We present a case study describing how a prototype implementation ofour technique was able to identify the bottlenecks in three realprograms. In addition, we were able to reduce the amount ofperformance data collected by a factor ranging from 13 to 700 comparedto traditional sampling and trace based instrumentation techniques.<!WA6><A HREF="ftp://grilled.cs.wisc.edu/technical_papers/hollingsworth_thesis.ps.Z"><H3>Finding Bottlenecks in Large-scale Parallel Programs</H3></A>Jeffrey K. Hollingsworth. Ph.D. Thesis, August 1994.<P><em>Note: this paper contains several color postscript pages.</em><P>This thesis addresses the problem of trying to locate the source ofperformance bottlenecks in large-scale parallel and distributedapplications. Performance monitoring creates a dilemma: identifying abottleneck necessitates collecting detailed information, yet collectingall this data can introduce serious data collection bottlenecks. Atthe same time, users are being inundated with volumes of complex graphsand tables that require a performance expert to interpret. I havedeveloped a new approach that addresses both these problems bycombining dynamic on-the-fly selection of what performance data tocollect with decision support to assist users with the selection andpresentation of performance data. The approach is called the W3 SearchModel (pronounced W-cubed). To make it possible to implement the W3Search Model, I have developed a new monitoring technique for parallelprograms called Dynamic Instrumentation. The premise of my work isthat not only is it possible to do on-line performance debugging, butfor large scale parallelism it is mandatory.<P>The W3 Search Model closes the loop between data collection andanalysis. Searching for a performance problem is an iterative processof refining the answers to three questions: why is the applicationperforming poorly, where is the bottleneck, and when does the problemoccur. To answer the why question, tests are conducted to identify thetype of bottleneck (e.g., synchronization, I/O, computation).Answering the where question isolates a performance bottleneck to aspecific resource used by the program (e.g., a disk system, asynchronization variable, or a procedure). Answering when a problemoccurs, tries to isolate a bottleneck to a specific phase of theprogram's execution.<P>Dynamic Instrumentation differs from traditional data collectionbecause it defers selecting what data to collect until the program isrunning. This permits insertion and alteration of the instrumentationduring program execution. It also features a new type of datacollection that combines the low data volume of sampling with theaccuracy of tracing. Instrumentation to precisely count and timeevents is inserted by dynamically modifying the binary program. Thesecounters and timers are then periodically sampled to provideintermediate values to the W3 Search Model. Based on this intermediatedata, changes are made in the instrumentation to collect moreinformation to further isolate the bottleneck.<P>I have built a prototype implementation of the W3 Search Model and ofDynamic Instrumentation. The prototype runs on Thinking Machine's CM-5and a network of workstations running PVM. In one study, the toolsidentified the bottlenecks in several real programs using two to threeorders of magnitude less data than traditional techniques. In anotherstudy, Dynamic Instrumentation was used to monitor long runningprograms and introduced less than 10% perturbation. While the W3Search Model and Dynamic Instrumentation complement each other, theyare also useful individually. The W3 Search Model can be applied toexisting post-mortem performance tools or even to simulated machinesand environments. Dynamic Instrumentation has be used to collectperformance data for other uses including visualization. The W3 SearchModel and Dynamic Instrumentation are being incorporated into theParadyn Performance Tools.<!WA7><A HREF="ftp://grilled.cs.wisc.edu/technical_papers/nv2.ps.Z"><H3>Mapping Performance Data for High-Level and Data Views ofParallel Program Performance</H3></A>R. Bruce Irvin and Barton P. Miller.<br>International Conference on Supercomputing (Philadelphia, May 1996).<P><em>Note: this paper contains several color postscript pages. Itshould print acceptably on b/w printers.</em><P>Programs written in high-level parallel languages need profilingtools that provide performance data in terms of the semantics ofthe high-level language. But high-level performance data can beincomplete when the cause of a performance problem cannot beexplained in terms of the semantics of the language. We also needthe ability to view the performance of the underlying mechanismsused by the language and correlate the underlying activity to thelanguage source code. The key techniques for providing theseperformance views is the ability to map low-level performancedata up to the language abstractions.<P>We identify the various kinds of mapping information that needs⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -