Title: Objectives: To Understand and Task Distribution Using Gprof.l Theory

Download as pdf or txt
Download as pdf or txt
You are on page 1of 12

Title: Write a program to check task distribution using Gprof.

Objectives: To understand and task distribution using Gprof.l

Theory: Gprof is a performance analysis tool for Unix applications. It uses a hybrid of
instrumentation and sampling and was created as extended version of the older "prof" tool. Unlike
prof, gprof is capable of limited call graph collecting and printing. GPROF was originally written b
y a group led by Susan L. Graham at the University of California, Berkeley for Berkeley Unix
(4.2BSD). Another implementation was written as part of the GNU project for GNU Binutils
in 1988 by Jay Fenlason. Profiling is an important aspect of software programming. Through
profiling one can determine the parts in program code that are time consuming and need to be
rewritten. This helps make your program execution faster which is always desired. In very large
projects, profiling can save your day by not only determining the parts in your program which are
slower in execution than expected but also can help you find many other statistics through which
many potential bugs can be spotted and sorted out. How to use gprof ?Using the gprof tool is not at
al l complex. You just need to do the following on a high level: Have profiling enabled while
compiling the code. Execute the program code to produce the profiling data. Run the gprof tool on
the profiling data file (generated in the step above). The last step above produces an analysis file
which is in human readable form. This file contains a couple of tables (flat profile and call
graph) in addition to some other information. While flat profile gives an overview of the timing
information of the functions like time consumption for the execution of a particular function, how
many times it was called etc. On the other hand, call graph focuses on each function like the
functions through which a particular function was called, what all functions were called from
withinthis particular function etc So this way one can get idea of the execution time spent in the
sub-routines too.. Gprof Setup and Usage. Here are some of the steps required for downloading and
setting environment for gprof : If not installed already, download and install gprof by executing
apt-get install binutils. To check that gprof is installed properly, execute the gprof
command and it should give some error like a.out: No such file or directory. Assuming that the
compiler being used it gcc or cc, compile your code with the option pg so that the executable
includes extra code for profiling purpose. Run the program in a normal way. When the program
terminates, a file named gmon.out (profiler data) would be produced in the same directory from
which the program was run. Use the gprof profiler to process this profiler data (gmon.out) and
produce human readable performance analysis and statistics of the program.

Steps for execution:

1. First, compile your application as you normally would, but


be sure to include the -pg flag.
Note that if you compile and link as separate steps in your
application built, you will need to include -pg in both steps.
%gcc -03 -pg -o myprog myprog.c

2.For parallel applications only: if you want each parallel process


to produce its own output file, you will need to set the
undocumented environment variable GMON_OUT_PRFIX
to some non-null string. For example
% setenv GMON_OUT_PREFIX ‘gmon.out’

3.Run your application as usual. The example below shown a 16


task MPI application running in the pdebug partition.
%srun -n16 -ppdebug myprog
4.View the results: use the gprof command to convert the output
file into human readablereport. Several examples shown below:a.Serial
b.Parallel –one process only
c.Parallel –multiple processes
d.Parallel –all processes
1 % gprof myprog gmon.out
2 % gprof myprog gmon.out.18302
3 % gprof myprog gmon.out.18297 gmon.out.18300
gmon.out.9097
4 % gprof myprog gmon.out.*
Another option for parallel programs is to sum a
ll output files into single gmon.sum file which can
then be viewed with gprof. For eample
%
gprof myprog
-
s gmon.out.*
%
gprof myprog gmon.sum

Program:

//test_gprof.c
#include<stdio.h>

void new_func1(void);
void func1(void)
{
printf("\n Inside func1 \n");
int i = 0;
for(;i<10000000;i++);
new_func1();
return;
}

static void func2(void)


{
printf("\n Inside func2 \n");
int i = 0;
for(;i<10000000;i++);
return;
}

int main(void)
{
printf("\n Inside main()\n");
int i = 0;
for(;i<10000000;i++);
func1();
func2();
return 0;
}
//test_gprof_new.c
#include<stdio.h>
void new_func1(void)
{
printf("\n Inside new_func1()\n");
int i = 0;
for(;i<10000000;i++);
return;
}

Output:

--------------------------------------------------------------------------------------------------------------------
comp-sys-16@compsys16:~$ gcc -Wall -pg test_gprof.c test_gprof_new.c -o test_gprof

comp-sys-16@compsys16:~$ ./test_gprof

Inside main()

Inside func1

Inside new_func1()

Inside func2

comp-sys-16@compsys16:~$ gprof test_gprof gmon.out > analysis5.txt

comp-sys-16@compsys16:~$

OUTPUT:

Analysis5.txt

Flat profile:

Each sample counts as 0.01 seconds.

% cumulative self self total

time seconds seconds calls ms/call ms/call name

33.68 0.03 0.03 1 30.31 30.31 new_func1


22.45 0.05 0.02 1 20.21 50.52 func1

22.45 0.07 0.02 1 20.21 20.21 func2

22.45 0.09 0.02 main

% the percentage of the total running time of the

time program used by this function.

cumulative a running sum of the number of seconds accounted

seconds for by this function and those listed above it.

self the number of seconds accounted for by this

seconds function alone. This is the major sort for this

listing.

calls the number of times this function was invoked, if

this function is profiled, else blank.

self the average number of milliseconds spent in this

ms/call function per call, if this function is profiled,

else blank.

total the average number of milliseconds spent in this

ms/call function and its descendents per call, if this

function is profiled, else blank.

name the name of the function. This is the minor sort

for this listing. The index shows the location of


the function in the gprof listing. If the index is

in parenthesis it shows where it would appear in

the gprof listing if it were to be printed.

Call graph (explanation follows)

granularity: each sample hit covers 2 byte(s) for 11.00% of 0.09 seconds

index % time self children called name

<spontaneous>

[1] 100.0 0.02 0.07 main [1]

0.02 0.03 1/1 func1 [2]

0.02 0.00 1/1 func2 [4]

-----------------------------------------------

0.02 0.03 1/1 main [1]

[2] 55.6 0.02 0.03 1 func1 [2]

0.03 0.00 1/1 new_func1 [3]

-----------------------------------------------

0.03 0.00 1/1 func1 [2]

[3] 33.3 0.03 0.00 1 new_func1 [3]

-----------------------------------------------

0.02 0.00 1/1 main [1]

[4] 22.2 0.02 0.00 1 func2 [4]

-----------------------------------------------

This table describes the call tree of the program, and was sorted by

the total amount of time spent in each function and its children.

Each entry in this table consists of several lines. The line with the
index number at the left hand margin lists the current function.

The lines above it list the functions that called this function,

and the lines below it list the functions this one called.

This line lists:

index A unique number given to each element of the table.

Index numbers are sorted numerically.

The index number is printed next to every function name so

it is easier to look up where the function in the table.

% time This is the percentage of the `total' time that was spent

in this function and its children. Note that due to

different viewpoints, functions excluded by options, etc,

these numbers will NOT add up to 100%.

self This is the total amount of time spent in this function.

children This is the total amount of time propagated into this

function by its children.

called This is the number of times the function was called.

If the function called itself recursively, the number

only includes non-recursive calls, and is followed by

a `+' and the number of recursive calls.

name The name of the current function. The index number is

printed after it. If the function is a member of a


cycle, the cycle number is printed between the

function's name and the index number.

For the function's parents, the fields have the following meanings:

self This is the amount of time that was propagated directly

from the function into this parent.

children This is the amount of time that was propagated from

the function's children into this parent.

called This is the number of times this parent called the

function `/' the total number of times the function

was called. Recursive calls to the function are not

included in the number after the `/'.

name This is the name of the parent. The parent's index

number is printed after it. If the parent is a

member of a cycle, the cycle number is printed between

the name and the index number.

If the parents of the function cannot be determined, the word

`<spontaneous>' is printed in the `name' field, and all the other

fields are blank.


For the function's children, the fields have the following meanings:

self This is the amount of time that was propagated directly

from the child into the function.

children This is the amount of time that was propagated from the

child's children to the function.

called This is the number of times the function called

this child `/' the total number of times the child

was called. Recursive calls by the child are not

listed in the number after the `/'.

name This is the name of the child. The child's index

number is printed after it. If the child is a

member of a cycle, the cycle number is printed

between the name and the index number.

If there are any cycles (circles) in the call graph, there is an

entry for the cycle-as-a-whole. This entry shows who called the

cycle (as parents) and the members of the cycle (as children.)

The `+' recursive calls entry shows the number of function calls that

were internal to the cycle, and the calls entry for each member shows,

for that member, how many times it was called from other members of

the cycle.

Index by function name


[2] func1 [1] main

[4] func2 [3] new_func1


---------------------------------------------------------------------------------------------------------
Annotated source:
comp-sys-16@compsys16:~$ gprof -A test_gprof gmon.out > analysis5.txt

*** File /home/comp-sys-16/test_gprof_new.c:

//test_gprof_new.c

#include<stdio.h>

void new_func1(void)

1 -> {

printf("\n Inside new_func1()\n");

int i = 0;

for(;i<10000000;i++);

return;

Top 10 Lines:

Line Count

5 1
Execution Summary:

1 Executable lines in this file

1 Lines executed

100.00 Percent of the file executed

1 Total number of line executions

1.00 Average executions per line

*** File /home/comp-sys-16/test_gprof.c:

//test_gprof.c

#include<stdio.h>

void new_func1(void);

void func1(void)

1 -> {

printf("\n Inside func1 \n");

int i = 0;

for(;i<10000000;i++);

new_func1();

return;

}
static void func2(void)

1 -> {

printf("\n Inside func2 \n");

int i = 0;

for(;i<10000000;i++);

return;

int main(void)

##### -> {

printf("\n Inside main()\n");

int i = 0;

for(;i<10000000;i++);

func1();

func2();

return 0;

Top 10 Lines:

Line Count
7 1

18 1

Execution Summary:

3 Executable lines in this file

3 Lines executed

100.00 Percent of the file executed

2 Total number of line executions

0.67 Average executions per line

Conclusion: Hence, we studied and implemented the gprof.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy