Reilly, M., A Performance Monitor for Parallel Programs, Academic Press Inc., 1990.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....software to resolve linear programming problems on a transputer based platform using a PC as a front end. In [11] there is a description of the methodology and studies made in order to evaluate SIMPAR. In the literature, we can find similar tools like [2] 3] 4] 5] 9] 12] 13] [14] and [16] ANDES differs from existing systems basically in the metrics used and in the methodology applied. This work was done at Universidad Sim on Bol ivar, Caracas, Venezuela 1 2 Description of ANDES ANDES is a software monitor which analyzes the performance of a parallel program by ....

Reilly, M., A Performance Monitor for Parallel Programs, Academic Press Inc., 1990.

....These tools use different mechanisms (i.e. software, hardware or hybrid) to record events of interest related to performance. However, these profiling mechanisms may perturb the behaviour of the application being monitored, becoming a significant factor. This factor, often called invasiveness [27], perturbation [17] or intrusiveness [2] must be taken into account when measuring the performance of an application in order to provide more accurate information. The purpose of this paper is to determine the degree of invasiveness of PARMACS, a well known set of macros which provides a ....

Matthew Reilly. A Performance Monitor for Parallel Programs. Academic Press, Inc., 1990.

....performance data can be generated so that program execution may be monitored. Many such mechanisms have been proposed, these include event sampling [3] hardware event recorders [4] and software event recorders [5] A detailed survey of these methodologies for multiprocessors may be found in [6]. Although event sampling produces the smallest amount of data, it is not adopted in AIMS because we wanted to capture and replay the entire execution process for the programmer to analyze his her code. Event sampling can also be very intrusive without instrumentation hardware. In order to support ....

M. H. Reilly, A Performance Monitor for Parallel Programs. Academic Press Inc . 1990.

....restrictions: ffl All the parallel programs to be analyzed by ANDES must terminate successfully, including all its constituent processes. ffl ANDES is not designed for real time applications. ffl Due to the fact that ANDES is a software monitor, it introduces some degree of invasiveness 1 [137]. ffl The user must specify the particular characteristics of the topology where ANDES will run. For this prototype, the topology is a bidirectional ring. 3.1.1 Performance Metrics The main goals of a parallel performance analyzer are: ffl To determine the performance of the program: This ....

....tools use different mechanisms (i.e. software, hardware or hybrid) to record events of interest related to performance. However, these profiling mechanisms may perturb the behaviour of the application being monitored and can become a significant factor. This factor, often called invasiveness [137], perturbation [140] or intrusiveness [54] must be taken into account when measuring the performance of an application in order to provide more accurate information. The purpose of this Chapter is to describe our experience determining the degree of invasiveness of PARMACS, a well known set of ....

Matthew Reilly, A Performance Monitor for Parallel Programs, Academic Press, Inc., 1990.

....computational behavior by modifying program code is prohibitive. Introspective computer systems require events that are capable of describing the complete computational behavior without interfering with program execution. One solution that provides such events is real time hardware monitors [12, 17, 18, 24]. Even these events can be incomplete, because hardware monitors might watch buses without access to the internal operation of the processor. A solution is to provide events at the machine level. Each event provides the description of the execution of one machine instruction. Low level events have ....

M. H. Reilly. A Performance Monitor for Parallel Programs. Academic Press, Boston, 1990.

....displayed for studying memory access patterns, different cache replacement algorithms and effects of multiprocessors on matrix algorithms. However, SHMAP does not directly monitor parallel programs on a shared memory machine but uses simulations on a sequential machine. On the other hand, Reilly [17] develops a hardware monitor for the multiprocessor VAX system M31 designed and built by DEC Advanced VAX System Group. The M31 was designed to allow experimentation in the area of parallel program development and system design. To serve this purpose the M31 s design includes support for an ....

Reilly, M. H. A Performance Monitor for Parallel Programs, Academic Press, 1990.

....computational behavior by modifying program code is prohibitive. Introspective computer systems require events that are capable of describing the complete computational behavior without interfering with program execution. One solution that provides such events is real time hardware monitors [105, 133, 138, 169]. Even these events can be incomplete, because hardware monitors might watch buses without access to the internal operation of the processor. Several false starts were attempted before the final solution was found. These false starts include a nearly complete C source code interpreter that worked ....

....monitor (stored program tools) 52, 112] Stored program tools are the most flexible and satisfactory, but they impose a high cost on the monitor because the monitor must operate at a much faster rate than that of the system being monitored. An extensive survey of monitoring tools is presented in [138]. This section presents a new technique that enables fast evaluation of Boolean expressions in hardware. This technique uses the same notion of the total differential of a Boolean function as the Unison algorithm described in Section 4.6. The total differential of a Boolean function of two ....

[Article contains additional citation context not shown here]

M. H. Reilly. A Performance Monitor for Parallel Programs. Academic Press, Boston, 1990.

....debugging tool. Minimally intrusive probes, typically requiring less than 0.1 of the machines cycles, are present at all times and provide a stable, instructive, programming environment. Monitors vary in their event detection capability and level of intrusiveness. For example, the M31 system [10], is a completely passive (non intrusive) monitor and can gather information at the hardware (e.g. cache hit rates) operating system (e.g. context switches) and application (e.g. subroutine calls) levels. Unfortunately, this requires special micro coded sensor processors that are almost as ....

....a number of recent designs: the test and measurement processor (TMP hardware) for the INCAS system [2] MCC s ES Kit performance monitor [8] Intel iPSC 2 [7] and MSU s MSPARC multicomputer performance monitor [3] 6] 13] Fig. 1 indicates the relationship of hybrid monitors to these two extremes[10]. The hybrid monitor moderates hardware and software costs while remaining minimally intrusive. II. MSPARC OVERVIEW The MSPARC machine is a mesh connected multicomputer developed within Mississippi State University s NSF Engineering Re ############# ############# ############# ######## # ##### ....

M. H. Reilly, A Performance Monitor for Parallel Programs. Boston, MA: Academic Press, Inc., 1990.

....yes no Define Performance Criteria Diagnosis Phase Figure 1.1. System Performance Management Process 1.2.1 Measurement Techniques When performance is being studied on an existing system, an important consideration is how the measurements are to be collected. Generally, there are three approaches [22, 53]: hardware monitors, software monitors, and hybrid monitors. Hardware monitors use a hardware device to collect and record data. Hardware monitors are excellent for collecting low level data such as memory accesses, cache hits, and instruction frequencies. Since no software is involved, the act of ....

....data such as memory accesses, cache hits, and instruction frequencies. Since no software is involved, the act of monitoring is passive: it has no effect on the system being monitored. The idea that the data collected by the monitor is influenced by the act of monitoring is called the probe effect [22, 49, 53]. Software monitors collect and record data with a software program. Event driven software monitors execute and record data when certain events occur on the system. Events related to the execution of programs on the system such as program start up or terminate, I O requests, and system calls are ....

Reilly, M. H. A Performance Monitor for Parallel Programs. Academic Press, Inc., San Diego, CA, 1990.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC