MATE User's Guide Users

User Manual:

Open the PDF directly: View PDF .
Page Count: 20

MATE

HPCA4SE Autonomous University of Barcelona

Date: June 22, 2018

Version: 1.0

MATE USER’SGUIDE

CAOS (UAB)

June 22, 2018

COMPUTER ARCHITECTURES

AND OPERATING SYSTEMS DEPARTMENT

AUTONOMOUS UNIVERSITY OF BARCELONA

Email: gr.hpca4se@uab.cat

Web: http://grupsderecerca.uab.cat/hpca4se/en

https://github.com/HPCA4SE-UAB

gr.hpca4se@uab.cat

Index

1 Introduction 1

2 MATE installation 1

2.1 Dependencies and build ............................ 1

3 Conﬁguration ﬁles 3

3.1 Application controller - AC.ini ........................ 3

3.2 Analyzer - Analyzer.ini ............................. 4

3.3 Tunlet - Tunlet.ini ................................ 5

3.4 DMLib - DMLib.ini: ............................... 6

4 Full execution example with XFire 6

5 Tunlet creation and execution 7

5.1 Steps to create a tunlet ............................. 8

6 Annex 11

6.1 Conﬁgure options ................................ 11

6.2 Simple tunlet example ............................. 13

6.2.1 MPI application ............................. 13

6.2.2 Ctrl.cpp ................................. 14

6.3 XFire example .................................. 15

6.3.1 Analyzer.ini ............................... 15

6.3.2 AC.ini .................................. 16

6.3.3 Tunlet.ini ................................. 16

6.3.4 DMLib.ini ................................ 17

References 17

MATE

1 Introduction

The aim of this document is to explain the essential steps to conﬁgure, install and ex-

ecute MATE [2,3,4]. MATE needs two programs, the Analyzer and AC, to work in

conjunction with the DMLib shared library. In ﬁgure 1we can see how they interact

with each other:

Figure 1: MATE structure

Thus, MATE is composed of the following modules which cooperate to control and

improve the application’s performance:

• The Application Controller (AC) is a daemon that controls the execution and

the dynamic instrumentation of each individual MPI task.

• The Analyzer is a centralized process that carries out the application perfor-

mance analysis, and decides on the monitoring and tuning. It automatically de-

tects existing performance problems on the ﬂy and requests appropriate changes

to improve the application’s performance.

• The Dynamic Monitoring Library (DMLib) is a shared library that is dynami-

cally loaded by the AC in the application tasks to facilitate collecting data and

delivering it to the Analyzer

The knowledge required to perform analysis and tuning is encapsulated in MATE in

a piece of software called a tunlet which will be explained more in detail in section 5.

This document is composed of 4 main sections: MATE installation, conﬁguration ﬁles,

a full execution example and the steps to create a tunlet.

2 MATE installation

2.1 Dependencies and build

First off, MATE needs some dependencies to be installed before building it. Those are

the following:

1 (18)

MATE

•Dyninst - The most critical dependency for MATE is Paradyn’s Dyninst API.

This library is responsible for inserting the instrumentation to the application

that will be monitored. MATE is programmed and tested to work with versions

>7.0.1, being v9.3.2 the latest version tested with. Dyninst can be downloaded

from https://github.com/dyninst/dyninst [1].

•MPI - MATE is currently implemented for MPI applications and therefore, it

requires some installed version. The latest MPI installation and version tested

with MATE was OpenMPI v1.10.2 .

•PAPI - The latest tested version of PAPI along with MATE was v5.6.1. It can be

downloaded from http://icl.cs.utk.edu/papi/

•Other dependencies - MATE also needs the following libraries:

– Boost - The latest tested version of Boost was v1.62.0 . It can be downloaded

from https://www.boost.org/

– libelf & libdwarf - These two libraries can be downloaded from https:

//sourceforge.net/p/elftoolchain/wiki/Home/

– libiberty - It is usually installed along with gcc and it can be downloaded

from https://gcc.gnu.org/onlinedocs/libiberty/

Go to https://github.com/HPCA4SE-UAB/MATE to download MATE once all depen-

dencies have been cleared. The building of MATE is similar to any UNIX-like system

installation:

$ ./configure --with-dyninst=<DYNINST_DIR> --prefix=<PREFIX>

$ make && make install

For details on the features that can be input to the conﬁgure step, see the annex in

section 6or do:

$ ./configure --help

Additionaly, make has four targets explained below:

•make - Compiles the application and puts the binaries of Analyzer and AC in

their corresponding folders.

•make install - Installs MATE in the preﬁx chosen (by default /lib and /bin).

•make clean - Deletes the compiled ﬁles generated in the make step.

•make doc - Creates the documentation of MATE in ./doc using Doxygen .

The tree structure that MATE uses can be seen in Figure 2.

2 (18)

MATE

Figure 2: MATE folder tree

3 Conﬁguration ﬁles

After the installation process and depending on the application to monitor, you must

take care of MATE’s conﬁguration ﬁles. This step is necessary to make MATE work

in conjunction with the MPI application. There are four conﬁguration ﬁles that have

to be modiﬁed. Examples of these can be found in the root directory under the conf/

folder:

•AC.ini: conﬁgures the Application Controller,

•Analyzer.ini: conﬁgures the Analyzer,

•Tunlet.ini: conﬁgures the tunlet and

•DMLib.ini: conﬁgures the DMLib’s syslog options.

In general, a MATE conﬁguration ﬁle is composed of several sections with their own

parameters and should look like the following:

[section_name]

parameter_identifier =# user_provided_value

...

[another_section_name]

parameter_identifier =# user_provided_value

...

The details for each of these ﬁles are shown in the following subsections.

3.1 Application controller - AC.ini

The AC.ini ﬁle is where the AC conﬁguration is placed. This ﬁle requires the sections:

AC,Analyzer and Syslog detailed below:

[AC]

The AC section speciﬁes parameters associated to the application controller executable:

3 (18)

MATE

[AC]

ACPath =# Application Controller path

DMLib =# libDMLib.so library path

PTPAcceptorPort =# Analyzer waiting event port

[Analyzer]

The Analyzer section is where the Analyzer parameters are speciﬁed:

[Analyzer]

Host =# Host where the Analyzer is executing

Port =# Analyzer port

[Syslog]

The Syslog section is where the debug parameters have to be speciﬁed:

[Syslog]

MasterSwitch =# true/false

LogLevel =

# 0 - To show all debug messages in log file.

# 1 - To show INFO messages.

# 2 - To show no messages.

StdErrLogLevel =# 0/ 1/ 2 the same as LogLevel,

# but the message will be printed in terminal

StdErr =# true/false to activate the information output

LogFile =# log file name

LogPath =# log file path

AppendMachineName =# true/false

AppendFile =# true/false

Prefix =# prefix to use when printing information

3.2 Analyzer - Analyzer.ini

The Analyzer conﬁguration ﬁle requires the sections: Analyzer,EventCollector and

Syslog:

[Analyzer]

This section only requires the boolean parameter DisableTuningActions to be set. As its

name suggests, it will disable the tuning action if set to true:

[Analyzer]

DisableTuningActions =# true/false

4 (18)

MATE

[EventCollector]

This section deﬁnes the Analyzer port to use (where it receives the application metrics

from libDMLib.so):

[EventCollector]

Port =# Analyzer port where it will get the app metrics

# from libDMLib.so

[Syslog]

This section contains the same parameters as the previous Syslog section from the

Application Controller and should be ﬁlled with the values relative to the Analyzer.

3.3 Tunlet - Tunlet.ini

In the Tunlet conﬁguration ﬁle (Tunlet.ini), the functions to monitor and its associated

features are indicated in the Functions section. The ﬁelds function1, function2, ..., func-

tionN are necessary to follow the pattern.

[Functions]

function1 =# name of one function to monitor

function2 =# name of another function to monitor

...

Each of the functions deﬁned should have its corresponding section such that:

[name_of_function1]

entry =# FuncEntry/FuncExit

event =# iterStart/iterEnd ...

...

[name_of_function2]

entry =...

The parameters can have the following values:

entry FuncEntry / FuncExit this corresponds to where the function will be monitored,

FuncEntry if in function entry instance, FuncExit if in function exit instance.

event Name of the event that will be generated. Each event is some signiﬁcant activity

that will be performed during the execution of the app and that collects all the

necessary data during run-time.

Depending on the information that is desired to obtain from each function, one can

specify the following values:

•Source: Depending on the element to monitor, the source parameter can have the

following values:

5 (18)

MATE

Source Monitoring element

FuncParamValue Function parameter.

VarValue Function variable.

FuncReturnValue Function return value.

ConstValue Constant value.

FuncParamPointerValue Function pointer parameter.

SendMessageSize The size of the message to send.This attribute can

only be inserted if the entry speciﬁed is FuncEntry.

RecvMessageSize The size of the message to receive. This attribute can

only be inserted if the entry speciﬁed is FuncExit.

SenderTid The identiﬁer of the sender. This attribute can only

be inserted if the entry speciﬁed is FuncExit.

•type: The source type can be Integer,Short,Float,Double,Char or String.

•id: Since source is a function parameter, then id is the identiﬁer of the parameters.

For instance, if the function fis called by f(a,b,c), the id corresponding to ais

0, bis 1 and cis 2. In any other case, the id will correspond to the name of the

variable.

3.4 DMLib - DMLib.ini:

This conﬁguration ﬁle only contains a Syslog section which will have the same

parameters as the other ones. The values need to be changed to those relative to

the DMLib log ﬁles. An example of a DMLib.ini ﬁle can be seen in section 6.3.4.

4 Full execution example with XFire

For this full execution demo, the conﬁguration ﬁles that are used can be found in

section 6. The demo is done with the XFire application. Its ﬁles and installation steps

can be found in examples/xﬁre. The steps to execute XFire along with MATE are:

1. Install XFire: To install XFire, go to examples/xﬁre/src/ from MATE’s root direc-

tory and do:

$ ./configure && make

This will create a xﬁre executable in XFire’s root directory.

6 (18)

MATE

2. Conﬁgure Analyzer.ini: The Analyzer.ini conﬁg ﬁle is in the root directory of

XFire and can be seen in section 6.3.1. The default parameters and values already

in Analyzer.ini don’t need to be changed for the example to work.

3. Conﬁgure AC.ini: AC.ini is also provided in the root directory of XFire and can

be seen in section 6.3.2. The parameter ACPath and DMLib must be changed

to point to where the AC executable and libDMLib.so library are respectively (in

absolute path). The Host parameter represents the name or ip of the host where

the Analyzer will be run (e.g. localhost if in the same machine).

4. Conﬁgure Tunlet.ini: The Tunlet.ini can be seen in section 6.3.3. This is where the

events are deﬁned and will be added as instrumentation to the program. Those

do not need to be changed for the example to work.

5. Execute the Analyzer: The general way of calling the Analyzer is by doing:

$ Analyzer -config </Analyzer/config/file/path> <mpi_app>

To run the Analyzer example, inside XFire’s root dir, do:

$ Analyzer -config Analyzer.ini xfire

6. Execute the Application controller: The general way of calling the AC is by

doing:

$ mpirun -np <n_processes> AC <mpi_app> <app_params>

To run the AC with the XFire app, inside XFire’s root dir, do:

$ mpirun -np 4AC xfire demo

Where demo is the parameter that tells XFire to run an example.

After a while, the created events will start their execution and the log ﬁles will record

the outputs of the AC, Analyzer and DMLib in the speciﬁed paths. Those were ex-

plicitly input in AC.ini, Analyzer.ini and DMLib.ini with the parameters LogFile and

LogPath.

5 Tunlet creation and execution

To support the analysis of different problems, MATE includes a catalog of tuning

techniques where each one solves a particular problem. Each tuning technique pro-

vides information about measure points, performance model (analytical model or set

of rules) and tuning action/points/synchronization. Such knowledge is provided to

MATE via speciﬁc libraries called tunlets. Each tunlet implements the logic to over-

come a particular performance problem by encapsulating knowledge about it in sev-

eral terms that deﬁne the information required for the monitoring, analysis and tuning

phases. The tunlet is thought to detect and resolve situations (events) which are de-

sired to be controlled in your application.

7 (18)

MATE

5.1 Steps to create a tunlet

1. Creation of the tunlet: For a faster and easier tunlet creation, use the tunlet

example MyTunlet.h and MyTunlet.cpp inside the src/Analyzer/ folder in the root

directory of MATE. These and the rest of the ﬁles can be found in examples/simple-

tunlet/src/.

The steps to create a tunlet are detailed below:

(a) Create the events for the situations to detect: Each event has to be given a

name. Their deﬁnition is done in MyTunlet.cpp and MyTunlet.h by means of

an enumerator, so, these will have to be deﬁned as follows:

In MyTunlet.h:

1enum EventsEnum

3idReplaceFunction ,

4idSetVariableValue ,

5. . .

6} ;

Then, in MyTunlet.cpp we will only need to create the corresponding map:

1s td : : map< st d : : s t r i n g , EventsEnum> EventMap = \

2boost : : assign : : m a p _l i st_ o f ( " ReplaceFunction " , idReplaceFunction

) ( "SetVariableValue" , idSetVariableValue ) . . . ;

(b) Capture the events: In MyTunlet.cpp, the function MyTunlet::CreateEvent, in-

herited from the EventHandler class, creates the new events using the previ-

ously deﬁned map EventMap:

1void MyTunlet : : CreateEvent ( Task & t )

3// Create the event

4EventsEnum idEvent ;

6// Read the event name from Tunlet . i n i

7idEvent = ( EventsEnum ) EventMap \

[ _cfg . GetS tringValue ( func , " event " ) ] ;

9// Create the new event

10 Event endEvent ( idEvent , func , ipFu ncExi t ) ;

11 endEvent . SetEventHandler ( *t h i s ) ;

12 t . AddEvent ( endEvent ) ;

14 // These f i n a l l i n e s have to be included

15 st d : : s t r i n g semaphoreFunc = " MonitorSignal" ;

16 Event semaphoreEvent ( 0 , semaphoreFunc , i pF un cE xi t ) ;

17 semaphoreEvent . SetEventHandler ( *t h i s ) ;

18 t . AddEvent ( semaphoreEvent ) ;

19 }

MyTunlet::HandleEvent also inherited from EventHandler and therefore, there’s

where each speciﬁc action must be taken depending on what the event is. In

8 (18)

MATE

the example below, for idReplaceFunction, the action to perform is to change

the function function_to_replace() for new_function().

1void MyTunlet : : HandleEvent ( EventRecord const & r )

3switch ( r . GetEventId ( ) )

5case idReplaceFunction :

7_app−>GetMasterTask ( )−>ReplaceFunction ( "

function_to_replace" ," new_function " , 0) ;

8break ;

11 case idSetVariableValue : { . . . break ; }

12 }

13 }

(d) Finish the tunlet: Apart from the above requirements, the following meth-

ods need to be deﬁned in MyTunlet.cpp:

•Initialize(Model::Application & app)

•BeforeAppStart()

•Destroy()

Then from the EventHandler class:

•HandleEvent

•CreateEvent

And from the TaskHandler:

•TaskStarted

•TaskTerminated

Generally, these methods can be implemented by default instructions, un-

less requiring speciﬁc conﬁgurations. These default instructions are shown

in MyTunlet.cpp.

2. Modiﬁcation of Ctrl.cpp:1The class Controller is responsible for calling the de-

sired functions from our tunlet via its method Controller::Run, but ﬁrst, we must

place the necessary headers, including our tunlet:

1# in cl ud e " C t r l . h "

2# in cl ud e " Config . h "

3# in cl ud e "DTAPI . h "

4# in cl ud e " Syslog . h "

5# in cl ud e " MyTunlet . h "

6# in cl ud e <u nistd . h>

Then, we will deﬁne the constructor where we will read the conﬁguration ﬁle

with the ConﬁgHelper object.

1The whole code is included in section 6.2.2 and in examples/simple-tunlet/

9 (18)

MATE

7C o n t r o l l e r : : C o n t r o l l e r ( CommandLine & cmdLine , s td : : s t r i n g const &

c f g F i l e )

8: _cmdLine ( cmdLine )

10 // Read c o n f i g u r a t i o n from f i l e

11 _c fg = ConfigHelper : : ReadFromFile ( c f g F i l e ) ;

13 // Configure log

14 Syslog : : Configure ( _cf g ) ;

15 }

Now we can deﬁne the Controller::Run method that will call our functions from

the tunlet. First we have to create the application, a pointer to the DTLibrary (by

passing the conﬁguration to it) and an object for our tunlet:

17 void C o n t r o l l e r : : Run ( ShutDownManager *sdm)

18 {

19 DTLibrary *l i b = DTLibraryFactory : : C r ea t eL i br a ry ( _c fg ) ;

20 MyTunlet mt ;

22 // C re at e t he a p p l i c a t i o n model

23 Model : : A pp li ca t io n & app = l i b −>C re a te A pp lic ati on (

24 _cmdLine . GetAppPath ( ) ,

25 _cmdLine . GetAppArgc ( ) ,

26 _cmdLine . GetAppArgv ( ) ) ;

28 // S et t he r e f e r e n c e t o th e app i n th e sdm so i t can s to p t he ACs

29 sdm−>setApp ( app ) ;

31 // I n i t i a l i z e th e t u n l e t

32 mt . I n i t i a l i z e ( app ) ;

Then start the tunlet and the app:

34 // S t a r t app

35 mt . BeforeAppStart ( ) ;

36 app . S t a r t ( ) ;

And create the main loops that will take care of the event processing:

37 while ( app . G et St at us ( ) == s t S t a r t i n g && ! sdm−>i s F i n i s h e d ( ) ) {

38 i n t nEvents = app . ProcessE ven ts ( tr u e ) ; // Blocking

39 i f ( nEvents > 0 )

40 Syslog : : Debug ( " [ C t r l ] P roce ssed %d e ven ts " , nEvents ) ;

41 sl ee p ( 1 ) ;

42 }

44 // Do nothin g i f t he user stopped th e a p p l i c a t i o n

45 i f ( ! sdm−>i s F i n i s h e d ( ) ) {

46 Syslog : : Debug ( " [ C t r l ] App i s running . . . " ) ;

47 Syslog : : Debug ( " [ C t r l ] Waiting f o r e ve nt s " ) ;

48 }

50 while ( app . Ge tS ta tu s ( ) == stRunning && ! sdm−>i s F i n i s h e d ( ) ) {

51 int nEvents = app . ProcessEv ent s ( t r u e ) ; // Blocking

52 i f ( nEvents > 0 )

53 Syslog : : Debug ( " [ C t r l ] P roce ssed %d e ven ts " , nEvents ) ;

10 (18)

MATE

54 sl ee p ( 1 ) ;

55 }

Finally destroy both the tunlet and the library.

57 Syslog : : Debug ( " [ C t r l ] A p pl ic at io n has f i n i s h e d " ) ;

59 // Destroy the t u n l e t

60 mt . Destroy ( ) ;

62 // Cleanup

63 DTLibraryFactory : : Destro yLi bra ry ( l i b ) ;

64 }

Once the tunlet is created and Ctrl.cpp modiﬁed, the Analyzer has to be recom-

piled and reinstalled. To do so, include the object MyTunlet.o in the Makeﬁle

inside Analyzer/ and execute the following in MATE’s root folder:

$ make && make install

3. Conﬁgure Analyzer.ini, AC.ini, Tunlet.ini and DMLib.ini: Once the Analyzer

is ready, we must adapt the ﬁles Analyzer.ini, AC.ini, Tunlet.ini and DMLib.ini.

To ﬁnd the ones used in this example, go to examples/simple-tunlet/ or section 6of

this document. Also, templates of these can be found in conf/. They have to be

copied into the root directory of the MPI application that we will execute.

4. Start the Analyzer and AC: The last step to perform will be to start the Analyzer

and AC as explained in section 4:

$ Analyzer -config Analyzer.ini <mpi_app>

$ mpirun -np <n_processes> AC <mpi_app> <app_params>

6 Annex

6.1 Conﬁgure options

Conﬁgure allows the user to customize the installation of MATE. If there are some

packages installed in local, one can specify the following installation options to look

for them:

11 (18)

MATE

General options

--help Display the help message

--preﬁx=<dir> Specify the destination directory. By default /bin for

the binaries AC and Analyzer and /lib for the the DM-

Lib library

--with-papi PAPI directory (must contain ./lib and ./include)

--with-papi-incdir PAPI include directory

--with-papi-libdir PAPI library directory

--with-libiberty LIBIBERTY directory (must contain ./lib and ./in-

clude)

--with-libiberty-libdir LIBIBERTY library directory

--with-libiberty-incdir LIBIBERTY include directory

--with-libelf LIBELF directory (must contain ./lib and ./include)

--with-libelf-incdir LIBELF include directory

--with-libelf-libdir LIBELF library directory

--with-libdwarf LIBDWARF directory (must contain ./lib and ./in-

clude)

--with-libdwarf-incdir LIBDWARF include directory

--with-libdwarf-libdir LIBDWARF library directory

--with-dyninst DYNINST directory (must contain ./lib and ./include

--with-dyninst-libdir Directory to look for dyninst libraries

--with-dyninst-incdir Directory to look for dyninst headers

12 (18)

MATE

Environment variables

CC C compiler command

CFLAGS C compiler ﬂags

LDFLAGS Linker ﬂags, e.g. -L<lib dir> if you have libraries in a nonstan-

dard directory <lib dir>

LIBS Libraries to pass to the linker, e.g. -l<library>

CPPFLAGS (Objective) C/C++ preprocessor ﬂags, e.g. -I<include dir> if you

have headers in a nonstandard directory <include dir>

CXX C++ compiler command

CXXFLAGS C++ compiler ﬂags

6.2 Simple tunlet example

6.2.1 MPI application

# in cl ud e <mpi . h>

# in cl ud e < s t d i o . h>

# in cl ud e <u nistd . h>

# in cl ud e < s t d l i b . h>

i n t my_val = 1 ;

void hello_world () {

printf (" The r e p l a c i n g f u n ct i o n has worked ! ! \ n " ) ;

// I f we put t h es e two l i n e s , t he Analyzer

// w i l l e nt er t he f u nc t io n j u s t once

// MPI_Finalize ( ) ;

// e x i t ( 0 ) ;

}

void instr_function ( i n t value_to_change ) {

i f ( value_to_change == 1 )

printf (" [ INFO ] : Value not changed : %d\n" , value_to_change ) ;

e l s e {

printf (" [ INFO ] : Changed value to %d ! ! \ n " , value_to_change ) ;

}

i n t main ( i n t argc , char * * argv ) {

// I n i t i a l i z e th e MPI environment

MPI_Init (NULL, NULL) ;

// Get the number of p roc e s se s

int world_size ;

MPI_Comm_size (MPI_COMM_WORLD, &worl d_si ze ) ;

13 (18)

MATE

// Get the rank o f the pr oc es s

int world_rank ;

MPI_Comm_rank(MPI_COMM_WORLD, &world_rank ) ;

// Get the name of the p ro c es s or

char processor_name [MPI_MAX_PROCESSOR_NAME ] ;

int name_len ;

MPI_Get_processor_name ( processor_name , &name_len ) ;

// P r i n t of a h e l l o world message from each pr oc es s

printf (" Hello world from p roc es s or %s , rank %d out of %d p r o c esso r s \n " ,

processor_name , world_rank , world_si ze ) ;

while (tr u e ) {

instr_function (my_val) ;

}

// F i n a l i z e t he MPI environment .

MPI_Finalize () ;

}

6.2.2 Ctrl.cpp

# in cl ud e " C t r l . h "

# in cl ud e " Config . h "

# in cl ud e "DTAPI . h "

# in cl ud e " Syslog . h "

# in cl ud e " MyTunlet . h "

# in cl ud e <u nistd . h>

C o n t r o l l e r : : C o n t r o l l e r ( CommandLine & cmdLine , s td : : s t r i n g const & cfgFile )

: _cmdLine ( cmdLine )

{

// Read c o n f i g u r a t i o n from f i l e

_c fg = ConfigHelper : : ReadFromFile ( c f g F i l e ) ;

// Configure log

Syslog : : Configure ( _cf g ) ;

}

void C o n t r o l l e r : : Run ( ShutDownManager *sdm )

{

DTLibrary *l i b = DTLibraryFactory : : C r ea t eL i br a ry ( _c fg ) ;

MyTunlet mt ;

// C re at e t he a p p l i c a t i o n model

Model : : A pp li ca t io n & app = l i b −>C re a te A pp lic ati on (

_cmdLine . GetAppPath ( ) ,

_cmdLine . GetAppArgc ( ) ,

_cmdLine . GetAppArgv ( ) ) ;

// S et t he r e f e r e n c e to th e app i n th e sdm so i t can s to p t he ACs

sdm−>setApp ( app ) ;

// I n i t i a l i z e th e t u n l e t

mt . I n i t i a l i z e ( app ) ;

14 (18)

MATE

// S t a r t app

mt . BeforeAppStart ( ) ;

app . S t a r t ( ) ;

while ( app . G et St at us ( ) == s t S t a r t i n g && ! sdm−>i s F i n i s h e d ( ) ) {

i n t nEvents = app . ProcessE ven ts ( tr u e ) ; // Blocking

i f ( nEvents > 0)

Syslog : : Debug ( " [ C t r l ] P roce ssed %d e ven ts " , nEvents ) ;

sl ee p ( 1 ) ;

}

// Do nothin g i f t he user stopped th e a p p l i c a t i o n

i f ( ! sdm−>i s F i n i s h e d ( ) ) {

Syslog : : Debug ( " [ C t r l ] App i s running . . . " ) ;

Syslog : : Debug ( " [ C t r l ] Waiting f o r e ve nt s " ) ;

}

while ( app . Ge tS ta tu s ( ) == stRunning && ! sdm−>i s F i n i s h e d ( ) ) {

int nEvents = app . ProcessEv ent s ( t r u e ) ; // Blocking

i f ( nEvents > 0)

Syslog : : Debug ( " [ C t r l ] P roce ssed %d e ven ts " , nEvents ) ;

sl ee p ( 1 ) ;

}

Syslog : : Debug ( " [ C t r l ] A p pl ic at io n has f i n i s h e d " ) ;

// Destroy the t u n l e t

mt . Destroy ( ) ;

// Cleanup

DTLibraryFactory : : Destro yLi bra ry ( l i b ) ;

}

6.3 XFire example

6.3.1 Analyzer.ini

[Syslog]

MasterSwitch=true

LogLevel=0

StdErr=true

StdErrLogLevel=0

LogPath=$HOME/mpi/log

LogFile=Analyzer.log

AppendMachineName=true

AppendFile=false

Prefix=Analyzer

[Analyzer]

DisableTuningActions=true

15 (18)

MATE

[EventCollector]

Port =8800

6.3.2 AC.ini

[AC]

ACPath=</path/to/MATEs/AC>

DMLib=</path/to/MATEs/libDMLib.so>

PTPAcceptorPort=9900

[Analyzer]

Host=<host_name_or_ip>

Port=8800

[Syslog]

MasterSwitch=true

# LogLevel=0 writes all messages, LogLevel=1 writes

# only INFO messages

LogLevel=0

# Log only info level messages on std err

StdErrLogLevel=0

StdErr=true

LogFile=AC.log

LogPath=$HOME/mpi/log

AppendMachineName=true

AppendFile=false

Prefix=AC

6.3.3 Tunlet.ini

[global_sendreceive]

entry=FuncEntry

event=IterStart

source1=FuncParamValue

type1=Integer

id1=0

source2=VarValue

type2=Integer

id2=TheTotalWork

source3=VarValue

type3=Integer

id3=TheWorkSizeUnitBytes

source4=VarValue

type4=Integer

id4=NW

[Factoring_SetNumTuples]

16 (18)

MATE

entry=FuncEntry

event=NewBatch

source1=FuncParamValue

type1=Integer

id1=0

source2=FuncParamValue

type2=Integer

id2=1

[global_sendwork]

entry=FuncEntry

event=TupleStart

source1=FuncParamValue

type1=Integer

id1=0

source2=FuncParamValue

type2=Integer

id2=2

source3=FuncParamValue

type3=Integer

id3=4

[arcStepKernel]

entry=FuncEntry

event=CalcStart

source1=FuncParamValue

type1=Integer

id1=0

source2=FuncParamValue

type2=Integer

id2=1

6.3.4 DMLib.ini

[Syslog]

MasterSwitch=true

#LogLevel=0 writes all messages, LogLevel=1 writes only INFO messages

LogLevel=0

StdErr=true

StdErrLogLevel=1

LogPath=$HOME/mpi/log

LogFile=DMLib.log

AppendMachineName=true

AppendFile=false

Prefix=DMLib

17 (18)

MATE

References

[1] Dynamic instrumentation library. http://www.paradyn.org/html/dyninst7.

0-software.html. Accessed: 2018-06-08.

[2] Morajko A., Caymes-Scutari P., Margalef T., and Luque E. Mate: Monitoring, anal-

ysis and tuning environment for parallel/distributed applications. Concurrency

and Computation: Practice and Experience, 19(11):1517–1531, 2007.

[3] Anna Morajko, Oleg Morajko, Tomàs Margalef, and Emilio Luque. Mate: Dy-

namic performance tuning environment. In Marco Danelutto, Marco Vanneschi,

and Domenico Laforenza, editors, Euro-Par 2004 Parallel Processing, pages 98–107,

Berlin, Heidelberg, 2004. Springer Berlin Heidelberg.

[4] Anna Sikora. Dynamic Tuning of Parallel/Distributed Applications. PhD thesis, Uni-

versitat Autònoma de Barcelona, Barcelona, 2004.

18 (18)

MATE User's Guide Users

Navigation menu

Versions of this User Manual:

Views

Navigation