instr (Раздаточные материалы)

IntroductionSeptember 8, 1993A Portable Dynamic Profilerfor C++ based LanguagesBernd MohrDepartment of Computer and Information ScienceUniversity of OregonEugene, Oregon 97403email: mohr@cs.uoregon.eduAbstractProgram profiling is the first step in program tuning. For sequential languages, thenecessary profiling code is automatically inserted by the compiler via a command lineswitch. However, not all compilers for parallel languages have this feature.

This articleintroduces a portable dynamic profiler for (parallel) languages which are based on C++.The first part describes the general approach which allows portable and dynamic programprofiling. The second part describes an instrumentation tool for pC++ which weimplemented for inserting the necessary profiling code in the program source.1 IntroductionIn general, a very valuable tool for program tuning is function profiling. For functionprofiling, special code has to be inserted at all entry and exit points of each function. Thiscode is then used to calculate the number of times this function is called and thepercentage of the total runtime which was spent in that routine. The necessarycomputations can be carried out in two ways.

First, the profile can be directly computedduring the runtime of the program (direct profiling). Second, all entry and exit points of afunction can be traced and the necessary computations are then done on the basis of theresulting event trace (trace-based profiling). The second method has the advantage that thedata in the event trace can also be used for further program analysis, e.g., programvisualization or animation.Compilers for sequential languages, especially on UNIX based operating systems, ofteninclude a command line option, which automatically instruments the program source forprofiling tools like prof or gprof [GKK82].

However, almost all compilers for parallellanguages lack this feature, as they are often research tools and emphasis is put on a properlanguage design and not on supporting performance tools.D R A F T 0.21Profiling C++September 8, 1993In this article we introduce a portable dynamic profiler for (parallel) languages which arebased on C++. All necessary program transformations are performed on the C++ languagelevel. This makes our approach extremely portable and flexible. It supports both direct andtrace-based profiling.

The first part of this article describes how features of C++ can beused to easily instrument the program source for profiling. The next section explains howthis can be used for dynamic profiling, i.e., the amount of profiling data which is recordedchanges during runtime depending on static and dynamic program properties. This featureis very useful for large parallel systems where it is important to be able to limit the totalamount of data to record. The second part describes an instrumentation tool for pC++ (aobject-parallel extension to C++) we implemented for inserting the necessary profilingcode in the program source.

Finally, the current pC++ profiling and tracing environment isdescribed.2 Profiling C++This section describes our general approach for profiling programs written in C++ or C++based languages.2.1General ApproachAll necessary program transformations are carried out on the language level. This ensuresportability. Profiling means inserting special code on all entry and exit points of allfunctions of a program. As there is no distinction between declarations and executablestatements in C++, we simply can add the necessary code for recording the entry into aprocedure by inserting it as the first statement of the function. Function exits are moreproblematic: First, there can be more than one exit point.

Second, consider the followingsmall example (see Figure 1).if ( something )return ( foo() );if ( something ) {foo_type f = foo();code_for_exit();return ( f );}FIGURE 1. Instrumentation exampleWe have to ensure that the exit code is executed as late as possible. A return expression ingeneral can be an arbitrary (and therefore complex) expression with function calls, andD R A F T 0.22Profiling C++September 8, 1993take a very long time. So, we have to extract the expression from the return statement, andcompute its value in advance.

Then we can execute the profiling exit code, and finallyreturn the computed value of the expression.Actually, we don’t have to do this transformations by ourself. By using a well-known C++trick, we can let the C++ compiler do the dirty work. The trick is very simple: We declarea special class Profiler (see Figure 1) which only has a constructor and a destructorand no other members. If we declare a variable of that class type as an automatic object inthe first line of each function which has to be profiled, it is initialized each time the controlflow reaches its definition (and the constructor is called) and destroyed on exit from itsblock (calling the destructor).class Profiler {char* name;public:Profiler(char *n) { name=n; code_for_enter(name); }~Profiler() { code_for_exit(name); }};void bar(){Profiler tr(“bar”); // Profiler variable// body of bar}FIGURE 2.

Class ProfilerThe C++ compiler is clever enough to rearrange the code by itself and to insert calls to thedestructor at the right places. Note also, that we use a private member to store a functionidentification which we can use in the destructor.2.2Dynamic ProfilingThe approach described above has basically two advantages:(1)Instrumenting at the source code level makes it very portable.(2)Different implementations of the profiler can be easily implemented by providingdifferent code for the code_for_enter and code_for_exit functions. Thismakes it very flexible.Currently, we have implemented two versions of the profiler:(1)Direct Profiling: The function profile is directly computed during the runtime of theprogram. In order to achieve that, we maintain a set of data values for each functionto be profiled.

The declaration of the structure to hold these values is shown inD R A F T 0.23Instrumenting pC++September 8, 1993struct p_func_descr {int numcalls;// number of callsdouble usec;// microseconds spent in this// function alonedouble cumusec;// microseconds spent in this// function and all its childs}FIGURE 3. Structure for holding Function Profile DataFigure 1. The actual implementation of the direct profiler uses two additionalmembers compared to the Profiler class declaration defined in Figure 1. One forstoring the timestamp of the entry into the function and the second to remember theparent function (i.e., the function who called the current function).

Both membersare set by the constructor (code_for_enter), which also increments thenumcalls field. The destructor (code_for_exit) uses the entry timestamp tocompute the duration of the function call and adds this value to the correspondingusec and cumusec fields, but also subtracts it from the usec field of its parentfunction. Through this trick we can compute the time spent in a function itself notcounting its children. If there is no parent function, i.e., the function is the mainfunction, the profile data gathered for all functions is written to a file by thedestructor.(2)Trace-based Profiling: Here the code_for_enter and code_for_exitfunctions simply call an event logging function from the portable software eventtracing module [mohr93b].

All events inserted are assigned to the event classEC_PROFILER. By using event classes, the event recording can be activated/deactivated at runtime (see se_event(3)). The computation of the profile statistics isthen done off-line.Other alternatives could be implemented in the same way. For example, there could be animplementation where the profiling code can be activated/deactivated for each functionseparately. One way of achieving this would be to have a global array with an entry perfunction, which indicates what to do when this function is called (e.g., do not profile,profile, stop execution, etc.) This array could be initialized at runtime making it a veryflexible and dynamic profiling environment which can be controlled by the user. Yetanother alternative would be to have user supplied, function specific profile code (e.g.,specified through source code annotations or special class members with predefinednames).3 Instrumenting pC++pC++ is an object-parallel extension to the C++ programming language [BBG+92b,BBG+93, gann93].

The pC++ compiler (pc++) consists of several stages which are shownD R A F T 0.24Instrumenting pC++September 8, 1993in Figure 4. pC++ source code is first parsed using pC++2dep, one file at a time toproduce a machine independent binary internal format called a .dep file. The programdep2C++ transforms it into a SPMD style C++ program for a parallel computer system.The C++ file is then compiled with the help of a conventional C++ compiler (like CC org++) and linked together with the pC++ runtime system to an executable.pC++SourcepC++KernelpC++2depinstrumentcommands.depFileInstrumentordep2C++functionsymbol fileC++FilepC++RTSTDL / EDFdescriptionCC or g++ExecutableFileFIGURE 4. pC++ Translation ProcessThe dep2C++ translator is implemented on top of Sage++, a sophisticated class libraryfor building C++ restructuring tools [BBG+92a].D R A F T 0.25Instrumenting pC++3.1September 8, 1993Implementation of the InstrumentorAs our approach for profiling is based on source code instrumentation, we can use theSage++ library for manipulating the pC++ program source in order to insert the necessaryprofiler class variable declarations at the beginning of each function.

So, the instrumentorconsists basically of three phases: (1) read the corresponding .dep file, (2) manipulate thesyntax tree with the help of Sage++ according to commands in a so-called instrumentationcommand file, and (3) write the changes back into the .dep file.The instrumentor supports both direct profiling and trace-based profiling.

On demand, theinstrumentor can produce description files which are helpful for analyzing the resultingprofile data. For direct profiling, a function symbol file (named “profile.ftab“) isgenerated which is used by the parallel profile printing tool (pprof).

For trace-basedprofiling, a TDL description [mohr90] of the profiling trace file and a general eventdescription file (EDF) is generated.3.2The Instrumentation Command FileBy default, every function in the given C++ input files is profiled.

However, the user canspecify the set of functions to instrument with the help of a instrumentation command file.The file can contain a sequence of instrumentation commands, one per line. Empty linesare ignored. The # character introduces a comment terminated by a newline.InstrCommand:“include”“file”“exclude”“class”Name“function”QualifiedNameName:Identifier“<”regularExpression“>”FIGURE 5. Syntax Diagram for “InstrCommand”A command is either an include or an exclude command.