Tecnológico de Monterrey Campus Querétaro

Transcripción

1 Tecnológico de Monterrey Campus Querétaro Rectoría Zona Centro Dirección de Ingeniería y Arquitectura Departamento de Sistemas Computacionales paradis: Un framework de ejecución distribuida de código secuencial Proyecto Integrador de Tecnología Computacional Autores: Director: Luis Héctor Chávez Freire Paola Lorena Ruiz González Jorge A. Torres Jiménez Querétaro, México, 30 de noviembre de 2010.

2 DASL4LTD Research Group [C-QRO-17/07] The Distributed and Adaptive Systems Lab for Learning Technologies Development paradis: Un framework de ejecución distribuida de código secuencial Deliverable Identifier: T1 Authors: Luis Héctor Chávez Freire Paola Lorena Ruiz González Delivery Date: 5 December 2010 Start Date: 17 August 2010 Duration: 4 months Deliverable Coordinator: Jorge Torres Classification: Public Circulation Querétaro, México, 30 de noviembre de 2010.

3 Resumen En años recientes, se han hecho múltiples esfuerzos para crear nuevos modelos de cómputo que permitan expresar de una mejor manera los programas, permitiéndole al desarrollador esforzarse más en crear mejores soluciones a sus problemas específicos y menos en todo lo demás. Estos modelos generalmente introducen una restricción en el tipo de problemas que pueden resolver, pero facilitan el resto del desarrollo. Uno de los problemas más difíciles en el área del cómputo científico es el de hacer uso eficiente de los recursos computacionales. Actualmente, la tendencia mundial busca dejar de construir máquinas más poderosas, y en su lugar utilizar una gran cantidad de computadoras de propósito general. Esta tendencia obliga a los desarrolladores a hacer uso del cómputo paralelo y distribuido. paradis busca cambiar este paradigma, creando un entorno de ejecución de paralelización y distribución semi-implícita, permitiendo ejecutar un script de JavaScript arbitrario de manera distribuida. Utilizando heurísticas obtenidas en tiempo de ejecución y pistas en forma de llamadas a funciones del entorno de ejecución, se separará el trabajo para aprovechar al máximo el poder de cómputo.

4

5 Índice general Índice general Índice de figuras Índice de tablas v vii ix 1. Introducción Contexto del problema Motivación del trabajo de investigación Objetivos del trabajo de investigación Hipótesis Metodología de Investigación Dominio del problema Estructura del documento Estado del arte Cómputo Distribuido Globus Toolkit: Infraestructura homogénea para cómputo distribuido BOINC: El poder de una super - computadora al servicio de tu proyecto Condor, en búsqueda del alto rendimiento Map - Reduce: La opción de Google para cómputo distribuido. 14 v

6 Dryad: cómputo distribuido para datos paralelos Windows Azure: Cloud Computing como servicio Lenguajes de Programación Programación Funcional Lenguajes Scripting Closures Continuaciones Planteamiento del problema Identificación de segmentos distribuibles del código Distribución de tareas entre distintos nodos de cómputo Reintegración del contexto Resolución de conflictos Propuesta de solución Modelación del problema y decisiones de diseño Fragmentación del código en Closures Distribución de tareas Algoritmo de reintegración del contexto y detección de conflictos Evaluación Plan de Evaluación Resultados de la Evaluación Conclusiones y trabajos futuros Conclusiones Trabajos Futuros A. Mejores prácticas para maximizar la paralelización 51 B. Manual de Usuario 55 vi

7 Índice de figuras 2.1. Arquitectura de Globus Toolkit Operación de MapReduce La Plataforma de Windows Azure, su soporte para aplicaciones, datos y su infraestructura en la nube junto con el marketplace Dos ejemplos de estructuras de programas Gráfica de tiempo registrados para la ejecución con distintos números de computadoras de uso común Screenshot de una ejecución de paradis B.1. Screenshot de la interfaz de paradis vii

8 viii

9 Índice de tablas 5.1. Ejecuciones en paradis con diferentes cantidades de máquinas ix

10 x

11 Fragmentos de código 1. Ejemplo de la implementación de un Closure en JavaScript Ejemplo de la implementación de una continuación en Phyton Ejemplo sencillo de código paralelizable en JavaScript Transformación estructural de ciclos en paradis Ejemplo de un código JavaScript altamente paralelizable xi

12 xii

13 Capítulo 1 Introducción 1.1. Contexto del problema La posibilidad de resolver problemas complejos por medio de una computadora es una de las razones por las cuales las ciencias de la computación y las tecnologías de información han ganado popularidad en los centros de investigación y universidades en los últimos años. La búsqueda de mejores soluciones y técnicas que nos permitan hacer más grande nuestra capacidad de resolver problemas, así como poder solucionar un mayor número de ellos de manera automática ha sido creciente. A pesar de estos esfuerzos, existen algunos problemas que son intrínsecamente complejos y requieren de una gran cantidad de recursos computacionales, esto representa un nuevo reto para los desarrolladores y científicos de la computación. Para poder identificar estos problemas existen formalismos y técnicas que nos ayudan a medir su complejidad, así como la posibildad de resolverlos en un tiempo considerable; nos referimos a la teoría de complejidad, una rama de las ciencias de la computación y matemáticas que se enfoca en clasificar todos los problemas computacionales de acuerdo a su dificultad inherente[?]; por medio de esta clasificación podemos saber a priori si existe un algoritmo que nos permita resolver una clase de problemas usando una cantidad razonable de recursos. Dado que la capacidad de una sola computadora es limitada, en años recientes, se ha popularizado una técnica que consiste en reunir la capacidad de cómputo de va- 1

14 Contexto del problema rias máquinas para hacerlas trabajaren conjunto y de esta manera poder resolver un mismo problema: esto se conoce como cómputo distribuido. Hay dos tipos principales de cómputo distribuido, el clúster y el grid. El clúster consiste en varias computadores similares físicamente conectadas entre sí por medio de una red de alta velocidad. Muchas de las supercomputadoras más potentes de hoy en día están construidas usando este modelo 1. El grid, por otro lado, no requiere que las computadoras estén conectadas entre sí, y generalmente posee recursos más heterogéneos, en el sentido de que ni si quiera es necesario que una misma organización tenga control administrativo de todas las computadoras. El proyecto SETI@Home 2 es un ejemplo de este paradigma. Existen muchas aplicaciones del cómputo distribuido (e.g. doblamiento de proteínas [?], rasterización de imágenes fotorrealistas [?] o búsqueda de información en internet [?]) que requieren una gran cantidad de procesamiento para poderse completar en un tiempo razonable 3. Para evitar que cada proyecto que necesite hacer uso del cómputo distribuido tenga que crear su propia implementación de las herramientas básicas (como son la división de tarea, la comunicación entre nodos, la transferencia de información entre ellos, etc.), se han creado frameworks para que los programadores construyan sus aplicaciones a partir de ellos. Los frameworks de ejecución de cómputo distribuido han existido desde hace casi 15 años, esfuerzos como el del Globus Toolkit, tuvieron lugar en 1996 [?]. Estas herramientas abstraen la mayoría de los problemas de crear aplicaciones para la grid y la nube. En épocas más recientes, se han creado esfuerzos comerciales por hacer plataformas completas para poder desarrollar aplicaciones en la nube. Ejemplos de estas plataformas son Windows Azure [?] y Amazon EC2 [?]. Este tipo de plataformas te permiten utilizar no sólo sus librerías y herramientas de desarrollo, también te permiten rentar el hardware que necesites esto varía de acuerdo al problema. Por ejemplo, para el caso del doblamiento de proteínas está medido en meses, pero la búsqueda de información en internet debe realizarse en fracciones de segundo

15 Motivación del trabajo de investigación A pesar de los múltiples esfuerzos que, como ya mencionamos, se han generado en torno al cómputo distribuido, existe una parte del ecosistema que no ha sido resuelta: el acceso al cómputo distribuido para aquellos no-expertos en el área. Hacen falta herramientas que permitan a cualquier persona con conocimientos de programación utilizar el poder del cómputo distribuido ejecutando un simple script en su computadora; dejándolos excentos de la preocupación de re-escribir su código para adaptarlo a alguna de las plataformas existentes. Es por esta falla que surge la idea de crear paradis. Proveer una plataforma fácil de usar que requiera de una configuración mínima para ser utilizada, será de gran ayuda en el campo del cómputo científico y la resolución de problemas complejos en menor tiempo Objetivos del trabajo de investigación Desarrollar un framework de ejecución paralela de código secuencial que permita la ejecución de scripts arbitrarios de JavaScript aprovechando los beneficios de este modelo de cómputo. Crear un modelo heurístico que permita, a partir de un programa dado, determinar fragmentos de código que puedan ser paralelizables. Desarrollar un motor de ejecución que permita distribuir fragmentos de un mismo programa entre varias máquinas y posteriormente reintegrar los resultados. Generar un mecanismo capaz de detectar conflictos en la reintegración de los resultados y que, en caso de existir problemas en dicha integración, sea capaz de volver al modelo de ejecución en una sola máquina Hipótesis Con paradis se logrará ejecutar código secuencial, incluso si este no está preparado para ejecutarse de manera distribuida, en a lo más el mismo tiempo que requeriría

16 Metodología de Investigación para ejecutarse en una sola computadora. Este límite está dado por la naturaleza del programa: si es inherentemente secuencial, no hay nada que se pueda hacer por paralelizar su ejecución Metodología de Investigación Con el objetivo de dar la formalidad necesaria a este documento y que pueda servir como herramienta para desarrolladores e investigadores del área de tecnologías de información, se seguirá una guía para la elaboración, presentación y diseño de este trabajo de investigación. Dicha guía tomará en consideración el propósito de los sistemas de información dentro de las organizaciones, el cual está orientado a mejorar la efectividad y eficiencia de las mismas [?]. De acuerdo a A. R. Hevner, S. T. March, J. Park, y S. Ramara, para que una aplicación sea productiva para una empresa es necesario que los desarrolladores de la misma cumplan con los siguientes 5 aspectos: Tener un amplio conocimiento sobre la empresa. Conocer las necesidades que cubre la aplicación, además de los propósitos de la misma. Objetivos y metas de la aplicación. Tendencias alrededor de las tecnologías de las que hace uso la aplicación. Información actualizada. El conocimiento necesario para el desarrollo del trabajo de investigación podrá ser adquirido basándose en cualquiera de los dos paradigmas siguientes: Paradigma de la ciencia del comportamiento - Desarrolla y justifica las teorías, principios y leyes que expliquen o pronostiquen fenómenos organizacionales y humanos que rodean al análisis, diseño, implementación, administración y uso de sistemas de información.

17 5 Paradigma de la ciencia del diseño - Su principal objetivo es el de solucionar problemas. Está centrado en la creación de ideas y la innovación en las practicas, capacidades tecnológicas y productos a traves de los cuales los procesos de análisis, diseño, implementación, administración y uso puedan ser alcanzados de manera eficiente y efectiva. Con base en lo anterior, podemos decir que la investigación se llevará a cabo tomando en cuenta lo relevante del problema sin solución previa, así como el diseño de la solución, las tecnologías en las cuales está basado, las personas que involucra y la transformación que ofrece al usuario Dominio del problema Identificación de fragmentos paralelizables en un programa. Para poder ejecutar un programa de forma distribuida, primero hay que identificar qué partes del código admiten ser paralelizados. Una vez identificados, es necesario serializar dichos fragmentos junto con el contexto necesario para ejecutarse en otra máquina. Generación de una topología dinámica de cómputo grid voluntario. Para facilitar el uso del framework en ambientes como universidades o laboratorios de cómputo, se decidió que se utilizaría un modelo de cómputo voluntario para realizar la distribución de tareas y ejecución paralela de código. El framework debe tomar en cuenta el hecho de que dichas máquinas no están siempre prendidas, y pueden ser apagadas o utilizadas a la mitad de la ejecución de una tarea, así que debe ser tolerante a fallos. Reintegración del contexto e identificación de conflictos. Una vez que se termine una fase de distribución de tareas, es necesario reintegrar todos los cambios de contexto que se realizaron en paralelo, para poder continuar de manera correcta con el programa. En caso de existir algún conflicto en dicha integración, es necesario deshacer los cambios y volver a ejecutar el fragmento en una sola computadora.

18 Estructura del documento Para fines de este trabajo de investigación, se asume que todas las máquinas donde se vaya a ejecutar el framework están admionistradas por la misma organización, se estará trabajando bajo un esquema de confianza absoluta. Por lo tanto, quedan fuera del alcance de este trabajo: Aspectos de seguridad. También se asume que la red por donde viajan los mensajes es de confianza. Los programas que se envíen al entorno de ejecución no se verificarán ni bloquearán para evitar ataques. Nodos bizantinos. Existen otros proyectos (como [?]) que son tolerantes a fallos intencionales en los nodos. Esto significa que todos los cálculos son verificados por más de una computadora Estructura del documento La teoría que sustenta el cómputo distribuido y sus avances, así como el diseño de lenguajes de programación modernos, serán revisados, dando un vistazo al estado actual en los progresos de estas dos áreas. El Capítulo 2, Estado del Arte, presenta el estado actual para cada uno de los Dominios del Problema identificados y otorga descripciones acerca de las tecnologías a utilizar en este framework. El Capítulo 3 trata sobre los problemas que este framework pretende solucionar. Estos problemas surgen de las necesidades que el dominio del cómputo científico presenta, así como de las carencias de las aproximaciones actuales. En el Capítulo 4 se detalla la propuesta de paradis, que en el Capítulo 5 será sujeto a evaluaciones cualitativas, presentando los resultados obtenidos. El Capítulo 6 muestra un resumen de las conclusiones y trabajos futuros.

19 Capítulo 2 Estado del arte Para dar un mayor acercamiento al tema del cómputo distribuido y sus diferentes aplicaciones, este capítulo está formado por dos secciones principales: la primera trata acerca del estado del arte en lo referente al tema del cómputo distribuido, y la segunda aborda diferentes conceptos relacionados con lenguajes de programación, en específico lenguajes de tipo scripting, así como definiciones de construcciones de lenguajes de programación que serán útiles para la explicación de la solución propuesta en este trabajo de investigación Cómputo Distribuido El cómputo distribuido es una forma poderosa forma de aprovechar los recursos distribuidos para realizar tareas a gran escala sin necesidad de haces uso de supercomputadoras. La computación distribuida se basa en dos pilares: el primero es el computacional referente a la asignación y administración de grandes tareas de cómputo y el segundo es el participativo el cual se refiere a la cooperación de la gente al proyecto ofreciendo sus recursos para el desarrollo de algún proyecto. [?]. Desde hace algunos años, la existencia de un gran número de equipos de cómputo sub-utilizados ha traído consigo el crecimiento del interés en temas relacionados al cómputo paralelo y distribuido; diferentes empresas e industrias, así como universidades y centros de investigación han buscado crear proyectos con los cuales aumentar 7

20 Cómputo Distribuido el rendimiento de los recursos computacionales existentes. Antes de adentrarnos más en el tema, es importante señalar la existencia de diversos tipos de cómputo distribuido: El cómputo en cluster y el computo en malla o grid; cuyas características explicaremos a continuación. Cuando nos referimos al cómputo cluster, hablamos de una colección de estaciones de trabajo similares o bien una serie de computadoras de uso general conectadas únicamente por medio de una red de área local de alta velocidad. Cada nodo con el mismo sistema operativo. [?]. Este tipo de cómputo adquirió gran popularidad en la época en que mejoró la relación precio-rendimiento de las computadoras de uso personal; es usado sobre todo para la programación en paralelo en la cual un solo programa es ejecutado paralelamente en múltiples máquinas. Dentro del ámbito del cómputo cluster existen diferentes configuraciones posibles, a continuación se describe cada una de ellas: Un commodity cluster es un sistema de cómputo local comprendido de una serie de computadoras interconectadas por una red en común. Se dice que es local cuando se trata de un conjunto de equipos independientes conectados a una misma red; en este tipo de cluster todos sus subsistemas componentes son supervisados dentro de un dominio administrativo único, típicamente están ubicados en un mismo espacio físico y son gestionados como si fueran un mismo sistema. Se trata de un cluster de tipo Beowulf-class system cuando es un cluster cuyos nodos son las computadoras personales, o bien, pequeños multiprocesadores simétricos (SMP) pertenecientes a las computadoras integradas por las redes de COTS de área local (LAN) o system area networks (SAN), y almacenado en una máquina con sistema operativoopen source tipo Unix. Un cluster de tipo constelación difiere del commodity cluster en que el número de procesadores en su nodo SMP excede al número de SMP que integran el sistema, además de que la red que interconecta los nodos SMP puede hacer uso de tecnología y diseño personalizados. Este tipo de configuraciones son útiles ya que proporcionan directrices y ayudan a centrar el análisis. [?]

21 9 En cuanto al cómputo grid, el término grid surge a mediados de los 90 s, para describir una propuesta de infraestructura de cómputo distribuido para la ciencia y la ingeniería [?,?], desde el nacimiento del término hasta la actualidad, se han desarrollado numerosos avances en el tema del cómputo distribuido, lo que ha ido modificando el alcance del significado de este término, extendiéndolo a los ramos de la inteligencia artificial y las redes de computadoras. Podemos diferenciar al cómputo grid del cómputo en cluster ya que este consta de sistemas distribuidos construidos generalmente como un conjunto de sistemas de cómputo, en dónde cada sistema podría caer dentro de un dominio administrativo diferente, y podría ser muy diferente cuando nos referimos al hardware, software, y la tecnología de red instalada. [?]. De acuerdo a Ian Foster, el problema específico que encierra el concepto de grid es la coordinación de recursos compartidos y la solución de problemas de manera dinámica, mediante organizaciones multi-institucionales de manera virtual. [?]. En el caso del cómputo en grid, el acceder a los equipos de cómputo, el software, la información y otros recursos implica enfrentarnos a problemas de colaboración y administración de recursos a nivel tanto industrial, científico e ingenieril. La separación geográfica entre computadoras de uso general o supercomputadoras ha hecho notable la necesidad de alguna herramienta que permita la integración de la capacidad de cómputo, así como de la información existente en las grandes bases de datos y otros dispositivos de almacenamiento. La existencia de las redes de alta velocidad presentan un avance en cuanto a la la tecnología necesaria para que esto suceda, sin embargo, crear una infraestructura física heterogénea en la cual el cómputo paralelo sea posible presenta un nuevo reto para los desarrolladores de software; un reto el cual ha sido atacado desde diversos puntos de vista y ante el cual han ido surgiendo diferentes propuestas se soluciones. Existen numerosas implementaciones de cómputo grid, así como herramientas middleware que facilitan la generación de proyectos que puedan ser ejecutados por este medio; Berkeley Open Infrastructure for Network Computing (BOINC) y Globus Toolkit, los cuales serán detallados más adelante en este trabajo de investigación, son tan solo un par de ejemplos de este tipo de software. Tanto en ámbito del Cómputo Cluster como en el del Cómputo en grid; se han creado numerosas iniciativas, cada una de las cuales presenta una nueva opción de aprovechamiento de los recursos computacionales. En los siguientes apartados de este

22 Cómputo Distribuido capítulo, haremos mención de diferentes iniciativas que han surgido para solucionar los problemas que hemos mencionado, los proyectos que se han desarrollado en torno a ellas, así como sus ventajas y desventajas que presentan en el ámbito del cómputo paralelo y distribuido Globus Toolkit: Infraestructura homogénea para cómputo distribuido. Como una solución ante el reto de crear una infraestructura heterogénea que facilitara el cómputo paralelo, en 1996 surge Globus Toolkit, una forma de integración vertical de la capa de aplicación, el middleware y la red [?]. Globus Toolkit consta de un grupo de herramientas de bajo nivel que proporcionan los mecanismos básicos para llevar a cabo tareas referentes a la comunicación, la autenticación, la información de red y el acceso a datos; dichos mecanismos pueden ser utilizados para desarrollar servicios de metacomputing 1 de alto nivel. Globus Toolkit es una tecnología que propicia el cómputo grid, ya que permite a los usuarios compartir la potencia de cálculo, bases de datos y otras herramientas online de forma segura sin sacrificar la autonomía local; dispone de un conjunto de módulos, cada uno de ellos define una interfaz la cual es utilizada por los servicios de alto nivel para invocar los mecanismos del módulo y provee una implementación, la cual utiliza operaciones a bajo nivel para implementar estos mecanismos en distintos entornos.(figura 2.1) Es importante mencionar que el módulo de comunicación, la librería Nexus, ha sido utilizada de manera independiente para construir diversas implementaciones de interfaces de programación paralela. 2.1 Esta tecnología incluye no solo el software y las bibliotecas necesarias para el monitoreo de recursos, sino también las herramientas necesarias para la gestión de la seguridad y los archivos. La aparición de esta tecnología provocó una gran revolución en la forma de hacer ciencia; proyectos como el Gran Colisionador de Partículas del CERN, han sido desarrollados con base en las tecnologías de Globus; esto a través del european data grid y esfuerzos de los EEUU como la Grid Physics 1 Metacomputer: Supercomputadora construida en red virtual de manera dinámica a partir de los recursos distribuidos geográficamente unidas por redes de alta velocidad.

23 11 GSI C GSI.Open SSH Globus Toolkit GridFTP C common libraries Metrics Reporting MyProxy Replica Location GRAM5 extensible IO (XIO) Security Data Management Execution Management Common Runtime Figura 2.1: Arquitectura de Globus Toolkit Network (GriPhyN). Globus Toolkit ha sido parte fundamental también del cabig, una infraestructura virtual de cómputo voluntario cuyo objetivo es la conexión de datos, herramientas de investigación, científicos y organizaciones para aprovechar sus fortalezas y la experiencia combinada en un entorno abierto con herramientas compartidas. Por último, otro proyecto científico relacionado a Globus Toolkit, es la red para Ingeniería y Simulación de sismos (NEES) [?], FusionGrid, el Observatorio Virtual Nacional. Como podemos ver, Globus Toolkit es una herramienta que nos permite hacerle frente al problema partiendo del punto más bajo, gracias a que posee numerosos mecanismos que útiles para implementar servicios, aún a bajo nivel. Sin embargo, existen otras iniciativas con perspectivas y alcances distintos, una de ellas es el proyecto BOINC BOINC: El poder de una super - computadora al servicio de tu proyecto. Bajo la premisa de que el poder de cómputo no está concentrado en las supercomputadoras sino en las millones de computadoras de propósito general que existen en todo el mundo, en 2002 la Universidad de California en Berkley creó BOINC

24 Cómputo Distribuido (Berkeley Open Infrastructure for Network Computing) [?], un sistema de software que facilita a los científicos la creación y ejecución de proyectos, teniendo a su disposición un gran poder de computo. A diferencia de Globus Toolkit, el cual se basa en el cómputo Grid realizado en computadoras de empresas, universidades y laboratorios, operadas por expertos en TI (Tecnologías de información), con BOINC este poder de cómputo se logra a través de la cooperación de los usuarios de computadoras de propósito general, quienes eligen participar en dichos proyectos, autorizando el uso de sus recursos computacionales. BOINC es una plataforma para compartir recursos de cómputo distribuido. Para que un proyecto pueda utilizar esta herramienta, es necesario contar con una URL maestra, la cual servirá como directorio para la organización de los distintos servidores. El servicio complejo de BOINC está centrado en una serie de bases de datos que almacenan las descripciones de las aplicaciones, versiones, unidades de trabajo, etc. Las funciones de los diferentes servidores son organizadas mediante una serie de servicios web y procesos daemon. Los servidores de datos se encargan de la carga de información usando un mecanismo basado en la certificación, esto para asegurarse de que únicamente los archivos que cumplan con las especificaciones de cada proyecto, sean los que se carguen. Una vez completado el proceso, los archivos que resultan son descargados por HTTP. [?] La creación de BOINC ha permitido que se desarrollen proyectos como SE- TI@home, cuyo objetivo es analizar las señales de radio en busca de señales de inteligencia extraterrestre y el cual actualmente cuenta con más de 2,760,643 computadoras colaborando; Predictor@home, cuyo principal objetivo es la realización de pruebas y evaluación de nuevos algoritmos para predecir estructuras de proteínas, tanto conocidas como desconocidas; folding@home, diferentes iniciativas del CERN, Einstein@home, entre otros. El uso de computo voluntario permitió además que no solo participaran personas que tuvieran acceso a computadoras de centros de investigación o universidades, sino que pudieran adherirse también aquellos con una computadora de uso general que no aprovecharan al 100 %. BOINC provee de herramientas para crear, iniciar y finalizar proyectos; además de poder añadir aplicaciones y plataformas nuevas o en diferentes versiones, crear unidades de trabajo y monitorear el desempeño de estas. Sin embargo, es una herramienta diseñada para ser aprovechada por científicos, ya que su funcionamiento

25 13 está centrado en proporcionar herramientas para el desarrollo de proyectos; además de la capacidad para añadir nuevas aplicaciones y sus diferentes versiones, creación de unidades de trabajo y monitoreo de del desempeño de los servidores. Además de estas herramientas, han surgido también diversas propuestas de modelos que permiten a los desarrolladores crear programas con características puntuales, los cuales puedan ejecutarse bajo modelos de cómputo distribuido. Cada uno de estos modelos presenta distintas características de implementación, ofreciendo un espectro amplio de posibilidades en cuanto a la forma de trabajar y desarrollar en torno a ellos. Para fines de este trabajo de investigación, enumeraremos algunos de los modelos más representativos, tomando en cuenta la magnitud de los proyectos en los que se ha aplicado y los resultados que se han logrado a través del mismo Condor, en búsqueda del alto rendimiento En los años 80 s nace Condor, con el objetivo de desarrollar, implementar, desplegar y evaluar mecanismos y políticas que apoyen la Computación de Alto Rendimiento por medio de la computación distribuida; además de la buscar la maximización de la utilización de computadoras de uso general o estaciones de trabajo sin interferir con los horarios de trabajo y las actividades de las personas que son dueños de las mismas[?]. Una de las innovaciones que introduce emphcondor es que por medio de esta tecnología fue posible identificar las estaciones de trabajo que se encontraban inactivas para así poder programar determinadas tareas a realizarse en dichos horarios; además, cuando la persona dueña de la estación de trabajo reanudaba sus labores, los puestos de control de emphcondor asignaban el procesamiento pendiente a otra estación de trabajo. El sistema garantiza que las tareas finalmente se completan, y que la menor cantidad de tareas se llevarán a cabo más de una vez. La idea de crear Condor nace a raíz de la sub-utilizacion de la capacidad de cómputo(en una empresa, se aprovecha aproximadamente un 30 % de la capacidad que se tiene); sin embargo, en ella misma pueden desarrollarse proyectos que requieran de una gran capacidad de cómputo para ser completados: simulación, algoritmos complejos,etc. El sistema Condor está diseñado para dar servicio a múltiples usuarios, permitiéndoles ejecutar programas que requieren de una gran capacidad de cómputo en

26 Cómputo Distribuido máquinas que se encuentran en estado idle. En este modelo, el sistema es capaz de detectar cuando una máquina está en idle, además, cuando una estación de trabajo está generando errores en su parte de la ejecución, esta se realizará de nueva cuenta para garantizar la completitud del trabajo. Es importante mencionar que los mecanismos que facilitan la ejecución en paralelo usando Condor consumen muy poca capacidad de cómputo, de otra forma, los dueños de las estaciones de trabajo probablemente no permitirían que estos fueran parte del sistema. Condor proporciona un mecanismo de administración de trabajo, políticas de programación, sistema de prioridades, monitoreo de recursos y gestión de los recursos. [?] La arquitectura de Condor y los mecanismos que maneja le permiten un buen desempeño en ambientes en los cuales un Resourse Management System (RMS) tradicional es débil. Condor permite el uso de grandes cantidades de cómputo tolerante a fallos, sin necesidad de disponer de los equipos al todo el tiempo, de esta manera, se facilita el uso de computación de alto rendimiento sin interferir con con la actividad local de cada estación de trabajo. Los lenguajes de programación ha crecido significativamente en años recientes, puesto que se han adaptado para expresar mejor la posible paralelización en un programa. Ejemplos de estos lenguajes o librerías son Cilk [?], Map/Reduce [?] y DryadLINQ [?] Map - Reduce: La opción de Google para cómputo distribuido. Google ha demostrado ser una de las empresas de tecnología que mayor compromiso tiene con la innovación; cada una de las herramientas que ofrece a sus usuarios han sido pensadas de manera que le faciliten la realización de sus tareas y lo lleven a construir nuevas soluciones. Bajo la misma premisa de aprovechar el cómputo sub-utilizado y aprovechar los recursos existentes nace Map Reduce [?], un modelo creado por Google, el cual permite realizar la ejecución de un programa de manera paralela, en múltiples computadoras de propósito general; una de las ventajas con las que cuenta este modelo es que permite que programadores con poca experiencia en el uso de cómputo paralelo y distribuido puedan desarrollar programas que se ayuden de este tipo de herramientas.

27 15 El modelo de programación de Map Reduce está compuesto de dos funciones básicas, el Map, escrito por el desarrollador, encargado de dividir el trabajo en varias unidades, generar claves para cada parte y repartir el trabajo, y el Reduce, también escrito por el desarrollador, el cual se encarga de recopilar los resultados de cada parte y unirlos en el resultado final, esto basándose en las claves de cada parte. En este modelo, el desarrollador es el encargado de precisar las unidades en las cuales el trabajo será dividido, esto a través de la definición de unidades semánticas que indiquen a los equipos de cómputo la forma en la cual deben generar dichas unidades. La figura 2.2 muestra la forma en el flujo de trabajo de un programa ejecutado en Map Reduce, la secuencia de las acciones es la siguiente: 1. La librería Map Reduce toma el programa y lo divide en M particiones; luego realiza copias del programa en una serie de máquinas (computadoras). 2. Una de las copias del programa es la copia Maestra, la cual está encargada de asignar tareas a las computadoras, ya sea de Map o de Reduce. 3. Una de las máquinas, a la cual le es asignada una tarea de Map, lee los datos de entrada, realiza un análisis sintáctico de los pares de clave/valor y, pasa cada uno de ellos como parámetro a la función Map; esta función produce nuevos pares de clave/valor. 4. De manera periódica, los pares que resulten serán enviados a un disco local, particionado en R regiones. La localización de estos pares en el disco local, es enviada a la máquina maestra, la cual es responsable de enviarlos a la fase de Reduce. 5. Cuando una máquina correspondiente a la fase de reduce es notificada de las localizaciones de estos pares por la máquina maestra, hace uso de procedure calls para leer los datos resultantes de las máquinas que han realizado la fase map. 6. Las máquinas encargadas de la fase reduce iteran sobre todos los resultados intermedios, hacen uso de los pares clave/valor y aplican la función reduce. La salida de esta función resulta en un archivo que podrá ser consultado por el usuario.

28 Cómputo Distribuido Usuario del Programa (1) fork (1) fork (1) fork Partición 0 (2) asignar map Maestra (2) asignar map Partición 1 Partición 2 (3) lectura Máquina Máquina (4) escritura local (5) lectura remota Máquina (6)escritura Archivo de salida 0 Partición 3 Máquina Máquina Archivo de salida1 Partición 4 Archivos de entrada Fase Map Archivos intermediosfiles (en discos locales) Fase Reduce Archivos de salida Figura 2.2: Operación de MapReduce

29 17 Dada la forma en que funciona Map Reduce, es posible controlar algunos errores. En caso de la computadora maestra, se realizan revisiones periódicas para revisar el estado de la misma, en caso de que esta quede fuera de servicio o presente algún error, se realiza una nueva copia de su información, comenzando a partir del estado del último chequeo correcto. [?] Múltiples problemas de cómputo pueden ser resueltos por medio de una implementación de Map Reduce, desde el año de creación de este modelo (2003), Google lo ha aplicado en distintos dominios, como son: resolución de problemas de clustering para sus productos Google News y Froogle, extracción de algunas propiedades de las páginas web para la realización de experimentos y el desarrollo de productos, procesamiento de imágenes a gran escala, entre otras Dryad: cómputo distribuido para datos paralelos Tanto en el modelo de programación que presenta Condor como en MapReduce el sistema define una estrategia de comunicación entre los equipos de cómputo participantes, lo que permite que el desarrollador se despreocupe en cuanto a temas como mecanismos de concurrencia, threads y control de concurrencia; sin embargo, dejan al desarrollador la responsabilidad y el trabajo de definir subrutinas que puedan ser ejecutadas por alguno de los equipos de cómputo disponibles, de esta manera, el desarrollador debe tomar en consideración que está llevando a cabo cómputo distribuido. Dryad es un proyecto de investigación de Microsoft, el cual fue planeado para la ejecución de aplicaciones en paralelo. En el modelo de ejecución de los programas en el contexto de este proyecto, cada trabajo que se ejecuta es tratado como un grafo dirigido acíclico, donde cada vértice es un programa y las aristas representan los canales de datos. En tiempo de ejecución, los vértices son los procesos que se comunican entre sí a través de los canales, y cada canal se utiliza para el transporte de una secuencia finita de registros de datos. [?] El objetivo principal de Dryad es organizar de manera eficiente los procesos correspondientes a los vértices en los equipos del clúster y proporcionar tolerancia a fallos mediante la re-ejecución de aquellos procesos que hayan presentado errores o que sean lentos. [?]

30 Cómputo Distribuido Windows Azure: Cloud Computing como servicio Dentro de las soluciones integrales en torno al cómputo distribuido, encontramos emphwindows Azure, un sistema operativo de servicios cloud que facilitan la realización de actividades de desarrollo, además de brindar servicio de alojamiento( hosting) y proporcionar el ambiente necesario para la gestión de servicios. emph- Windows Azure proporciona a los desarrolladores las herramientas necesarias para emphhostear, escalar, y gestionar aplicaciones web en Internet a través de centros de datos Microsoft R. [?] Windows Azure presenta ventajas como ser una plataforma flexible que soporta múltiples idiomas y es capaz de integrarse con el entorno existente en las instalaciones. Ya que para crear aplicaciones y servicios de emphwindows Azure, los desarrolladores pueden hacer uso de sus conocimientos existentes acerca de Microsoft Visual Studio. Además, emphwindows Azure hace uso de estándares de programación, protocolos y lenguajes como SOAP, REST, XML, Java, PHP y Ruby. De acuerdo a la página web oficial de emphwindows Azure algunos de los beneficios que presenta esta solución frente a otras de cómputo distribuido son: Agilidad: Aprovecha al máximo las las herramientas de desarrollo, por medio de la gestión de servicios automatizados y la presencia de centros de datos mundiales para responder más rápidamente a las necesidades del cliente. Eficiencia: Incrementa la productividad y la eficiencia operacional por medio de la reducción del costos. Tanto clientes como los miembros de la empresa tienen la posibilidad de tener una reducción del costo de las operaciones de algunas cargas de trabajo hasta en un % durante un período de 3 años. Enfoque: Es una solución enfocada en prestar servicios y valor a sus clientes, no en la gestión de infraestructura tecnológica. Reduce el tiempo que se dedica a obstáculos operativos y permite que los centrarse en el desarrollo de sus diferenciadores competitivos. Simplicidad: Permite que el programador haga uso de las habilidades de programación con las cuales ya cuenta para crear y administrar aplicaciones y servicios web.

31 19 Aplicaciones y Datos Windows Azure AppFabric SQL Azure Windows Azure Windows Azure Marketplace Figura 2.3: La Plataforma de Windows Azure, su soporte para aplicaciones, datos y su infraestructura en la nube junto con el marketplace. Confiabilidad: Cuenta con un servicio respaldado por acuerdos que proporcionan un servicio confiable y una experiencia rica en relación a los servicios en línea. La plataforma Windows Azure está integrada por 3 componentes ((Figura 2.3)) los cuales le permiten ejecutar aplicaciones en la nube: Windows Azure: Proporciona un entorno basado en Windows para ejecutar aplicaciones y almacenar datos en servidores alojados en los data centers de Microsoft. SQL Azure: Tecnología basada en SQL Server que proporciona servicios de almacenamiento de datos relacionales en la nube. Windows Azure AppFabric: Facilita la conexión de aplicaciones, tanto locales como en la nube entre si.

32 Lenguajes de Programación 2.3 Todos estos componentes se ejecutan en los centros de datos de Microsoft, los cuales están ubicados en distintos puntos del mundo. Los desarrolladores que hacen uso de esta plataforma pueden controlar en qué centro de datos quieren que se lleve a cabo la ejecución de sus aplicaciones y el almacenamiento de sus datos. [?] 2.2. Lenguajes de Programación Cuando surgieron los sistemas distribuidos, la programación de los mismos se realizaba en lenguajes secuenciales tradicionales, añadiendo generalmente algunos procedimientos para enviar y recibir mensajes. Sin embargo, conforme fueron creciendo el número de aplicaciones y haciéndose estas más complejas, estos lenguajes dejaron de satisfacer el 100 % de los requisitos, por lo que se comenzaron a diseñar lenguajes más sofisticados. De acuerdo a Bal, Steiner y Tanenbaum [?], un lenguaje de programación puede ser candidato para desarrollar una aplicación distribuida si: El lenguaje es adecuado para la aplicación. El lenguaje permite realizar la implementación con una eficiencia razonable en el hardware existente. Existen numerosos modelos que permiten cumplir con las dos características anteriores, el más básico es aquel en el que un grupo de procesos secuenciales corren en paralelo y se comunican mediante paso de mensajes; en este modelo el lenguaje puede solucionar la tarea programada de múltiples formas (e.g. diferentes tipos de paso de mensajes, chequeo de errores y type check del contenido). Sin embargo, para muchas aplicaciones, este modelo básico puede ser de muy bajo nivel, es por eso que existen modelos alternativos diseñados para el paralelismo, la comunicación y el manejo de errores, los cuales proporcionan mayor nivel de abstracción. La ausencia de efectos secundarios en los lenguajes funcionales permiten que la evaluación de las funciones se realice en cualquier orden, incluso en paralelo. Por otro lado, los lenguajes lógicos permiten que diferentes partes de un procedimiento puedan

33 21 ser trabajadas en paralelo, dos ejemplos de este tipo de lenguajes son Concurrent PROLOG y PARLOG. Dentro de los lenguajes orientados a objetos también es posible introducir la paralelización, esto haciendo que los objetos sean activos. Es importante hacer la distinción entre lo que es distribución lógica y distribución física de un programa; el software distribuido de manera lógica consiste en múltiples procesos que de comunican por medio de paso de mensajes. En contraste, los sistemas no distribuidos de manera lógica de comunican a través de datos compartidos. Existen 4 diferentes combinaciones de distribución lógica y física de software: 1. Software lógicamente distribuido ejecutándose en hardware físicamente distribuido, un ejemplo de este tipo de programas puede ser una colección de procesos corriendo cada uno de ellos en un procesador distinto por medio de mensajes de SEND y RECEIVE a través de la red. 2. Software distribuido de manera lógica corriendo en hardware no físicamente distribuido, en este segundo caso se hace uso de la misma lógica multi-proceso, con la diferencia de que ahora el paso de mensajes físico es simulado por la implementación de paso de mensajes usando memoria compartida. 3. Software no distribuido de manera lógica ejecutándose en hardware físicamente distribuido, esta clase intenta ocultar la distribución física haciendo que el sistema se comporte como si existiera memoria compartida. 4. Software no distribuido de manera lógica corriendo en hardware no físicamente distribuido, esta últimacombinación es la más sencilla ya que realiza la comunicación por medio de el compartimiento de datos usando la memoria compartida, lo que hace la programación mucho más sencilla Programación Funcional Los lenguajes funcionales son lenguajes declarativos cuyo modelo de computación es la función; la programación de este tipo de lenguajes, generalmente, describe en forma de expresiones lo que será computado, sin detallar la forma en que se llevará a cabo el cómputo. [?] Si bien este tipo de cómputo es considerado por muchos como más rápidos y concisos -ambas cuestiones que no pueden afirmarse de manera total-

34 Lenguajes de Programación lo que si podemos asegurar es que este tipo de lenguajes de programación son más susceptibles de razonamiento formal y el análisis, además de que facilita la ejecución de arquitecturas paralelas. Esto último es una de las grandes ventajas que tiene en lo referente al cómputo distribuido, lo implícito del paralelismo, el cual se manifiesta a través de las dependencias de los datos y la semántica de los operadores primitivos. En contraste con los lenguajes convencionales, en los cuales se requiere de construcciones explícitas para invocar, sincronizar y, en general, coordinar las actividades concurrentes. En el ámbito de la programación funcional las funciones pueden ser tratadas como valores de primera clase capaces de almacenar estructuras de datos que reciban argumentos como parámetros y generen resultados de acuerdo a ellos; esto es lo que conocemos como funciones de orden superior, las cuales pueden ser usadas para dar valor a distintas variables en un programa Lenguajes Scripting En los últimos años ha crecido significativamente el uso de lenguajes scripting, esta popularidad la han ganado gracias a las ventajas que presentan para realizar la integración de aplicaciones. A diferencia de los lenguajes para programación de sistemas, los cuales están diseñados para poder llevar a cabo la implementación de algoritmos y estructuras de datos haciendo uso de elementos de bajo nivel como las palabras de la memoria, los lenguajes scripting están diseñados para integrar aplicaciones ya existentes. Los lenguajes scripting asumen la existencia de un conjunto de componentes de gran alcance y están destinados principalmente a la conexión de dichos componentes. En este sentido, los lenguajes para desarrollo de sistemas se muestran inflexibles en cuanto al manejo de tipos de datos para gestionar la complejidad de un sistema, mientras que los lenguajes de scripting no hacen uso de tipos para simplificar las conexiones entre los componentes y facilitar el desarrollo rápido de aplicaciones. [?]. Podemos darnos cuenta así de que estos lenguajes pueden ser usados complementariamente, son usados de manera conjunta en algunos frameworks en los que el componente es creado mediante lenguajes de programación para desarrollo de sistemas e integrado por medio de lenguajes de scripting; esta tendencia en el desarrollo

35 23 es debida a que la existencia de computadoras más potentes, el aumento en la importancia de las interfaces gráficas para el usuario y las arquitecturas en componentes, el crecimiento de internet y la mejora de los lenguajes de scripting han incrementado la popularidad y aplicabilidad de este tipo de lenguajes. Ahora, debemos dejar en claro que los lenguajes de scripting no son reemplazo de otro tipo de lenguajes, sino simplemente sirven para conectar de una mejor manera las piezas de algunos sistemas. Otro factor que ha influido en el crecimiento de la popularidad de los lenguajes scripting es la popularización del Internet; esta herramienta,la cual no se encarga de la generación de nuevos datos sino que facilita la indexación de los existentes y aquellos que sus usuarios crean, hace uso de este tipo de lenguajes para permitir que múltiples componentes puedan trabajar de manera conjunta. Un ejemplo de esta aplicación de los lenguajes de scripting lo tenemos con Perl, lenguaje popular para la creación de scripts CGI, así como JavaScript, el cual es popular para secuencias de comandos en páginas Web. A continuación profundizaremos un poco más en los beneficios y las ventajas de la utilización de JavaScript en entornos de Frameworks y para la integración de componentes, esto para proporcionar un mayor fundamento teórico a la solución que presenta esta tesis. JavaScript JavaScript es un lenguaje scripting de gran simplicidad sintáctica que permite el desarrollo de aplicaciones cliente/servidor, facilitando la creación de aplicaciones que se ejecuten a través de Internet, este lenguaje goza de gran popularidad debido a la posibilidad que brinda en el manejo de objetos, la capacidad de realizar asignaciones de tipos de manera dinámica y la realización de las evaluaciones en tiempo de ejecución. Sin embargo, JavaScript cuenta con cualidades que permiten su uso en aplicaciones más allá del entorno web, ya que se trata de un lenguaje que soporta los closures y las continuaciones, además de estar diseñado para ejecutar peticiones haciendo uso de una cola de llamadas. Acerca de estos dos últimos conceptos hablaremos en las siguientes secciones.

36 Lenguajes de Programación Closures El término closure (o cerradura) fue propuesto por [?] para referirse a una expresión lambda (o una función anónima) cuyas variables libres han sido cerradas por el ambiente léxico, resultando en una expresión cerrada o closure. Posteriormente, el uso de los closures en lenguajes como Scheme [?] popularizó su uso. El uso de closures en lenguajes de programación modernos es común en todos los lenguajes de programación funcionales, y adicionalmente se ha popularizado en lenguajes de otros paradigmas, gracias a la incorporación de elementos funcionales (como las funciones lambda en lenguajes como C# o las clases anónimas en Java). JavaScript permite anidar funciones para ser creadas, de acuerdo al ámbito léxico vigente al momento de su definición, tiene un operador () para invocarla inmediatamente o más adelante. El closure nace de esta combinación de código que puede ser ejecutado fuera del ámbito en el que se define en combinación con la ejecución en su propio ámbito de aplicación.[?] Program 1 Ejemplo de la implementación de un Closure en JavaScript function showclosure(){ var inc = makeinc(1); } inc(); //1 inc(); //2 inc(); //3 function makeinc(initalvalue){ var count = initalvalue } return function(){ return count++; };

37 Continuaciones Prácticamente todos los lenguajes de programación poseen estructuras de control que permiten los saltos entre llamadas a funciones, algunas de estas estructuras permiten incluso saltar con argumentos entre funciones, a este tipo de salto lo llamamos continuación[?]. Las continuaciones representan el resto de la computación dado un punto en el cálculo, es decir, las estructuras de datos y el código necesario para completar un cómputo; se pueden considerar como una generalización de estructuras de control como jump y goto. Las continuaciones pueden ser usadas dentro de diferentes configuraciones, en cada una de las cuales pueden jugar un papel distinto, el cual podría ir de funciones matemáticas hasta direcciones de máquina. Una continuación es una forma de captar el flujo de control de un programa y manipularlo, es una idea primitiva que se puede utilizar para sintetizar cualquier forma de control de flujo.[?] A continuación se presenta un ejemplo de implementación de una continuación en Phyton: Program 2 Ejemplo de la implementación de una continuación en Phyton def looptest(n): this = continuation.current() k = this.update(n) # continuation at " = " if k: else: this(k-1) # resuming at " = " del this.link

38 Lenguajes de Programación En este ejemplo, nuestra continuación this está preparada para saltar a la situación en la que la asignación se lleva a cabo. La llamada this (k-1) nos mueve inmediatamente de regreso al contexto de dicha asignación, sólo que con un nuevo valor de k. Esto da lugar a la ejecución repetida de este segmento de código, formando un while loop. En este ejemplo no se hace uso de una continuación en los límites de una declaración, sino que es localizada en medio de una llamada a la función, en la situación de paso de parámetros. Este tipo de continuaciones son muy útiles ya que podemos pasar un parámetro y obtener un resultado nuevo.

39 Capítulo 3 Planteamiento del problema De acuerdo a lo planteado en la primera parte de este trabajo de investigación, sabemos que el uso de cómputo distribuido es una opción que facilita la ejecución de programas destinados a la investigación, la realización de cálculos de gran complejidad, entre otros. Sin embargo, esta solución presenta algunos retos para su uso e implementación. podemos identificar 4 diferentes problemas en cuanto a los métodos para paralelización, las: 3.1. Identificación de segmentos distribuibles del código En todos los otros frameworks investigados, se muestra una tendencia hacia crear mejores lenguajes, herramientas y modelos de cómputo para poder expresar de una manera en la que se exprese mejor la intención del programador con respecto a la distribución y paralelización del código. En el caso de este framework, se ha decidido tomar un lenguaje de propósito general, sin hacer cambios a la sintaxis y distribuir su ejecución de manera automática. Al no contar con un mecanismo sintáctico que le permita al entorno de ejecución identificar dichas regiones, es necesario crear una serie de heurísticas que permitan identificar segmentos potenciales del código que se puedan paralelizar, contando con un mecanismo para deshacer dicha acción. Por ejemplo, si se contara con un có- 27

40 Distribución de tareas entre distintos nodos de cómputo digo similar al del programa 3, cada una de las evaluaciones de la función f(i) se podría hacer en una máquina distinta (asumiendo que esta función no tiene efectos secundarios). Program 3 Ejemplo sencillo de código paralelizable en JavaScript var array = [1,2,3,4,5,6,7,8,9,10]; for(var i in array) { array[i] = f(i); } print(array); 3.2. Distribución de tareas entre distintos nodos de cómputo El problema de distribuir las tareas entre distintos nodos de cómputo se ha resuelto de distintas maneras a lo largo del tiempo. Map Reduce, por ejemplo, distribuye envía el procesamiento a todas las máquinas que contengan una partición de la información que se necesite procesar [?], y proyectos como BOINC y Distributed.net se basan en que los nodos voluntarios soliciten tareas al nodo central [?,?]. El framework tiene que resolver este problema de manera que permita integrar tanto nodos de cómputo dedicados así como voluntarios. Esta decisión de mezclar ambos tipos de distribución de tareas le permite al framework ser más flexible en cuanto a configuración, en el sentido que teóricamente sería posible utilizar servidores dedicados al procesamiento distribuido, además de aprovechar los recursos de cómputo que pueden ofrecer otras computadoras encendidas y subutilizadas en un ambiente como una escuela. Es requisito para la distribución de tareas la tolerancia a fallos: el cómputo se debe realizar de tal manera que el sistema se pueda recuperar ante la falla de uno de los nodos de cómputo.

41 Reintegración del contexto Por la manera en la que se realizará la distribución de las tareas en el framework, es necesario encontrar un mecanismo en el cual se pueda volver a integrar el contexto de la aplicación después de haber realizado una operación de distribución de una tarea. Esta operación debe garantizar varias cosas: 1. El resultado final de la reintegración debe ser igual, sin importar el orden en el que se efectúe sobre las subtareas. 2. El efecto neto del resultado de la ejecución de todas las subtareas debe ser equivalente a haber ejecutado todas las tareas de manera secuencial en una misma computadora Resolución de conflictos Es imposible garantizar la ausencia de conflictos en la reintegración del contexto después de haber realizado una operación de distribución en un lenguaje de propósito general (aunque sí es posible realizar este tipo de garantías en lenguajes funcionales, como Scheme[?], en el que se garantiza la ausencia de efectos colaterales en la ejecución de funciones). Debido a que en este framework no se cuenta con un mecanismo semántico en el cual el usuario indique qué fragmentos del código no se pueden paralelizar, es necesario entonces detectar alguna manera a posteriori de detectar conflictos en la reintegración y de una estrategia para ejecutar dicho fragmento de código de manera secuencial para garantizar su correcta resolución.

42 Resolución de conflictos

43 Capítulo 4 Propuesta de solución Este capítulo presenta la propuesta de solución del framework de distribución de código paradis, la cual está basada en los problemas identificados en el Capítulo 3 que son: Identificación de segmentos distribuibles del código. El framework está pensado alrededor de tomar un lenguaje de propósito general existente, sin hacer cambios a la sintaxis y distribuir su ejecución de manera automática. Entonces, debe existir un mecanismo que nos permita de manera automática identificar qué fragmentos del código son apropiados para esto. Distribución de tareas entre distintos nodos de cómputo. El framework tiene que resolver este problema de manera que permita integrar tanto nodos de cómputo dedicados así como voluntarios. Esta decisión de mezclar ambos tipos de distribución de tareas le permite al framework ser más flexible en cuanto a configuración, en el sentido que teóricamente sería posible utilizar servidores dedicados al procesamiento distribuido, además de aprovechar los recursos de cómputo que pueden ofrecer otras computadoras encendidas y subutilizadas en un ambiente como una escuela. Esto también debe garantizar el progreso del sistema en caso de que uno de los nodos falle. Reintegración del contexto. Por la manera en la que se realizará la distribución de las tareas en el framework, es necesario encontrar un mecanismo en el cual se 31

44 Modelación del problema y decisiones de diseño pueda volver a integrar el contexto de la aplicación después de haber realizado una operación de distribución de una tarea. Resolución de conflictos. Debido a que en este framework no se cuenta con un mecanismo semántico en el cual el usuario indique qué fragmentos del código no se pueden paralelizar, es necesario entonces detectar alguna manera a posteriori de detectar conflictos en la reintegración y de una estrategia para ejecutar dicho fragmento de código de manera secuencial para garantizar su correcta resolución. En las siguientes secciones de esta propuesta de solución se presenta la justificación del conjunto de requisitos seleccionados para la funcionalidad del Framework, basado en las problemáticas descritas en el Capítulo 3, para luego representar tales requisitos con algoritmos formales descritos en pseudocódigo. Este capítulo está dividido en tres secciones. En la primer sección (4.1) se van a establecer los modelos que se utilizarán a lo largo del capítulo, junto con algunas decisiones de diseño. La segunda sección (4.2) presenta la manera en la que se identificarán fragmentos paralelizables en el código y cómo es que estos fragmentos se serializarán para poderlos distribuir. Posteriormente, la sección de distribución de tareas (sección 4.3) mostrará la manera en la que se integrará el cómputo voluntario en el Framework, haciendo énfasis en garantizar de que el sistema en conjunto progresará hacia una solución siempre y cuando haya al menos un nodo disponible. Por último, se presenta el algoritmo de reintegración de contexto y detección de conflictos en la sección Modelación del problema y decisiones de diseño En general, podemos modelar un programa de cómputo como un grafo acíclico dirigido, donde cada nodo representa una serie de instrucciones, y un arco representa una dependencia en el orden en el que se deben de ejecutar. Un programa inherentemente secuencial consistirá entonces de una serie de nodos donde cada nodo (excepto el primero y el último) tienen exactamente un predecesor y un suceros (similar en estructura a una cadena), como se puede ver en la figura 4.1a. Un programa altamente paralelizable, en cambio, tiene una estructura menos lineal, tal como se aprecia en la figura 4.1b. Si se opera bajo la premisa que hay una gran cantidad de nodos

45 33 (a) Secuencial (b) Paralelizable Figura 4.1: Dos ejemplos de estructuras de programas de cómputo voluntario, es posible calcular un límite inferior para el tiempo en el que se puede ejecutar el programa en su totalidad, mediante métodos matemáticos como el CPM 1 [?]. Sin embargo, no es posible saber de antemano cuánto tiempo se va a tardar cada nodo en ejecutarse. Este mismo modelo se ha usado antes en otros trabajos de investigación, como en [?]. Para fines de este trabajo, el grafo de actividades del programa se puede construir de la siguiente manera: Cada bloque de código es un nodo que se agrega en serie al final de la cadena de nodos. En el caso de tener un ciclo, hay dos posibilidades: Todas las iteraciones del ciclo son independientes entre sí, y cada uno de ellos se pueden ejecutar en paralelo. Hay interdependencia entre las iteraciones del ciclo, y entonces deben de realizarse de manera secuencial. Se asume que un ciclo consta de un nodo inicial vacío, seguido de todas las iteraciones del ciclo (ya sea en paralelo o en serie), seguido de un nodo final vacío. En la sección 4.2 se explica el método que se utiliza para determinar si las iteraciones del ciclo se pueden paralelizar o no. 1 Critical Path Method

46 Fragmentación del código en Closures El objetivo de el framework es buscar, de manera automática y no supervisada, encontrar el mayor número de bloques de código que admitan ser ejecutadas de manera independiente en paralelo, minimizando así el tiempo de ejecución total. Con el objetivo de hacer un framework portable entre plataformas de cómputo, se decidió realizar la implementación sobre una máquina virtual, en específico en la JVM 2. El lenguaje de propósito general que se va a utilizar para ejecutar el código será JavaScript, gracias a su soporte nativo de closures. Rhino es una implementación de código abierto de un compilador e intérprete del lenguaje JavaScript sobre la JVM, desarrollado originalmente por Netscape Communications y después por la Mozilla Foundation Fragmentación del código en Closures Como se mostró en la sección 4.1, es a partir de los ciclos en el programa que se puede lograr la paralelización. Lamentablemente, es un problema muy grande el saber de manera general si dos fragmentos de código están o no relacionados. Es por esta razón que es necesario encontrar un método alterno de detección de fragmentos paralelizables. Se hará uso del concepto de closures, revisado en la sección En este trabajo de investigación, el método para decidir si un ciclo específico es o no paralelizable es el siguiente: Sea c un fragmento de código. Podemos definir la función v(c) como aquella que obtiene el conjunto de todas las referencias a variables que c usa de manera directa, y la función b(c) como la que obtiene el conjunto de todas las referencias directas a otros bloques de código a partir de c. Dado el conjunto B 0 = {c} podemos definir de manera recursiva B i+1 = {b(b i ) b i B i }, i 0 2 Java Virtual Machine

47 35 esto es, B i es el conjunto de todos los bloques que son accesibles desde c después de i aplicaciones de la función b(c). La función closure(c) nos permite conocer todas las variables que son referenciadas, ya sea de manera directa o indirecta por c. La definición de closure(c) es closure(c) = V = i N{v(b i ) b i B i } Dados dos fragmentos de código c 1 y c 2 (que pueden ser iteraciones distintas del mismo ciclo), sea V com = closure(c 1 ) closure(c 2 ). Si V com =, entonces ambos fragmentos son disjuntos y se pueden paralelizar sin problemas. De la misma manera, cuando no se modifica ninguna variable de V com en ninguno de los fragmentos, y se utilizan como variables de sólo-lectura. En cualquier otro caso, se pierde la garantía de que c 1 y c 2 puedan ejecutarse en paralelo. Hay un caso muy común y específico que es el uso de arreglos, matrices y mapas, pues el acceso a los elementos individuales de este no se puede predecir de manera estática, y solo se puede conocer en tiempo de ejecución. Esto quiere decir que si todas las variables de V com que se modifican son de tipo matricial, entonces es imposible determinar de manera general si se pueden paralelizar o no. Este será el caso principal sobre el cual operará el framework. La manera en la que se fragmenta se presenta en el algoritmo??. Data: Un script de computadora Result: Una lista de fragmentos serializados de código qgetsqueue; foreach Bloque b do if b es un ciclo then c closure(b); foreach Iteración i del bloque b do c i c + {variablesdeliterador}; serializa c i y agrégalo a q; end end end regresa q; Algorithm 1: Algoritmo de fragmentación de código usando closures

48 Distribución de tareas En el anexo A, se presentan una serie de recomendaciones para maximizar la paralelización de un programa. Para el caso de la implementación de este framework, se decidió modificar el parser de Rhino, ya que una vez que se pasa por esta etapa, es imposible distinguir de entre los distintos tipos de ciclos en JavaScript. Es por eso que se hizo una pequeña función que cambiara los ciclos a una forma más útil para el framework, que se muestra en el programa 4. Esta transformación es importante, pues mediante la elección de nombres únicos para las funciones generadas, es como el intérprete puede ubicar de manera fácil los puntos en los que es posible realizar la separación del código. Si se serializa el closure sobre la función interna (llamada pi0 en el ejemplo), es posible capturar el contexto completo de una sola iteración del ciclo. Program 4 Transformación estructural de ciclos en paradis for(var i in array) { /* instrucciones */ } function p0(i) { /* instrucciones */ } for(var i in array) { function pi0() { p0(i); } pi0(); } 4.3. Distribución de tareas Como se mencionó anteriormente en este mismo capítulo, para lograr el paralelismo, se hará uso de la distribución de subtareas en distintas máquinas. En el caso del presente trabajo, el modelo que se usará será el del cómputo voluntario, en el cual se tiene un nodo central confiable donde se inician todos los procesos de cómputo y orquesta el progreso de todo el sistema y varios nodos de cómputo que tienen las siguientes características:

49 37 Intermitencia. Como las máquinas en las que se instalará el cliente de cómputo del framework son computadoras que no se están utilizando durante todo el día, no podemos esperar que estén disponibles en ningún punto específico en el tiempo. Sin embargo, cuando están disponibles es cuando voluntariamente van a contribuir al progreso del sistema. Recursos limitados. Al no ser computadoras dedicadas exclusivamente al cómputo de alto desempeño y cuyo propósito es ser simplemente una máquina de propósito general, las especificaciones técnicas de estos nodos no serán los más adecuados para nuestras necesidades. Propensos a fallos. No se espera que ninguno de los nodos de cómputo sean confiables, a la vez que estos pueden fallar en cualquier momento y por una multitud de razones. Una vez que la ejecución de un programa llega un punto en el que se puede paralelizar la ejecución (i.e. un ciclo), y se serializan todas las iteraciones de dicho ciclo, estas se colocan en una lista de espera simple. Conforme los nodos de cómputo voluntarios tienen disponibilidad de tomar uno de los trabajos pendientes, notifican al nodo central de su disponibilidad, y éste envía la versión serializada de uno de estos trabajos. Una vez que el nodo de cómputo termina de procesar el fragmento, envía todos los cambios realizados en el contexto original al nodo central para su reintegración. Para detectar los cambios en el contexto original se mantiene una lista de todas las variables modificadas por la ejecución del nodo de cómputo que estaban presente en la versión serializada de la tarea. La información que se envía de vuelta es justamente esta lista de variables, junto con sus nuevos valores. Al estar nuevamente disponible, el nodo de cómputo vuelve a hacer una petición de trabajo al nodo central, y así sucesivamente hasta que se termine de ejecutar por completo el programa. En el caso concreto de la implementación del framework, se utilizó una fila que almacena todas las instancias de las iteraciones de un ciclo en memoria. Todos los clientes que contactan al servidor obtienen una de estas iteraciones, que posteriormente se ejecutará en el cliente y devolverá los cambios al contexto de ejecución al servidor. En caso de que uno de estos clientes llegara a fallar en algún punto en este

50 Algoritmo de reintegración del contexto y detección de conflictos proceso, la instancia de la iteración se regresará a la fila para que otro cliente la obtenga. Esto se puede apreciar en el algoritmo 2. Data: Una lista q de bloques de código serializados while true do c es un cliente que se conecta b q.pop() if b es nulo then Ya no hay más bloques por ejecutar Notifica al cliente y cierra la conexión; end Envía b a c Lee la respuesta de c Reintegra el contexto que envió c a un contexto local temporal if el contexto temporal tiene conflictos then Cancela la operación y ejecuta todos las iteraciones del ciclo de manera secuencial end if hubo algún error durante el proceso then q.push(b); end end Algorithm 2: Algoritmo de distribución de tareas por parte del servidor 4.4. Algoritmo de reintegración del contexto y detección de conflictos Como se mencionó en la sección 4.1, para poder garantizar que la ejecución de un programa es correcta, es necesario que todos los cambios en el contexto de ejecución que fueron realizados en los nodos de cómputo se reintegren en el nodo principal. Por eso es necesario que Cada vez que uno de los nodos de cómputo termine con una tarea, envía la lista de variables modificada con sus nuevos valores de vuelta al nodo principal. Entonces el algoritmo que sigue el cliente para decidir qué valores enviar es el que se puede ver en el algoritmo 3. Una vez que la versión serializada del contexto llega al servidor, este ejecuta el algoritmo de detección de conflictos y reintegración del contexto que se puede ver en el algoritmo 4.

51 39 Data: Un bloque de código serializado b Result: Una lista ans de variables con sus valores f la versión des-serializada de b; m newmap(); ans newmap(); for identificador v en el contexto de f do m[v] f.v; end f(); for identificador v en el contexto de f do if m[v] f.v then ans[v] f.v end end return ans; Algorithm 3: Algoritmo de ejecución y serialización del contexto cambiado Data: Una lista de cambios de contexto q m newmap(); for contexto c en q do for identificador v en el contexto de f do if m[v] = null or m[v] = f.v then m[v] f.v; end else se ha detectado un conflicto; return f alse; end end end for identificador v en m do contexto[v] m[v]; end Algorithm 4: Algoritmo de detección de conflictos y reintegración del contexto

52 Algoritmo de reintegración del contexto y detección de conflictos Esto implica que únicamente se permite la modificación de variables si para cada par de tareas i, j, el conjunto de variables modificadas es disjunto 3. Esto sigue de la idea presentada en la sección 4.2 de que las tareas paralelizables son aquellas que no tienen variables modificadas en común. Sin embargo, variables matriciales (como arreglos, matrices y arreglos asociativos) pueden modificar sus elementos individuales sin causar un conflicto, y esto no es posible de identificar más que en tiempo de ejecución. En caso de no existir un conflicto en toda la reintegración del conflicto, los cambios en las variables se aplican en el entorno de ejecución y la ejecución continúa de manera normal a partir del punto donde el ciclo termina. Sin embargo, si hubo un conflicto (i.e. existió al menos una lista de modificaciones que no fue aceptada), la ejecución se reanuda de manera secuencial desde antes de empezar el ciclo y se descartan los cambios parciales en las variables que se efectuaron hasta ese momento. Es así como el framework logra garantizar que la ejecución de un programa será correcta, aunque su ejecución sea imposible de paralelizar. Veremos en el capítulo 5 varios tipos de programa, junto con su desempeño con y sin paralelización, utilizando distintos números de nodos de ejecución. Para ver un ejemplo real de uso de este framework, es posible consultar el programa 5 en el capítulo A. 3 Es posible tomar en cuenta y detectar cambios en las variables en vez de guardar únicamente el estado final. Por ejemplo, en el caso de un contador, cada nodo de ejecución puede reportar el cambio en el valor, y agregarlo al final en el nodo principal. Este comportamiento sólo es posible si todas las operaciones que actuaron sobre la variable son conmutativas, es decir, que el resultado de la agregación de las operaciones será el mismo, sin importar el orden en el que se apliquen dichas operaciones. Este es el caso, por ejemplo, de la suma sobre los números reales. Sin embargo, esta optimización queda fuera del alcance de este trabajo de investigación

53 Capítulo 5 Evaluación Para observar el cumplimiento de los objetivos planteados, así como poder evaluar el nivel de alcance de cada uno de ellos, se realizarán una serie de pruebas que nos permitan medir el alcance logrado en cada caso. A lo largo del desarrollo de este proyecto, se ha acumulado experiencia e información en torno al problema del cómputo paralelo y distribuido, lo que ha sido de utilidad para la generación de pruebas que nos permitan evaluar el cumplimiento de dichos objetivos. Paradis será el framework que resulte del cumplimiento del total de los objetivos planteados en este trabajo de investigación; la correcta implementación de cada uno de ellos garantiza el funcionamiento total de la herramienta. Por tal razón, las pruebas de evaluación que a continuación se describen serán realizadas para probar la correcta implementación de cada uno de los objetivos en individual y, al final, que el framework de manera integral funcione de acuerdo a lo especificado Plan de Evaluación Uno de los objetivos de este trabajo es el desarrollo de un framework de ejecución paralela de código secuencial que permita la ejecución de scripts arbitrarios de JavaScript aprovechando los beneficios de este modelo de cómputo. Para demostrar que la ejecución aprovecha las características del cómputo distribuido, aplicaremos la técnica de análisis, comparando la ejecución del script en una computadora de 41

54 Plan de Evaluación propósito general, con el resultado de la ejecución del mismo script en una serie de computadoras con trabajando con nuestro framework. Los pasos y artefactos que permitirán la realización de este análisis, se describen a continuación: Entrada: El script de JavaScript con el cual se desea trabajar. Paso 1: Ejecutar el script en una sola computadora de propósito general. Paso 2: Registrar el tiempo y los resultados obtenidos de esta primera ejecución. Paso 3: Ejecutar el script en una serie de computadoras que cuenten con paradis Paso 4: Registrar el tiempo y los resultados obtenidos de esta segunda ejecución. Paso 5: Realizar una comparativa de los resultados registrados en el paso 2 y el paso 4. Resultados esperados: Tras haber realizado este análisis, lo esperado es que el tiempo de ejecución en nuestro framework sea menor o igual al registrado en la ejecución en una sola computadora de uso general. Un segundo objetivo de nuestro framework es la creación de un modelo heurístico que identifique correctamente los fragmentos de código que puedan ser paralelizables; para verificar que dicho objetivo se cumpla, se realizarán las siguientes pruebas para la evaluación del framework: Se ejecutarán los siguientes scripts, cada uno con distinto grado de paralelización: Solución de un problema utilizando programación dinámica. Esto nos resultará en un código inherentemente secuencial y altamente interdependiente. Solución de un problema utilizando algoritmos genéticos. Esto nos proveerá con una mezcla de fragmentos paralelizables y fragmentos secuenciales. Un raytracer, que es altamente paralelizable. Se ejecutarán todos los scripts con varios nodos voluntarios listos para ejecutar código de manera distribuida y se tomará el tiempo que le toma al script en terminar.

55 43 Para facilitar el registro y análisis de la información, se generarán los siguientes artefactos: Una tabla y una gráfica que indiquen el porcentaje de tiempo que le tomó a cada script terminar en cada configuración con respecto a la medición obtenida en el Paso 2; así como las características especiales o factores relevantes que hayan existido en cada una de las pruebas realizadas Resultados de la Evaluación Para verificar el aprovechamiento de los beneficios del cómputo distribuido se utilizó un programa escrito en JavaScript, el cual realiza el cálculo de la función inversa MD5, el detalle de la implementación de este programa podrán encontrarlo en el Anexo A. De inicio, el script fue ejecutado en una sola computadora de uso común con las siguientes características: Intel(R) Xeon(R) CPU 2.83GHz, con ocho núcleos 16GB de memoria RAM El tiempo total que necesitó para encontrar las contraseñas para 11 hashes MD5 de hasta 6 caracteres de longitud fue de 9.85 horas. Se utilizó el mismo script para ejecutarse en forma paralela con paradis, para esto se instaló la herramienta en varias computadoras de uso común de los estudiantes, las cuales estuvieron conectadas a la red de forma voluntaria. Se realizó una convocatoria a ayudar por medio de una red social. Dada la heterogeneidad de las máquinas que participaron, es imposible determinar características generales del equipo, pero habían computadoras que iban desde una netbook con un núcleo hasta computadoras de escritorio con 4 núcleos. El tiempo de ejecución fue de 20.5 minutos lo que representa el 3.46 % del tiempo de ejecución en una sola computadora y es equivalente a 12.3 horas máquina. Los datos anteriores nos permiten afirmar que el objetivo de realizar una ejecución paralela de código secuencial aprovechando los beneficios de este modelo de cómputo fue alcanzado.

56 Resultados de la Evaluación Número de Máquinas Tiempo de ejecución single s 1 máquina s 2 máquinas s 3 máquinas s 4 máquinas 9.861s 5 máquinas 8.135s 6 máquinas 7.251s 7 máquinas 6.201s 8 máquinas 5.746s Tabla 5.1: Ejecuciones en paradis con diferentes cantidades de máquinas. Con el objetivo de apreciar a forma en que mejoran los tiempos de ejecución en relación al aumento del número de computadoras de uso general disponibles para realizar la ejecución del programa, se corrió una versión reducida del mismo script (donde se limita a 4 caracteres la longitud de la contraseña en vez de 6) en una cantidad distinta de computadoras de uso general, la información de cada uno de estos experimentos se muestra en la Tabla 5.1: Como se puede ver en la Gráfica 5.1, generada a partir de esta misma información, el tiempo de ejecución reduce de manera drástica con las primeras máquinas, sin embargo, con las siguientes la disminución es gradual. También se realizó la ejecución de un script de un programa secuencial, en el cual cada iteración depende de la anterior. El programa en este caso realizaba la suma de todos los números del 0 al 999 (inclusive) de la manera directa. Al ejecutarse con single, termina casi inmediatamente, en 0.317s. Sin embargo, al momento de intentar ejecutarlo de manera paralela, el overhead de serialización/des-serialización aunado a que intenta paralelizar un ciclo que sabemos que no es posible, eleva el tiempo de ejecución a 2.467s. Cabe resaltar que en cuanto el servidor nota que el contexto no es reintegrable, detiene la ejecución paralela, causando que sólo se evalúen unas cuantas iteraciones en los clientes. Una captura de pantalla se puede apreciar en la figura 5.2.

57 Single Figura 5.1: Gráfica de tiempo registrados para la ejecución con distintos números de computadoras de uso común Figura 5.2: Screenshot de una ejecución de paradis

58 Resultados de la Evaluación

59 Capítulo 6 Conclusiones y trabajos futuros 6.1. Conclusiones El cómputo distribuido es una de las mejores opciones para aprovechar al máximo el performance de cada una de las computadoras existentes dentro de cualquier entorno, sobre todo si hablamos de una empresa o institución que posee un gran número de equipos, muchos de los cuales están subutilizados. El aprovechamiento de la capacidad de cómputo para fines de investigación, o bien, para la ejecución en sistemas de programas complejos que requieran de una gran capacidad de cómputo, ahorra a los usuarios finales la inversión que significa la adquisición de una supercomputadora, al tiempo que les permite llevar a cabo sus tareas. El cómputo distribuido tiene además la ventaja de proporcionar a sus usuario alto rendimiento, una disponibilidad alta ya que en caso de fallar una de las máquinas el resto siguen dando servicio eficiencia y escalabilidad. A lo largo de la realización de este trabajo de investigación pudimos ver que existen diferentes tecnologías, implementaciones y middleware que permiten a los desarrolladores la creación y ejecución de programas que hagan uso de la ejecución en paralelo, sin embargo, en algunas ocasiones el uso de estas herramientas exige que los desarrolladores estructuren sus programas de forma que la solución pueda ser paralelizable, aspecto que no siempre es posible. No todos los problemas pueden ser resueltos mediante cómputo paralelo. Otro problema de algunas de estas herramientas es la complejidad que presentan en cuanto a desarrollo; uno de los objetivos del 47

60 Trabajos Futuros cómputo paralelo es hacer que el desarrollador deje de preocuparse por los recursos computacionales y se centre en la implementación de la solución, sin embargo, al ser esta compleja, se pierde parte del beneficio. Fue debido a esto que se buscó desarrollar una herramienta que permitiera que usuario beneficiarse de las características del cómputo paralelo con la posibilidad de desarrollar soluciones en un lenguaje sencillo. Los lenguajes scripting presentan ventajas en torno al cómputo distribuido, ya que facilitan la ejecución dinámica y cuenta con gestión automática de la memoria. En particular para fines de este trabajo de investigación, pudimos aprovechar dos ventajas adicionales de JavaScript: su manejo de closures y continuaciones, elementos que nos facilitaron la implementación de este framework de ejecución paralela. En los últimos años la popularidad del computo paralelo y distribuido ha crecido, no solo por las ventajas que presenta para la ejecución de programas que requieran de una gran capacidad de cómputo, sino también porque estas herramientas dan la posibilidad a usuarios de una computadora de uso general, de participar en proyectos de investigación o científicos con tan solo poner a disposición de estos proyectos la capacidad de cómputo con la que cuentan Trabajos Futuros Durante la creación del entorno de ejecución, notamos la posibilidad de hacer muchísimas mejoras al desempeño. Por la manera en la que funciona la serialización de objetos y funciones JavaScript con el compilador Rhino, es necesario ejecutar el código en modo interpretado, de manera que no se está aprovechando al máximo el poder de los nodos de cómputo. La idea es que, por medio de análisis estático (en tiempo de compilación), es posible identificar bloques de código que no se necesitan serializar (utilizando un grafo de dependencias) para optimizar dichos bloques y mejorar el desempeño. Otro punto relacionado con el desempeño es que el entorno de ejecución distribuida podría estar mucho más integrado con el compilador/optimizador/intérprete. Una mayor integración podría significar importantes mejoras en tiempo de ejecución, pues muchas de las validaciones y heurísticas (como la detección de variables modificadas) se podrían realizar de manera más simple, elegante y eficiente.

61 49 Otra idea que no se exploró en este trabajo es la de cambiar la topología de la red de cómputo, de cliente-servidor a peer-to-peer. Esto traería ventajas como aún más facilidad de administración, una potencial mejora de desempeño y flexibilidad, puede ocasionar problemas de confiabilidad. Esto es porque en el esquema tradicional de cliente-servidor solo es necesario que el servidor esté ejecutándose de manera confiable, todos los clientes pueden ir y venir en cualquier momento; en el esquema peer-to-peer, en cuanto uno de los nodos de cómputo deja de estar disponible, todo el progreso que realizó ese nodo tiene que volverse a ejecutar. Una manera posible de evitar esto es proveer un sistema de almacenamiento distribuido a los nodos, como una tabla de búsqueda distribuida como Chord [?] y Tapestry [?]. Este esquema adicionalmente tiene la ventaja de que todos los nodos son clientes y servidores a la vez, así que el paso de distribución de tareas/reintegración del contexto se podría ejecutar de manera recursiva conforme sea necesario.

62 Trabajos Futuros

63 Anexo A Mejores prácticas para maximizar la paralelización Debería resultar aparente de la descripción del capítulo 4 que hay dos cosas muy importantes a considerar para la ejecución óptima de un programa: primero, existen algoritmos que son inherentemente secuenciales y no pueden ser paralelizables; segundo: existen muchos programas, que, con unos pequeños cambios, es posible generar una versión equivalente del programa que explote mejor el mecanismo de paralelización que ofrece el framework paradis. Primero que nada, hay que recordar que el modelo de paralelización del framework se basa en encontrar ciclos en el código del tipo for(var i in s), donde i es la variable del iterador y s es el conjunto sobre el cual se va a iterar. El otro tipo de ciclo, el for(var i = 0; i <x; i + +) quedó fuera del alcance por no ofrecer la garantía de que la variable del iterador sea inmutable durante el ciclo. Otro aspecto a considerar es el hecho de que la serialización, des-serialización, reintegración del contexto y transmisión de los chunks serializados todas son operaciones que toman tiempo. Eso quiere decir que si existe un ciclo pequeño, de pocas iteraciones o de muy corta duración, es mejor notificarle al entorno de ejecución que suspenda momentáreamente la distribución de tareas. Esto se puede lograr mediante la función especial paradis.stop(), llamada justo antes del ciclo que se desee ejecutar localmente. Al terminar el ciclo, se puede llamar la función especial 51

64 52 paradis.start() de nuevo y así regresar al intérprete a su estado original donde intenta paralelizar todos los bloques que puede. Por último, como otra consecuencia del hecho de que las operaciones que sustentan a una ejecución no sean instantáneas es que siempre es preferible ejecutar un código en otra computadora sólo cuando se estime que el tiempo de ejecución de una iteración de un ciclo durará más que todo el overhead de la ejecución distribuída. Como ejemplo, se realizó un script que calcula la función inversa MD5. La función MD5 era usada como una función de hash 1 hace años hasta que se descubrió que era inseguro. Aún así, existen muchas empresas y proyectos que la utilizan para almacenar contraseñas de manera supuestamente segura. En este ejemplo, se demuestra la aplicación de todos los consejos para mejorar el desempeño de los scripts. 1 esto es, una función que toma una cadena de longitud arbitraria y genera una cadena de longitud fija. Generalmente este tipo de funciones también cumplen con la propiedad de que un pequeño cambio den la entrada, produce un gran cambio en la salida, y que son difíciles de invertir

65 53 Program 5 Ejemplo de un código JavaScript altamente paralelizable // Demo 4 de paradis :D MD5^-1 redux function numtostring(n) { var ans = ; while(n > 0) { ans = String.fromCharCode((n+25)%26 + a.charcodeat(0)) + ans; if(n > 26) { n = Math.floor((n-1)/26); } else { break; } } } return ans; var md5orig = [ "9cdfb439c7876e703e307864c9167a15", "fe01ce2a7fbac8fafaed7c982a04e229", "4d186321c1a7f0f354b297e8914ab240", "3e3f44d7e0cb298b7d0fe9821b35e3fc", "bd39ef185c96c7bd761a5d7d8f70dca2" ]; var starts = []; var ans = [] // este bloque de código, al ser un ciclo que no se // paraleliza, se ejecuta en su totalidad en la máquina // local. for(var i = 0; i < 48; i++) { // cada uno de los bloques ejecutará 10,000 // iteraciones, para compensar el tiempo de // distribución de la tarea starts[10000 * i] = true; }

66 54 for(var s in starts) { java.lang.system.out.println("bloque de " + s); for(var i = 0; i < 10000; i++) { var num = parseint(s) + i; // la implementación de la función MD5 se // omitió por cuestiones de claridad var md5 = MD5(numToString(num)); for(var j = 0; j < md5orig.length; j++) { if(md5 == md5orig[j]) { ans[numtostring(num)] = md5orig[j]; } } } } // esto se imprimirá en la computadora // cliente, no en el servidor. Es // necesario realizar el reporte // completo al final java.lang.system.out.println(" Encontrado! " + numtostring(num) + " = " + md5orig[j]); // a partir de este punto, queremos que todo se ejecute en la // computadora local para que se desplieguen los resultados. paradis.stop(); java.lang.system.out.println(" And the answers are: "); for(var a in ans) { java.lang.system.out.println(a + ": " + ans[a]); }

67 Anexo B Manual de Usuario Existen dos partes fundamentales del framework paradis: el servidor (que es el nodo que inicia el cómputo de un script y va llevando cuenta del progreso de la operación, y los nodos cliente voluntarios, que se conectan al servidor a pedirle tareas cada determinado tiempo. El modo de uso del servidor es bastante sencillo, basta con ejecutar java -cp paradis.jar org.paradis.server nombre del script.js para ejecutarlo en modo distribuido o java -cp paradis.jar org.paradis.server -single nombre del script.js para ejecutarlo en modo de una sola instancia. Por defecto, se utiliza el puerto 8000 para comunicación entre nodos, pero se puede configurar agregando la bandera -p puerto a la línea de comandos. Para el caso del cliente, se hizo una pequeña interfaz gráfica para que los nodos voluntarios pudieran ejecutar en cualquier plataforma, en muchas ocasiones basta con hacer doble click sobre el archivo.jar. Dicha interfaz se puede apreciar en la figura B.1. En caso de no desearse utilizar la interfaz gráfica, se puede agregar el parámetro -console para ejecutarlo en modo de consola. Por defacto, el cliente intentará conectarse al host paradis-dasl4ltd.qro.itesm.mx, pero se puede cambiar agregando el parámetro -h hostname y el puerto mediante -p puerto. También es posible configurar el tiempo que espera el cliente entre peticiones vacías (i.e., cuando el servidor reporta que no hay tareas pendientes). La configuración por defecto es de un segundo, pero es posible cambiarlo con la bandera -s milisegundos. 55

68 56 Figura B.1: Screenshot de la interfaz de paradis