ParserOTF.tex 5.27 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
%% This file is part of the ViTE project.
%% This software is governed by the CeCILL-A license under French law
%% and abiding by the rules of distribution of free software. You can
%% use, modify and/or redistribute the software under the terms of the
%% CeCILL-A license as circulated by CEA, CNRS and INRIA at the following
%% URL: "".
%% As a counterpart to the access to the source code and rights to copy,
%% modify and redistribute granted by the license, users are provided
%% only with a limited warranty and the software's author, the holder of
%% the economic rights, and the successive licensors have only limited
%% liability.
%% In this respect, the user's attention is drawn to the risks associated
%% with loading, using, modifying and/or developing or reproducing the
%% software by the user in light of its specific status of free software,
%% that may mean that it is complicated to manipulate, and that also
%% therefore means that it is reserved for developers and experienced
%% professionals having in-depth computer knowledge. Users are therefore
%% encouraged to load and test the software's suitability as regards
%% their requirements in conditions enabling the security of their
%% systems and/or data to be ensured and, more generally, to use and
%% operate it in the same conditions as regards security.
%% The fact that you are presently reading this means that you have had
%% knowledge of the CeCILL-A license and that you accept its terms.
%% ViTE developers are:
%%        - COULOMB Kevin
%%        - FAVERGE Mathieu
%%        - JAZEIX Johnny
%%        - LAGRASSE Olivier
%%        - MARCOUEILLE Jule
%%        - NOISETTE Pascal
%%        - REDONDY Arthur
%%        - VUCHENER Clément 


The OTF format is an open format. Moreover, the OTF library provides tools to convert Vampir'\url{} or Tau(\url{}) traces which are some of the most common used trace format.
An API is also provided in order to read the files.

More details can be found at \\\url{} (in english or deutsch).

The OTF parser uses two parsers like the Paj\'e one.
We decided to separate the definitions from events for a better scalabity.
Moreover, we use the provided API to parse the files because it is a portable interface.

\subsection{Supported functions}
Because they are optional and do not have a direct correspondance with the Paj\'e format, we do not handle the following functions~:
\item \textit{Definition, event, snapshot and summary Comments}.
\item \textit{DefCreator}.
\item \textit{Collective operation}.
\item \textit{Snapshots}.
\item \textit{Summaries}.
Also we do not take in account the streams in optional fields.

In the future we could consider that snapshots are events.

\subsubsection{Correspondances and differences between this format and the Paj\'e one}

The genericity of the Paj\'e format is very useful because we do not need to create other classes for the trace.

So, a process will be designed as a container in Paj\'e format.
A process group will be considered as the container type in order to keep the Paj\'e format. If a process does not belong to a process group, we assign it to the empty process group (the 0). However, a process can belong to more than one process group. We do not handle this case and only consider that the first one found is the process group.

A function will be an event and its function group will be the EventType.

A counter will be a variable and a counter group the VariableType.

A message will be a link. Its value will be~: "sender\_name to receiver\_name" because there are no message value in the OTF format.

\subsection{Definition Parser}

This parser stores all the OTF objects (process, functions...).
In order to do it, we use the provided API which uses handlers. 

Variables in the ParserDefinition are static because this is the only way to handle handlers.

While parsing, we only store each component. At the end of it, we create all the ContainerType. We can not create the EventType or VariableType because we do not know in which kind of process the event or the variable is used.

\subsection{Event Parser}
Due to the optionnality of the process creation, we have to check before each event or counter catched that the container exist.

Now that we know which kind of process uses the event or counter, we can create the eventType or variableType if they do not exist.
Because of the fact that if an event does not exist, it is automatically created by the trace, we can not add the optional fields like source file or color. In order to pass through it, we added a boolean attribute to the function structure which says if the function has already been defined.

For the counter, we are not sure that the sender has an ancestor. If it is not the case, we consider that the ancestor is also the sender.

The handling of the remaining time is in the EventParser too. Because we consider (good consideration?) that reading the definitions is done faster than reading the events, we only take the time for events to compute the remaining time.