Marco Mancini Justo. línies. ELASTIC, Cluster, Computación de altas prestaciones, MRNet, MATE, Dyninst, Optimización guiada por plugins

Transcripción

1 TFG EN ENGINYERIA INFORMÀTICA, ESCOLA D ENGINYERIA (EE), UNIVERSITAT AUTÒNOMA DE BARCELONA (UAB) 1 Designing an Elastic Package: The plugin for ELASTIC, a dynamic tuning for large-scale applications framework Marco Mancini Justo Resumen Dentro de los esfuerzos para mejorar el desempeño de aplicaciones en clusters, el Departamento de Arquitectura de Computadores y Sistemas Operativos de la Escuela de Ingeniería de la UAB creó la herramienta ELASTIC. Esta herramienta permite monitorizar, analizar y sintonizar aplicaciones inyectando código en tiempo ejecución dentro de un cluster altamente paralelo sin una gran penalización por comunicaciones, a diferencia de todas las aplicaciones disponibles que cumplen esta tarea. Para poder tener una comunicación eficiente, ELASTIC crea una red de nodos con MRNet que le permite aplicar sus algoritmos de forma jerárquica en una red en árbol. ELASTIC necesita para poder cumplir sus cometidos plugins especializados para cada aplicación que va optimizar. De ésta manera, el programador tiene que darle la inteligencia a ELASTIC para que pueda monitorizar los elementos necesarios, analizarlos para saber cuándo actuar y saber cómo sintonizar el programa de la manera más adecuada. Este trabajo de fin de grado se aplica sobre el prototipo de ELASTIC que, pese a haber presentado resultados, necesita un trabajo de ingeniería del software para poder facilitar su uso a futuros usuarios. En este trabajo se especificará cómo se hace un ELASTIC PACKAGE (El plugin de ELASTIC) desde el punto de vista del programador. línies. ELASTIC, Cluster, Computación de altas prestaciones, MRNet, MATE, Dyninst, Optimización guiada por plugins Abstract Within the efforts to improve the performance of applications in clusters the department of computer architecture and operative systems of the engineering school of UAB built ELASTIC. This tool can do monitoring, analyzing and tuning of applications injecting code on execution time in a highly parallel cluster without a big overheat when the problem scales into the thousands of nodes. To mitigate the overheat of the communications, ELASTIC uses a network of nodes launched with MRNet that allows to executes it's algorithms in a tree based network. To achieve it's purpose, ELASTIC needs specialized plugins for every application it wants to optimize. That's because the programmer has to give his knowledge to ELASTIC in order to know what to monitor, how to analyze it and how to tune the application accordingly. This paper works on the ELASTIC prototype because, even if it proved it's viability, it lacks a proper documentation and a user's manual. Our objective is to ease the work of future programmers wanting to develop plugins for their programs to benefit from ELASTIC. This paper and further documents will specify how to build and understand the structure of an ELASTIC PACKAGE (plugin) from a programmers viewpoint. Index Terms ELASTIC, cluster, High performance computing, MRNet, MATE, DyinInst, Plugin driven optimization 1* E mail de contacte: marco.mancini@e campus.uab.cat 2* Menció realitzada: Enginyeria de Computadors 3* Treball tutoritzat per: Eduardo Cesar (Computer Architecture and Operating Systems Department) Curs 2014/15

2 2 EE/UAB TFG INFORMÀTICA: DESIGNING AN ELASTIC PACKAGE 1 INTRODUCCIÓN Este paper se basa en ELASTIC, una herramienta creada para optimizar aplicaciones dentro de entornos computacionales a gran escala. Esta herramienta se creó como un prototipo por lo que hacía falta un trabajo extra para que fuera posible usarlo en otros proyectos. Era necesario aplicar diseño del software a los Elastic Packages de tal manera que se minimizara el tiempo necesario para poder usar la herramienta en diferentes programas. Pese a ser un trabajo con una gran carga de diseño del software está dentro de la mención de ingeniera de los computadores por las características de la herramienta y el hecho de que es una herramienta puntera en el campo de la computación de altas prestaciones. En este trabajo me he encontrado con dos prototipos de ELASTIC y nula documentación, a partir de ahí he conseguido localizar y analizar las funcionalidades en las cuales participan los Elastic Packages. Con todo ello, he diseñado y refactorizado acordemente el código para facilitar la creación de Elastic Packages en el futuro. 1.1 Organización del documento El resto del documento sigue la siguiente organización: En la sección 2, Estado del Arte, hablaremos del contexto en el que nace la linea de investigación que ha dado lugar a ELASTIC y en qué situación se encuentra. En la sección 3, Objetivos, y 4, Metodología, se tratan las bases para éste Trabajo de Fin de Grado. En la sección 5, ELASTIC, se describe la herramienta y la arquitectura sobre la que se sustenta. En la sección 6, ELASTIC Packages, se describen de los plugins para la herramienta de tal manera que el programador pueda tener una referencia de su estructura. En la sección 7, Arquitectura funcional de ELASTIC, se expone la ejecución y función de la herramienta. En la sección 8, Resultados, se resume lo aprendido de ELASTIC y se detallan las funciones de los programadores en el desarrollo de ELASTIC Packages. La sección 9 será las Conclusiones, la 10 Agradecimientos y 11, Bibliografía 2 ESTADO DEL ARTE En el mundo de las aplicaciones de altas prestaciones el rendimiento y la eficiencia de los programas es un tema de capital importancia. Esto se debe a que los recursos utilizados son caros en cuanto a hardware y energía. Cualquier mejora en el rendimiento permite ahorrar centenares o incluso miles de euros por cada ejecución de un programa. Por ello, encontramos muchas lineas de investigación abiertas en diferentes universidades y centros de investigación que se dedican a crear herramientas que ayuden a los programadores a implementar aplicaciones que puedan ser ejecutadas en entornos de altas prestaciones de forma eficiente. Hoy en día hay varias herramientas para aumentar el rendimiento de aplicaciones de altas prestaciones. La mayoría de ellas se basan en el análisis del código y pruebas de ejecución para determinar si una aplicación es eficiente o puede ser mejorada. Hay herramientas que además aconsejan cómo mejorar la aplicación. Este trabajo se centra en un herramienta que hace análisis/sintonización modificando parámetros para poder optimizar a tiempo real la ejecución de una aplicación sin tener que recompilarla. Esto es importante porque cubre un nicho de aplicaciones que otras herramientas no pueden tratar, como son las aplicaciones que en cada ejecución pueden evolucionar de forma distinta a partir de los valores de inicio. Éstas aplicaciones necesitan crear un sistema de evaluación y optimización para cada aplicación teniendo en cuenta cómo puede evolucionar y los parámetros que se quieren optimizar. ELASTIC permite tener una herramienta generalista para que el programador no tenga que crear un sistema de optimización entero, sino que tan sólo con adaptar un plugin a sus necesidades sea suficiente para poder optimizar su aplicación. Además, está especialmente adaptada para entornos con un gran numero de nodos. Se basa para ello en una red jerárquica. Mediante un sistema de resumen de la información permite que un solo nodo llegue a tener una visión general de una aplicación a gran escala sin sobrecargar la red.

3 AUTHOR ET AL.: MARCO MANCINI JUSTO 3 Hay varias aplicaciones que hacen un análisis automático y pueden trabajar en entornos con un gran numero de elementos; véanse, por ejemplo, Paradyn [1], Scalasca [2], TAU [3] y Periscope [4]. Sin embargo, ninguna de ellas está orientada al análisis/sintonización de las aplicaciones en tiempo de ejecución. Por ello se creó dentro de DACSO (Departamento de Arquitectura de Computadores y Sistemas Operativos) un grupo de investigación en herramientas de sintonización automática/dinámica de aplicaciones paralelas basadas en plugins. Los resultados de este grupo de investigación han sido: ( 2004 MATE [5] ) Herramienta de análisis/sintonización centralizada. Ésta herramienta fue la predecesora de ELASTIC. En ella se usa DynInst [7] para poder monitorizar, analizar y sintonizar aplicaciones mediante la inyección de código en tiempo de ejecución. ELASTIC aprovecharía gran parte de este programa y lo mejoraría utilizando MRNet [8] puesto que en MATE, cuando el volumen de nodos escalaba demasiado, el rendimiento se veía muy comprometido por la sobrecarga en las comunicaciones. ( 2012 ELASTIC [6] ) Herramienta análisis/sintonización distribuida de forma jerárquica. Utilizando los dos prototipos que se crearon para hacer la prueba de concepto se ha preparado el diseño general de los ELASTIC Packages. 3 OBJETIVOS El objetivo final de este trabajo de fin grado (TFG) es definir, diseñar e implementar la interfase para la definición de los plugins (ELASTIC Packages) de la herramienta. El prototipo de ELASTIC debería tener diferenciado de forma teórica por una parte el programa ELASTIC, que es el que provee de todas las herramientas para instrumentalizar un programa y optimizarlo en un cluster con un esfuerzo razonable y, por otra, los ELASTIC Packages. El único esfuerzo del equipo que quiera optimizar su implementación con ELASTIC tendría que ser la creación de los ELASTIC Packages. Son pequeños plugins que contienen todo el conocimiento del equipo que ha diseñado el programa a optimizar. Adjuntándolos a ELASTIC, éste último tendría todo lo necesario para mejorar la eficiencia del programa que está siendo instrumentalizado. En este TFG se encontrará cómo está asociado el modulo que hace de plugin en las implementaciones que se hicieron como prueba de concepto. Después se refactorizará el programa para poder separar de ELASTIC lo que supondrá el modulo del Elastic Package. 4 METODOLOGÍA Para este Trabajo de Fin de Grado (TFG) he aplicado una metodología en cascada. Las primeras dos entregas de informes estaban dedicadas al análisis del entorno (MRNet, dyninst) y luego de ELASTIC para poder luego poder diseñar y implementar los ELASTIC Packages. Esta metodología en cascada se cumplió durante el tiempo de análisis hasta que se llegó a la parte de analizar con detenimiento ELASTIC. Subestimé el tiempo necesario para poder comprender todo el código y sus funciones puesto que pese a desde un principio ser la parte principal del trabajo no fue suficiente. El problema principal fue sin duda la falta de documentación y la inconsistencia de los comentarios. La etapa de diseño entonces se retrasó más de lo esperado, haciendo que el objetivo final de llevar a cabo las pruebas funcionales se retrasara. Se ha hecho una implementación, refactorizando el código para tener separado el código de los Elastic Packages del resto de ELASTIC. Pero las pruebas funcionales quedaron fuera del tiempo del proyecto. 5 ELASTIC ELASTIC implementa una mejora vital a su predecesor MATE en que puede aplicarse sobre una ejecución a gran escala. MATE tenía un nodo central que era el encargado de recibir toda la información de los nodos, analizarla y enviar las ordenes de sintonización para corregir lo que el programador hubiera previsto necesario. Este acercamiento tiene un punto débil. Cuando el entorno escala mucho en nombre de elementos la comunicación con el nodo

4 4 EE/UAB TFG INFORMÀTICA: DESIGNING AN ELASTIC PACKAGE supervisor se convierte en un cuello de botella. Por ello, ELASTIC implementa una red de nodos supervisores que se distribuyen en capas para paralelizar sus funciones. Para poder llevar a cabo esto sin que a su vez la red de supervisores sea un cuello de botella, crean una abstracción del programa como se ve en la figura 1. La segunda y más importante es la paralelización de la comunicación, eliminando la necesidad de enviar toda la información a un nodo. Así pasando a tener un número escalable de nodos, los cuales se intercambian información entre sí. Esto se hace a cambio de utilizar más recursos y enviar más mensajes. Esto es debido a que hay más procesos extra de análisis. Además la abstracción y traducción generan una cantidad extra de mensajes. Pese a esto, en la tesis sobre ELASTIC se demuestra que la mejora en el rendimiento hace que los costos sean perfectamente asumibles. Figura 1, representación de la red jerárquica de supervisores. Los nodos que están en contacto con la aplicación real recogen los datos de ésta, los analizan y hacer una abstracción. La forma de abstraer los datos es algo que elige el programador dependiendo de la información importante que se puede extraer de un grupo de eventos de diferentes nodos. La información resumida es enviada a la capa superior donde a su vez es resumida y enviada a la capa superior hasta que llega a una capa final, la cual tendrá una visión de toda la ejecución. Lo cual hace que el nodo que tiene la información de toda la ejecución tenga una carga mucho menor de comunicación que su equivalente en MATE. Una vez un nodo detecta que la ejecución debe ser optimizada crea eventos en forma de órdenes de sintonización que empiezan a bajar en la jerarquía propagándose a todos los hijos del nodo que ha dado la orden. Hasta que dichas ordenes llegan a los nodos en contacto con la aplicación real que envían las ordenes de sintonización a la aplicación. Este paradigma tiene dos ventajas importantes respecto a su predecesor: La primera, es que hay una paralelización del trabajo de análisis, permitiendo que se pueda hacer un análisis más potente sin que repercuta en exceso en el tiempo extra de ejecución. 5.1 Estructura interna de la jerarquía FE (Front End) Son los nodos de jerarquía más alta, siendo los más alejados de la información de la aplicación real. CP (Middle Node) Son los nodos intermedios. Tienen padres y a la vez hijos, siendo los dos virtuales. Por lo que tienen que abstraer y traducir información dentro de la jerarquía pero no hablan directamente con la aplicación real. BE (Back End). Son los nodos de jerarquía más baja. Son los más numerosos y son los que están en contacto con la aplicación real. Abstractor ATM. El Abstractor se encarga de sintetizar la información para luego transmitirla a los nodos de jerarquía superior. El ATM, por el contrario, se encarga de dar las ordenes de sintonización a la jerarquía inferior. Figura 2, Esquema de jerarquía de comunicación

5 AUTHOR ET AL.: MARCO MANCINI JUSTO 5 6 ELASTIC PACKAGE 6.1 Funciones de los EP Monitorización La monitorización es el proceso mediante el cual ELASTIC puede recolectar información de variables de la aplicación que quiere optimizar. Estas variables no las escoge ELASTIC sino el programador de la aplicación a optimizar. Este elige cuáles son las variables que necesitará ELASTIC para poder llevar a cabo un análisis sobre el estado de la aplicación. Usando la API de DMLib el programador puede hacer que cuando ELASTIC lance la red de supervisores mediante MRNet inyecte código dentro de la aplicación. De tal manera que las variables que el programador ha decidido se envíen mediante una conexión de sockets a los nodos BE. En el caso de los nodos CP y FE la etapa de monitorización se lleva a cabo de la misma manera que en el BE. Exceptuando la inyección código dentro de la aplicación, puesto que los nodos CP y FE recibirán su información de la aplicación virtual. Todas las variables entre nodos se transmiten mediante un paso de mensajes. La aplicación, ya sea la real o la virtual, genera eventos que contienen las variables a monitorizar y un timestamp. Luego cada nodo recogerá de su pool de eventos cada evento y extraerá la información que luego será analizada. 6.2 Funciones de los EP Análisis Cada nodo, ya sea un BE, un CP o un FE analiza los datos que le llegan. Todos aplican un algoritmo decidido por el programador de la aplicación que será el encargado de comprobar si la ejecución se está desarrollando como se prevee. En caso contrario y dentro de los parámetros que haya especificado el programador se lanzará una orden de sintonización para arreglar el problema que haya surgido. 6.3 Funciones de los EP Tuning Cada nodo puede generar una orden de tuning después de analizar su pool de eventos. Esta orden es un imperativo para aplicar algún cambio al programa, tal como pasar una variable a una función de la aplicación, crear, mover y/o eliminar threads o cambiar parámetros de ejecución. Estas ordenes se pueden dar en todos los niveles, por lo cual el primer supervisor en encontrar un problema dará ordenes a sus subordinados para arreglarlo. Estos eventos de tuning se propagarán por la jerarquía hasta llegar a la aplicación real y activarán un protocolo de tuning. El programador será el encargado de definir e implementar el protocolo de tuning que se inyectará en la aplicación para optimizarla. 6.4 Funciones de los EP Abstraer/Traducir ELASTIC crea una red en árbol de supervisores. Para ser eficiente, cada nivel del árbol abstrae o concreta la información que dispone para poderla mover dentro del árbol sin crear una sobrecarga en la comunicación. Las etapas de monitorización y tuning, pese a que no se ha especificado antes, requieren en gran medida de este proceso. La monitorización empieza con eventos que provienen de la aplicación real. Cada nodo a su vez abstrae la información, creando un resumen que envía a la jerarquía superior. A medida que subimos en la jerarquía cada evento representa la información en un conjunto mayor de nodos. Para llevar a cabo la abstracción, el programador tiene que definir un algoritmo que resuma la información de cada nivel. El evento resultante será enviado al pool de eventos del supervisor del nodo. Los eventos de tuning pueden ser generados en cualquier nodo por lo que, cuando un eventos de tuning se genera en un nodo que no tiene contacto con la aplicación real, tiene que ser traducido. Dicha traducción será enviada a los nodos que cuelgan de éste. La traducción sigue un algoritmo que será definido por el programador. Dicho algoritmo reparte las ordenes que ha generado un nodo a sus N hijos. Estas órdenes se propagarán por la aplicación, saltando de un pool de eventos de ordenes de tuning a otro. Cuando finalmente llegan al pool de un BE, no se traducirá más y se aplicará la orden de tuning a la aplicación real. 7 ARQUITECTURA DE UN ELASTIC PACKAGE La ejecución de ELASTIC está guiada por sus plugins y por ende por el programador. En esta sección se explicará de qué etapas está compuesta la ejecución de ELASTIC en las cuales el

6 6 EE/UAB TFG INFORMÀTICA: DESIGNING AN ELASTIC PACKAGE programador tiene que decidir qué se tiene que hacer y cómo. La primera etapa es la inicialización. INIT Dentro de la inicialización hay varias etapas que el programador tiene que concretar. 1. Ejecutar la aplicación: El programador tiene que especificar dentro de ELASTIC y en su script de lanzamiento el programa a instrumentalizar. 2. Creación de la red de MRNet: Para esta etapa el programador tiene que especificar el número de nodos supervisores y el tamaño de cada capa. Los parámetros se pueden especificar en el script de lanzamiento. 3. Instrumentalización con DMlib y DynInst: Una vez la red está creada, ELASTIC iniciará la inyección de código para empezar a monitorizar. Para ello el programador tiene que definir qué variables del programa han de ser monitorizadas. Con este fin existe la API de DMlib que ofrece una serie de funciones para poder hacer la inyección de las variables elegidas por el programador. Cuando la aplicación esté instrumentalizada y funcionando, empezará periódicamente a enviar eventos que se acumularán en el pool de eventos de cada nodo BE. A partir de aquí podemos dar por finalizada la etapa de inicialización y empieza el flujo principal. La etapa principal está orquestada por la función Check_Execution. Dicha función se encarga de coordinar las distintas tareas que se llevan a cabo en cada nodo. El flujo de datos entre las tareas se puede observar en la figura Monitor: El pool de eventos se va llenando, por lo que periódicamente Check_Execution llama a una función creada por el programador con el objetivo de extraer la información dentro de los eventos para poder ser analizada. Para más información sobre los eventos en el anexo se explican con detalle las propiedades de la clase event y eventrecorder que son las que el programador tendrá que tratar para poder extraer la información del pool. 2. Analyze: La información extraída de los eventos es enviada a una función de análisis que retornará si hay algún problema o no. Esta función contiene un algoritmo hecho por el programador para que ELASTIC pueda decidir en función de la información de los eventos si hay que hacer tuning en la aplicación o no. Idealmente el algoritmo debería cumplir tres funciones: La primera, poder evaluar la desviación del estado de la ejecución actual frente a una ejecución ideal. Segunda, tener un rango de valores de desviación eficientes. Esto es debido a que un rango que se active demasiado a menudo provocaría una sobrecarga de ordenes de tuning. Por otro lado si las ordenes de tuning se generan en casos muy contados es muy probable que la propia ejecución de la monitorización y análisis de ELASTIC provoque una sobrecarga en la ejecución. Y tercera, poder generar no solo el aviso de que hay un problema sino además tener varios escenarios identificados dependiendo de las características de las desviación. Con el objetivo de poder tener protocolos de tuning distintos para casos distintos. Figura 3, Esquema del flujo de datos entre los módulos de Check_Execution

7 AUTHOR ET AL.: MARCO MANCINI JUSTO 7 Se haya detectado un problema o no en la información que se ha analizado, si el nodo que lo ha hecho es un BE o un CP debe abstraer la información a sus supervisores. Para ello, el programador tiene que implementar un algoritmo que resuma la información que acaba de ser analizada. En el anexo se explican un poco las funciones y estructuras de datos que necesitará el programador para llevar a cabo la abstracción. Dicho algoritmo no tiene restricciones desde el punto del entorno pero debería tener en cuenta dos aspectos: Uno, el volumen del resumen. Idealmente debe tener el tamaño mínimo para no sobrecargar la red de comunicación, a la vez que genera un evento que permita a los supervisores tener una visión general de la aplicación de forma eficiente. Dos, el tipo de evento que genera el Abstractor. Se puede generar un nuevo tipo de variable dependiendo de si está hablando de la aplicación real o de una aplicación virtual. Esta consideración es importante porque en el caso de cambiar el tipo de variable habría que añadir casos especiales dependiendo del tipo de nodo que esté observando el pool. 3. Tuning: En el caso de que la función Analyze retorne un valor que indique que hay un problema. Check_Execution activará la función de tuning para que se encargue de generar una orden de tuning. El programador tiene que especificar el algoritmo para optimizar la aplicación. Para llevar a cabo el tuning ELASTIC inyectará instrucciones dentro de la aplicación basándose en la API de Dmlib, por lo que las acciones están limitadas. Para más información el anexo Task Class contiene los métodos que se pueden utilizar para hacer tuning. Por último comentar que las ordenes solo actuarán sobre la aplicación real en el caso de que sea el BE quien lleve a cabo la orden de tuning. En los demás tipos de nodos se llamará a Translator. 4. Translator: Cuando hay ordenes de tuning en el pool, si están en un nodo CP o FE estas órdenes se tienen que transmitir a los nodos subordinados para que se propague dentro de la jerarquía. Para ello el programador tiene que definir un algoritmo para propagar las ordenes de tuning. Consideraciones que hay que tener sobre este aspecto: Como se está enviando ordenes a todos los hijos, es vital utilizar las funciones que provee ELASTIC para los nodos extraigan información de sus hijos de tal manera que se pueda repartir las ordenes de forma precisa. Para más información en el anexo hay una añadido sobre estas funciones de ELASTIC. 8 RESULTADOS Los objetivos de este trabajo eran por una parte definir una interfaz para que el usuario de ELASTIC pudiera usarlo con facilidad (mediante los EP) y, crear una versión funcional en la cual estuviera un EP claramente definido. Sobre ELASTIC dividiría lo obtenido en, por un lado, la lógica de análisis y, por otro, la monitorización e instrumentalización. El módulo análisis, junto con el paso de mensajes entre los diferentes supervisores, fue una de las prioridades puesto que esto era la principal aportación que se había hecho con ELASTIC. La monitorización y tuning con el programa, sin embargo, es algo que se conserva de MATE ya que utiliza la API de Dmlib para llevarlo a cabo. Se hizo una clasificación de los diferentes archivos que formaban ELASTIC para saber cuales pertenecían enteramente a MATE, cuáles se habían editado para crear ELASTIC y, por último, cuáles se habían editado para generar las diferentes versiones. Se refactorizó el código para poder separar la lógica de análisis que el programador tendría que definir del resto de ELASTIC al crear los EP. Después de hacer la experimentación se iban a refactorizar los elementos necesarios para monitorizar e instrumentalizar. Pero se consideró mejor centrarse en el análisis y la comunicación entre los diferentes niveles de los nodos dicha experimentación quedó fuera del tiempo del proyecto por las dificultades añadidas en la experimentación al tener que hacerlo en cluster del CRAG [9]. 9 CONCLUSIONES Este trabajo de fin de grado pertenece a una linea de investigación del DACSO, por lo que una de las prioridades al cerrar este trabajo es documentar todo lo aprendido y generar una

8 8 EE/UAB TFG INFORMÀTICA: DESIGNING AN ELASTIC PACKAGE manual del programador para ayudar a los investigadores futuros a trabajar con ELASTIC y disminuir el tiempo de aprendizaje que necesiten para poder implementar mejoras en ELASTIC. Dentro del trabajo futuro que hay que hacer en la aplicación es prepararla completamente para poder usar en aplicaciones reales. La línea de trabajo futura debería ser en orden: Acabar la implementación de los EP con pruebas funcionales. Crear EP para poder atajar gran variedad de situaciones y generalizar el código junto con hacer un trabajo de estilo para arreglar todos los problemas de inconsistencias de comentarios, de nombres de funciones y cableado en el código. Aplicar la ingeniería del software al resto de ELASTIC como se aplicó en MATE para tener una estructura mucho más clara para mejoras que se quieran hacer al código principal de ELASTIC. Subir a un repositorio junto con tutoriales de uso y una serie de ejemplos para minimizar el tiempo de aprendizaje. Applications PhD dissertation, Dept. Informática., UAB., Bellaterra, Spain., [6] A, Martinez. Dynamic Tuning for Large Scale Parallel Applications PhD dissertation, Dept. Of CAOS., UAB., Bellaterra, Spain., [7] Dyninst Programmer's Guide Release 8.1 Paradyn Tools Project, [8] MRNet API Programmer's Guide. Release Paradyn Tools Project, [9] J, Navarro. G, Vera. Integrating Computational Resources between CRAG and HPCA4SE CRAG., UAB., Bellaterra, Spain., [10] Royce, Winston. "Managing the Development of Large Software Systems p/process/waterfall.pdf Retrieved 15 October [11] N, Fernandez. Aplicación de la ingeniería del software sobre la herramienta MATE: Common y DMLib Bsc dissertation, Dept. of CAOS., UAB., Bellaterra, Spain., [12] R, Echeverría. Aplicación de la ingeniería software sobre la herramienta MATE Analyzer Bsc dissertation, Dept. Of CAOS., UAB., Bellaterra, Spain., Anexo 10 AGRADECIMIENTOS A Eduardo Cesar por tener paciencia para escuchar mi montaña de dudas y teorías detectivescas. 11 BIBLIOGRAFIA [1] Official Paradyn website, last check january 2015 [2] G,Michael Gerndt, Periscope Tuning Framework: Automatic Performance Engineering for HPC PPE/Periscope%20Tuning%20Framework.pdf Retrieved 25 january 2015 [3] TAU (Tuning and Analysis Utilities) website, hp last check january 2015 [4] Official Scalasca website, checked january 2015 [5] A, Morajko Dynamic Tuning of Parallel/Distributed A1. CLASES DE LA API DE DMLIB Esta lista propiedades proviene de la tesis de MATE. Las siguientes clases son las que componen la API de DMlib. Application class Properties Name name of the running program NumActiveTasks number of tasks actually running Tasks a collection of Task objects Hosts a collection of Host objects that form the virtual machine MasterTask references the master task of the application Status application status information MonitoredEvents collection of events being monitored in all the tasks Methods Start executes the application AddEvent adds a definition of new event to be traced in all running tasks of the application

9 AUTHOR ET AL.: MARCO MANCINI JUSTO 9 RemoveEvent removes previously added event from all running tasks LoadLibrary load a shared library to all running tasks UnloadLibrary removes a previously loaded shared library from all running tasks SetVariableValue modifies a value of a specified variable in a given set of tasks ReplaceFunction replaces all calls to a function with calls to another one in a given set of tasks InsertFunctionCall inserts a new function invocation code at a given location in a given set of tasks InsertOneTimeFunctionCall inserts a new function invocation code in a given set of tasks and calls it once FunctionParameterChange sets the value of an input parameter of a given function in a given set of tasks RemoveFunctionCall removes all calls to a given function from the given caller function in a given set of tasks Callbacks SetTaskHandler installs a callback function that is called when a new task is started or existing one is terminated SetHostHandler installs a callback function that is called when a new host is added to the virtual machine or an existing one is removed Task class Properties Id globally unique task id Name process name FilePath file path of the task image Host reference to the host object this task is running on IsRunning indicates if the task is still running Status task status information MonitoredEvents collection of events being monitored in this tasks TuningActions a collection of tuning actions performed in this task Methods AddEvent adds a definition of new event to be traced in this task RemoveEvent removes previously added event from this task LoadLibrary load a shared library to this task UnloadLibrary removes a previously loaded shared library from this task SetVariableValue modifies a value of a specified variable in the running task ReplaceFunction replaces all calls to a function with calls to another one in this task InsertFunctionCall inserts a new function invocation code at a given location in this task InsertOneTimeFunctionCall inserts a new function invocation code in this task and invokes it once FunctionParameterChange sets the value of an input parameter of a given function in this task RemoveFunctionCall removes all calls to a given function from the given caller function in this task Callbacks SetTaskExitHandler installs a callback function that is called when this task terminates Event class Properties Id globally unique event id FunctionName name of the function this event is associated to InstrPlace function entry or exit NumAttributes number of event attributes Attributes a collection of attributes to be recorded with this event Callbacks SetEventHandler installs a callback function that is called each time a record of this event is delivered Attribute class Properties Source indicates source for attribute value (i.e. constant value, function parameter value, variable value, function return value) ValueType data type of the attribute value (i.e. integer, float, etc.) SourceId identifies the object to be used as a source (i.e. variable name, function name to be called, index of function parameter) EventRecord class Properties EventId globally unique event id Event references event object this record is associated to Timestamp indicates when the event happened Task references a task that generated this event

10 10 EE/UAB TFG INFORMÀTICA: DESIGNING AN ELASTIC PACKAGE AttributeValues a collection of recorded attribute values EventHandler class Methods HandleEvent called to handle an event record TaskHandler class Methods TaskStarted called when a new task is started TaskTerminated called when a task is terminated HostHandler class Methods HostAdded called when a new host is added to the virtual machine HostRemoved called when a host is removed from the virtual machine Por último comentar que en el proceso de abstracción cuando se envía la información a los nodos de jerarquía más alta entra en juego una función que crea un evento virtual y lo envía. PacketPtr parent_packet(newpacket(cur_packet- >get_streamid(), cur_packet->get_tag(), "%d %d %d %ld %d", state->rank_comm, id_event, id_iteracion, mean_iter_time, total_agents)); packets_out.push_back( parent_packet ); Siendo en este ejemplo mean_iter_time una variable resumen utilizada en uno de los prototipos de ELASTIC. Por otro lado con el evento creado parent_packet la linea final lo envía al pool de eventos del padre del nodo actual. A2. FUNCIONES DE AYUDA PARA CREAR UN EP ELASTIC al usar una arquitectura distribuida de los nodos necesita varias funciones que den información sobre la red. Un parámetro muy importante es en qué nivel de la jerarquía se encuentra el nodo actual. Para conseguir esto hay una estructura de datos que contiene toda la información de la red por lo que después de hacer las siguientes operaciones. //Get NET Network* net = const_cast< Network*>( topolinfo.get_network()); //Get information about the node bool is_be = net->is_localnodebackend(); bool is_fe = net->is_localnodefrontend(); bool is_cp = net->is_localnodeinternal(); Cada nodo tendrá los flags, is_be, is_fe y is_cp que le servirán para saber dónde se encuentra. De la estructura net se puede extraer información sobre la red. Como por ejemplo la cantidad de hijos que tiene un nodo.