Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo






descargar 62.26 Kb.
títuloResumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo
fecha de publicación31.08.2015
tamaño62.26 Kb.
tipoResumen
e.exam-10.com > Derecho > Resumen
http://www.cps.unizar.es/imagenes/logocps.gif

Proyecto Final de Carrera

Ingeniería Informática

Curso 2010/2011

Render P2P:

Simulación de un KD TREE

Diego Ignacio Mallea Lobera

Director:

Juan Francisco Magallón Lacarta

Grupo de Informática Grafica Avanzada

Departamento de Informática e Ingeniería de Sistemas

Centro Politécnico Superior

Universidad de Zaragoza

Abril de 2010
A mis padres Jorge José y María Pilar Olga, y a mis hermanas Gabriela y Eugenia,

por insistirme en que termine mis estudios.

A mi novia Nadia,

por no reclamar el tiempo empleado.

A mis amigos de toda la vida,

por secuestrarme y impedirme que me centre en acabar la carrera.

Derechos de Autor

Los derechos de la presente obra perteneces a D. Diego Ignacio Mallea Lobera y al Dr. D. Juan Antonio Magallón Lacarta, del Departamento de Informática e Ingeniería de Sistemas del Centro Politécnico Superior de la Universidad de Zaragoza. Queda prohibida la reproducción total o parcial de esta obra, por cualquier medio, sin el permiso escrito de los autores.

Ficha Técnica

Proyecto fin de carrera

Título:




Autor:

D. Diego Ignacio Mallea Lobera

DNI:

72981973-Y

Promoción:

200?/2011

Especialidad:

Informática

Director:

Juan Antonio Magallón Lacarta

Departamento:

Informática e Ingeniería de Sistemas

Centro:

Centro Politécnico Superior

Universidad:

Zaragoza

Fecha

Abril 2011

Resumen

Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo.

Estas pequeñas estaciones con las que consultamos el correo o las cuentas de nuestras redes sociales, están la mayoría del tiempo sin aprovechar al máximo su poder de cálculo. Hace tiempo que programas como el SETI, Folding o figthAids entre otros aprovechan estos tiempos de baja actividad de nuestras computadoras para procesar en horas grandes cantidades de datos, las cuales requerirían de supercomputadoras que requieren de costosas inversiones y un mantenimiento tan costoso que solo grandes gobiernos u organismos pueden hacer frente.

Por otro lado tenemos que ámbitos tan dispares como el cine, los videojuegos, en la aeronáutica y un largo etcétera, se hace necesario el computar ingentes cantidades de datos con cálculos increíblemente complejos.

Un ámbito en el cual se tiene una serie de cálculos que se pueden paralelizar y tiene una complejidad tan alta que requiere de más de un computado, es el mundo de la animación 3D.

El presente proyecto busca evaluar los fundamentos básicos tras la producción de una animación 3D, en un sistema distribuido Peer to Peer.

En primera instancia se decidió el evaluar las búsquedas en arboles kd mediante el empleo de dicha red, para ello se decidió el implementar una red de dichas características para poder distribuir el cálculo y los nodos de la red.

Posteriormente se implemento una serie de algoritmos comúnmente empleados para la generación de dichas escenas animadas, búsquedas en kd-tree, modificando estos para poder realizar los cálculos de una manera distribuida entre los componentes de la red.

Según se avanzo en el estudio se hizo patente un hambre por evaluar e investigar las posibilidades de dicho sistema para nubes de volúmenes incurriendo en unas posibilidades de investigar las posibilidades de las mismas.

Tras el desarrollo del PFC, se puede concluir que el uso de redes P2P abre un sinfín de posibilidades y mejoras. Además la ampliación de dichos algoritmos del procesado de nubes de puntos a nubes de volúmenes abre posibilidades que congenian con técnicas de colisiones.
Contenidos

Capitulo - 1.Introducción 10

1.1.Preámbulo 10

1.2.Motivación 10

1.3.Objetivos 10

1.4.Estado del Arte 11

1.5.Estructura de la Memoria 11

Capitulo - 2.Planificación 13

2.1.Preámbulo 13

2.2.Ciclo de vida 13

2.3.Análisis de Riesgos 14

2.3.1.Alta complejidad en la implantación y comprensión 14

2.3.2.Lapsos de inactividad del proyecto 14

2.3.3.Incertidumbre de no poder cumplir con la funcionalidad adecuada 14

2.4.Conclusiones 14

Capitulo - 3.Contexto Tecnológico 15

3.1.Visión Global 15

3.2.Software y motores de Render 15

3.3.Limitaciones de los sistemas de render actuales 15

3.3.1.Granjas de Render Caseras: 15

3.3.2.Granjas de Render Profesionales: 17

3.4.Sistemas distribuidos de datos 17

3.4.1.Bases de datos Distribuidas 17

3.4.2.Tablas hash Distribuidas 18

3.4.3.Sistemas de índice centralizados 18

3.4.4.Sistemas personalizados 18

3.5.Estado de las técnica 19

3.5.1.Los algoritmos 19

Capitulo - 4.Descripción del sistema 20

4.1.Preámbulo 20

4.2.Diagrama del sistema 20

4.3.Estructura de cada nodo de render descentralizado 20

Capitulo - 5.Solución propuesta 21

5.1.Preambulo 21

5.2.Lenguajes de programación evaluados 21

5.3.Sistema de comunicación 23

5.4.Interfaz de Usuario 23

5.5.Almacenamiento de datos 24

5.6.Modelado de la solución 25

Capitulo - 6.Análisis de Medidas 26

6.1.Preámbulo 26

6.2.Medida de la Red 26

6.3.Tendencia de la escalabilidad 26

6.4.Tendencia de paralelizarían del sistema 26

6.5.Conclusiones 26

Capitulo - 7.Conclusiones 27

7.1.Preámbulo 27

7.2.Sobre la solución 27

7.3.Trabajo Futuro 27

7.4. Aplicación del PFC al mundo real 27

7.5.Valoración personal y conclusión final 27

Capitulo - 8.Bibliografía 28

8.1.Lecturas 28

8.2.Otros enlaces de interés 28

Figuras y Tablas

Capitulo - 1.Introducción

1.1.Preámbulo


En este capítulo se va a hacer una breve introducción de las motivaciones, los objetivos, el estado actual de las tecnologías implicadas en el proyecto. Además de dar una breve guía para navegar por la memoria del proyecto.

1.2.Motivación


Cuando inicie este proyecto las motivaciones eran bien claras. El usarlo como trampolín de aprendizaje de ciertos ámbitos tecnológicos que despertaban mi curiosidad. Sobre todo quería implementar mi propio sistema de compartición de datos y calculo al puro estilo P2P. También uní a este cometido los algoritmos del intricado mundo de de las imágenes sintéticas en 3D.

Según fue avanzando mi proyecto, se despertó en mí un afán por optimizar tanto los algoritmos como la aplicación al máximo explorando las posibilidades de las tecnologías de programación. Mis motivaciones fueron ampliándose en estos ámbitos. Con estas nuevas motivaciones y mis ideas iniciales emprendí la tarea de realizar una aplicación escalable y óptima que agrupase las mejores tecnologías a mí alcance.

1.3.Objetivos


Los objetivos del presente proyecto son los de realizar un estudio de los conceptos implicados en la realización de una granja de render distribuida con una estructura descentralizada.

Para ello abordare el análisis e implementación de una serie de algoritmos básicos, utilizados en el render.

Como no podía ser de otro modo, mis objetivos también fueron variando a lo largo de dicho proceso de aprendizaje. Dando un peso cada vez mayor al uso de tecnologías de programación.

Como colofón final he ampliado el enfoque de los algoritmos estudiados, realizando un estudio de los mismos para el tratamiento de volúmenes, vislumbrando todo un mundo de aplicaciones.

1.4.Estado del Arte


El render no es hoy en día un misterio, existen soluciones reconocidas que dan solución a esta tarea. De hecho uno puede comprar una solución que implica software y hardware optimizado para dicha tarea.

También hay soluciones que hacen uso de una infraestructura de red casera para dicho cometido, repartiendo el trabajo en nuestros equipos habituales cuando estos están inactivos.

En cuanto a la investigación de las técnicas de render existen infinidad de soluciones, con el paso del tiempo unos algoritmos se han hecho más populares al observarse que tienen un mejor rendimiento o dan unos buenos resultados, en la mayoría de las situaciones. Estos algoritmos tienen en común que se realizan infinidad de accesos a los puntos del espacio a procesar. Los más populares de ellos hacen uso de estructuras llamadas arboles kd. Dichos arboles tienen el objetivo de dividir el espacio de puntos con el objetivo de hacer a estos accesibles para el procesado y con ello usar un tiempo mínimo en realizar los cálculos.

Por último no se puede decir que un algoritmo es eficiente en todos los casos, ya que para determinadas situaciones siempre habrá una optimización u otro algoritmo que nos cumpla mejor nuestro objetivo.

1.5.Estructura de la Memoria


El presente documento sigue una estructura de capítulos descompuesta de la siguiente manera:

  • Capítulo 1: Introducción. Pretende mostrar la motivación de este documento, así como resumir brevemente el estado actual de las arquitecturas P2P y la computación grafica distribuida.

  • Capítulo 2: Planificación. Muestra los esfuerzos necesarios para la consecución de este proyecto.

  • Capítulo 3: Contexto tecnológico. Explica las tecnologías usadas, además de mostrar el proceso de aprendizaje seguido en ellas.

  • Capítulo 4: Descripción del sistema. Detalla los principales puntos a tener en cuenta del sistema, haciendo un análisis de las decisiones tomadas, los posibles riesgos y carencias.

  • Capítulo 5: Solución aportada: Describe la implementación realizada.

  • Capítulo 6: Ejemplos y test. Resume los resultados obtenidos.

  • Capitulo 7: Conclusiones. Realiza un análisis de los resultados obtenidos en el ámbito global del proyecto así como futuras ampliaciones.

  • Capítulo 8: Bibliografía. Presenta los distintos medios a los que se hace referencia en este documento de un manera detallada.


Capitulo - 2.Planificación

2.1.Preámbulo


En este capítulo se va a detallar la planificación llevada en el presente proyecto, las decisiones tomadas en dicha planificación, las rectificaciones, los riesgos y desviaciones observadas, así como las conclusiones de la misma.

2.2.Ciclo de vida


En el desarrollo del proyecto se decidió el uso de un ciclo de vida en espiral. Para ello se decidió el realizar tres ciclos completos con el fin de poder adaptarnos a los posibles contratiempos que pudiesen surgir.

Las fases de cada ciclo elegidas inicialmente fueron las siguientes:

  • Determinar objetivos: En esta primera fase plantearíamos unas metas.

  • Análisis de Riesgos: En esta segunda fase evaluaríamos los contratiempos que pudieran obstaculizar el completar correctamente las metas marcadas.

  • Desarrollar y probar: Llevaríamos las tareas necesarias para realizar las metas planteadas en la fase anterior.

  • Planificación Evaluaríamos el trabajo realizado en las fases de este ciclo.

Como no podría ser de otro modo los tiempos estimados en la planificación inicial se vieron alterados totalmente. Sobrepasando los tiempos planificados inicialmente.

Debido a condiciones laborales y personales el tiempo inicialmente planificado para las distintas tareas se alargó más de lo estimado. A ello hay que añadir que el primer prototipo fue un completo desastre.

Finalmente según se fueron sucediendo mas ciclos estos fueron dando una proyección mas real.

2.3.Análisis de Riesgos


En la realización del presente proyecto se pueden agrupar los riesgos evaluados durante las distintas etapas en estas tres categorías.

2.3.1.Alta complejidad en la implantación y comprensión


Ciertos algoritmos del sistema requieren un estudio altamente costoso en tiempo y complejidad. Además en la elaboración de los mismos se puede incurrir en fallos difíciles de detectar.

2.3.2.Lapsos de inactividad del proyecto


Debido a condiciones laborales y personales la dedicación total se hace imposible. Existe una clara posibilidad de incurrir en grandes periodos sin actividad. El reanudar dichos periodos de inactividad puede ser complejo y lento retomar la implantación y estudio del mismo.

2.3.3.Incertidumbre de no poder cumplir con la funcionalidad adecuada


Hubo una gran incertidumbre de si se podría realizar una implementación adecuada y optima.

2.4.Conclusiones


El ciclo de vida en espiral permitió realizar un mayor seguimiento del mismo permitiendo reevaluar el estado del proyecto dando una medida de progreso del mismo mas real, ya que debido a las complejidades encontradas se hacía muy difícil una planificación más convencional.

Como una mejora a tener en cuenta en futuros proyectos se hace patente el tener más en cuenta los tiempos de inactividad del proyecto como un riesgo mayor del estimado en primer momento, dificultando la viabilidad del proyecto.

Capitulo - 3.Contexto Tecnológico

3.1.Visión Global


A la hora de computar grandes cantidades de nubes de puntos, estos se reparten en una estructura de árbol kd. Esta estructura tiene como objetivo el ordenar los puntos del espacio para una optima búsqueda en el.

Cuando nuestra nube de puntos tiene unas dimensiones aceptables estas pueden ser procesadas por un único computador. Aun así, la cantidad de datos a procesar hace de este proceso una tarea costosa.

Cuando nuestra nube de puntos alberga una ingente cantidad de elementos, la tarea de procesarlo e incluso almacenarlos no puede ser llevada por una sola maquina, debido a que los recursos de las mismas son limitados. Con este hecho se hace patente la necesidad de compartir el procesado y el almacenamiento de dicha nube.

Lógicamente la distribución de los elementos nos resuelve esta limitación pero a su vez nos implica una serie de retos a superar.

3.2.Software y motores de Render


Actualmente existen reconocidas aplicaciones de modelado 3D y render populares tales como 3ds MAX y V-Ray que procesan en forma distribuida de manera sencilla y transparente para el usuario. Otro motor de render famoso es Mental Ray.

La última generación de motores de render, además de distribuir el proceso final en varios equipos o nodos de render, permite utilizar esta misma potencia de procesamiento para hacer el render en pantalla aplicando cambios en tiempo real. V-Ray RT es precisamente uno de estos tipos de software. Estas modificaciones sobre luces, cámaras, y posiciones de objetos, evita la necesidad de realizar múltiples renders previos de estudio, lo cual significa un ahorro muy importante de tiempo.

3.3.Limitaciones de los sistemas de render actuales

3.3.1.Granjas de Render Caseras:


Principalmente hay dos limitaciones básicas:

Los ordenadores deben estar disponibles por tiempo indeterminado, es decir, lo necesario para completar el proceso global de render.

La heterogeneidad entre los equipos, lo más usual, un entorno de oficina, obliga a esperar a que concluya el render en el equipo más lento para disponer del render completo.

3.3.2.Granjas de Render Profesionales:


Requieren de un entorno controlado, acondicionamiento de instalaciones para un alto rendimiento.

Sus instalaciones requieren de una compleja cantidad de elementos. Nodos de render, Switch de conectividad, Switch de monitoreo, Servidor de archivos, UPS, Servidor de backup. En conclusión requieren de una infraestructura específica y costosa.

3.4.Sistemas distribuidos de datos


Actualmente existen diversas maneras de almacenar datos de manera distribuida.

3.4.1.Bases de datos Distribuidas


Las bases de datos distribuidas nos permiten almacenar los datos en varias maquinas y/o volúmenes.

Ventajas

  • Refleja una estructura organizacional - los fragmentos de la base de datos se ubican en los departamentos a los que tienen relación.

  • Autonomía local - un departamento puede controlar los datos que le pertenecen.

  • Disponibilidad - un fallo en una parte del sistema solo afectará a un fragmento, en lugar de a toda la base de datos.

  • Rendimiento - los datos generalmente se ubican cerca del sitio con mayor demanda, también los sistemas trabajan en paralelo, lo cual permite balancear la carga en los servidores.

  • Economía - es más barato crear una red de muchas computadoras pequeñas, que tener una sola computadora muy poderosa.

  • Modularidad - se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin afectar a los demás sistemas (módulos).

Desventajas

  • Complejidad - Se debe asegurar que la base de datos sea transparente, se debe lidiar con varios sistemas diferentes que puden presentar dificultades únicas. El diseño de la base de datos se tiene que trabajar tomando en cuenta su naturaleza distribuida, por lo cual no podemos pensar en hacer joins que afecten varios sistemas.

  • Economía - la complejidad y la infraestructura necesaria implica que se necesitará una mayor mano de obra.

  • Seguridad - se debe trabajar en la seguridad de la infraestructura así como cada uno de los sistemas.

  • Integridad - Se vuelve difícil mantener la integridad, aplicar las reglas de integridad a través de la red puede ser muy caro en términos de transmisión de datos.

  • Falta de experiencia - las bases de datos distribuidas son un campo relativamente nuevo y poco común por lo cual no existe mucho personal con experiencia o conocimientos adecuados.

  • Carencia de estándares - aún no existen herramientas o metodologías que ayuden a los usuarios a convertir un DBMS centralizado en un DBMS distribuido.

  • Diseño de la base de datos se vuelve más complejo - además de las dificultades que generalmente se encuentran al diseñar una base de datos, el diseño de una base de datos distribuida debe considerar la fragmentación, replicación y ubicación de los fragmentos en sitios específicos.

3.4.2.Tablas hash Distribuidas


Las tablas de hash distribuidas son una clase de sistemas distribuidos descentralizados que proveen un servicio de búsqueda similar al de las tablas de hash, donde pares (clave, valor) son almacenados en el DHT, y cualquier nodo participante puede recuperar de forma eficiente el valor asociado con una clave dada. La responsabilidad de mantener el mapeo de las claves a los valores está distribuida entre los nodos, de forma que un cambio en el conjunto de participantes causa una cantidad mínima de interrupción. Esto permite que las DHTs puedan escalar a cantidades de nodos extremadamente grandes, y que puedan manejar constantes errores, llegadas y caídas de nodos.

3.4.3.Sistemas de índice centralizados


Implica una interacción con el sistema encargado de indexar la información muy férrea. Si estos sistemas caen, todo el sistema.

3.4.4.Sistemas personalizados


Implica la implementación de algoritmos de relación y mantenimiento a veces artesanales. La mayoría de las veces incurren en costosos tiempos de desarrollo, pudiendo caer en no abordar todas las posibles situaciones.

3.5.Estado de las técnica

3.5.1.Los algoritmos


El campo de los algoritmos usados en los sistemas de render está muy estudiado. Hoy en día se sabe cuáles son los mejores algoritmos y optimizaciones para procesar una escena 3D.

  • GOURAUD: Luz Ambiente y difusa

  • PHONG: Luz Ambiente, Difusa y especular.

  • RAYTRACING: Simular luz como rayo.

  • Mapeado de fotones: Montecarlo

  • BRAF: Radiosidad

En general el mundo de las imágenes sintéticas se parece a la receta de un cocinero. Para elaborar un fotograma de nuestra escena debemos mesclar distintos algoritmos con sus optimizaciones según el plato a realizar.

Por ejemplo cuando se quiere simular una escena donde hay una niebla, se hacen los ajustes pertinentes para poder optimizar su procesamiento al máximo.

Capitulo - 4.Descripción del sistema

4.1.Preámbulo


Nuestro sistema se va a encargar de evaluar una serie de algoritmos típicos del render permitiendo la distribución de los cálculos y los datos de una manera descentralizada.

4.2.Diagrama del sistema



4.3.Estructura de cada nodo de render descentralizado


Cada nodo de render deberá poder realizar las siguientes tareas.

Gestionar el almacenamiento de los datos.

Gestionar las comunicaciones.

Gestionar los cálculos.

Proveernos de un entorno para el monitoreo y control de la solución.

Capitulo - 5.Solución propuesta

5.1.Preambulo


Vamos a evaluar la solución propuesta. Para ello analizaremos las diferentes tecnologías existentes en el mercado y las decisiones que nos han llevado a adoptar unas frente a otras.

5.2.Lenguajes de programación evaluados


Los lenguajes evaluados han sido:

  • Java

  • C/C++

  • PHP

  • Delphi

  • Visual Basic, C#

  • LISP, SMALKTALK,…

Se ha optado por la implementación de una solución basada en java por tener los siguientes puntos a su favor:

  • Ser esta una plataforma de código abierta, lo cual redunda en un ahorro de gastos.

  • Ser multiplataforma, lo cual implica el poder llegar a un mayor numero de entornos.

  • Tener una gran cantidad de Apis y documentación, esto es sumamente importante a la hora de poder desarrollar nuestra solución con una complejidad lo menor posible.

  • Facilidad de aprendizaje e implementación. Otros lenguajes exóticos o bien carecen de la simplicidad de este lenguaje o no tienen una comunidad de la que nutrirnos de soluciones.

Como puntos en contra tenemos frente a una plataforma nativa:

  • Al ser un lenguaje que corre en una maquina virtual por lo que tiene un rendimiento menor que códigos nativos. Este hecho hoy en día se puede desmentir ya que diversos estudios demuestran que en rendimiento están más o menos empatados, siendo más importante las implementaciones.

  • Necesidad de instalación de maquina virtual.


5.3.Sistema de comunicación


En las comunicaciones de red se quería un sistema que fuera lo mas simple posible , obviándonos del duro trabajo de una implementación de cero, pero además que fuera lo suficientemente optimo para que dichas comunicaciones no representasen un problema elevado de rendimiento.

Las opciones evaluadas fueron:

  • RMI

  • WEBSERVERS

  • SOCKETS

  • RPC

El uso de webservers no cumplen con la necesidad de realizar unas comunicaciones lo mas optimas posibles al sobredimensionar en exceso las llamadas.

En el caso de los Sockets nos implica una implementación demasiado de bajo nivel. Aunque es bastante optima en cuanto a tamaño de datos.

En el caso de RPC, los que utilizan el estándar IDL tienen una alta compatibilidad pero su rendimiento depende en gran medida de la implementación realizada por cada uno de los actores en el juego.

Por otra parte, teniendo como gran contra el ser una comunicación cerrada al lenguaje Java, se opto por esta al estar lo suficientemente madura y aportar una simplicidad a nuestras comunicaciones.

El uso de RMI posibilita el envió de clases serializadas entre los actores.

Como previsión se ha decidido el dar modularidad el núcleo de la aplicación en previsión de poder en un futuro ampliar este con la incorporación de distintos módulos que den soporte a otras formas de comunicación.

5.4.Interfaz de Usuario


Entre las alternativas para interactuar en la aplicación tenemos las siguientes:

  • Línea de comandos

  • Entorno Web

  • Entorno de Escritorio

El uso de un entrono de línea de comandos se hace demasiado complicado para un usuario estándar.

Un entorno Web es muy interesante, en un principio se inicio su implantación. Proto se hizo patente de que eleva la complejidad de nuestra aplicación a niveles demasiado elevados y entorpece su distribución al público en general, al tener que instalarse un servidor de aplicaciones Web.

El uso de una solución de escritorio nos simplifico la implantación de la solución, permitiendo el uso de herramientas graficas para presentar los datos al usuario con unos costes medio de tiempo, frente a su implementación en un entorno Web.

Debido a las posibilidades del desarrollo futuro de un entorno Web para la supervisión de la aplicación se ha decidido implementar la estructura de la aplicación siguiendo el patrón de diseño MVC

5.5.Almacenamiento de datos


A la hora de utilizar una fuente de datos se nos presentan las siguientes alternativas:

  • Utilizar una base de datos

  • Utilizar Objetos con serialización estándar en Ficheros

  • Utilizar XML almacenados en Ficheros

  • Utilizar Objetos con serialización personalizada almacenado en Ficheros

EL uso de una base de datos implicaría el uso de un gestor de BD, que aunque hay gestores incrustados en aplicaciones nos

Utilizar XML almacenado en ficheros nos sobredimensiona el tamaño de los datos, ocupando demasiado la estructura del formato frente al elemento a almacenar.

El uso de una serialización estándar nos ocupa una memoria reducida pero esta puede ser mejorable.

El uso de una serialización personalizada nos permitiría un uso óptimo de los recursos.

Finalmente se ha optado por una serialización personalizada con el fin de optimizar el uso de la memoria.

5.6.Modelado de la solución


Se ha decidido modelar la solución dando un soporte modular a nuestra implementación. Para ello se ha decidido dividir la solución en tres proyectos al más puro estilo MVC.

Primero tendremos la implementación del modelo. Tiene el objetivo de proveer de un modelo de datos al sistema. Este modelo modelara un interfaz común para alimentar al sistema permitiendo la integración de nuevas implementaciones que permitan el aumentar las posibilidades del mismo manteniendo la compatibilidad con versiones anteriores.

En cuanto al controlador tendrá una estructura modular. Esta tiene el fin de poder escalar las comunicaciones permitiendo proveer de nuevos medios de integración. Además de permitir la modificación del sistema de almacenamiento o computación.

El separar la vista del controlador nos permitirá poder adaptar la solución a otros medios como puede ser una página web o una consola de comandos.

Capitulo - 6.Análisis de Medidas

6.1.Preámbulo


Para evaluar el sistema, debemos calcular una serie de medidas, para poder ver la viabilidad del mismo.

  • Medida de red

  • Tendencia de la escalabilidad.

  • Tendencia de paralelización del sistema.

6.2.Medida de la Red


Indica el tamaño que tiene que tener el modelo para poder ser interesante ser modelado en un sistema de red compartida.

6.3.Tendencia de la escalabilidad


Muestra la tendencia del sistema según este se va escalando.

6.4.Tendencia de paralelizarían del sistema


Nos indica el grado de paralelización promedio de un sistema según este va creciendo.

6.5.Conclusiones


Comprobamos que el rendimiento de procesar os datos en un solo equipo es mayor al de procesarlo en varios equipos, debido a las latencias de red. Pero este hecho deja de sernos un factor decisivo cuando nuestro sistema toma unas dimensiones que no pueden ser albergadas en un solo equipo.

Capitulo - 7.Conclusiones

7.1.Preámbulo


En este capítulo se hará un análisis y resumen de las conclusiones sonsacadas en este proyecto.

7.2.Sobre la solución


Se ha comprobado la viabilidad real de una solución de render distribuida y descentralizada.

Frente a soluciones profesionales según las medidas calculadas se demuestra que el sistema pude mejorar el uso de una solución profesional. Esto es posible cuando los datos a computar son elevados y nuestro sistema tiene una escala enorme.

7.3.Trabajo Futuro


Como trabajo futuro queda la implementación de un sistema de gestión y monitoreo web.

La implantación de un sistema de cálculo de colisiones utilizando la estructura estudiada.

7.4. Aplicación del PFC al mundo real


Las aplicaciones del proyecto al mundo real son bien claras. Cualquier estudio famoso podría utilizar su estructura interno de ordenadores sin colapsar las comunicaciones al ser estas descentralizadas, evitando el cuello de botella de una red centralizada. Además al estar la información descentralizada con redundancia nos evitamos problemas de pérdidas de datos. Además no hace falta proveer al servidor centra de una gran capacidad de red y almacenamiento, al no existir este.

7.5.Valoración personal y conclusión final


Es una alternativa viable e interesante. No hay que menospreciar la escalabilidad de estos sistemas. En cuanto al mundo de los algoritmos estos todavía pueden recibir muchos enfoques sorprendentes.

Capitulo - 8.Bibliografía

8.1.Lecturas

8.2.Otros enlaces de interés


[1] Cálculo distribuido, computación distribuida, grid computing

http://www.arrakis.es/~alfema/calculo_distribuido.html

[2] Comparación entre métodos de acceso espaciales y de puntos multidimensionales.

http://www.ing.ula.ve/~ibc/maemp.pdf

[3] Optimización del Cálculo de Colisiones para Mallas deformables mediante Voxelización de Primitivas.

http://www.gmrv.es/~jgascon/papers/ceig08.pdf

[5] Java vs C (rendimiento)

http://www.sargue.net/2005/10/java-vs-c-rendimiento.html

http://blog.cfelde.com/2010/06/c-vs-java-performance/

[5] Render en Granjas

http://cadstock.com/articulo.php?id=244

[5] Bases de Datos Distribuidas

http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas

Añadir el documento a tu blog o sitio web

similar:

Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo iconResumen Hoy en día, se puede afirmar que el acceso a computadoras...

Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo iconResumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de

Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo iconResumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran

Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo iconResumen Hoy en día, se puede afirmar que el acceso a co

Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo icon¿Qué es Wikipedia? En la universidad posiblemente no haga falta responder...

Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo iconUn circuito rectificador es un circuito que convierte potencia de...

Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo iconEl emprendimiento hoy en día, ha ganado una gran importancia por...

Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo iconLos ingenieros en informática son los profesionales más demandados...

Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo iconHoy ha sido el primer día, y al no conocer a la profesora, nos ha...

Resumen Hoy en día, se puede afirmar que el acceso a computadoras con una gran potencia de cálculo está al alcance en nuestros hogares o puestos de trabajo iconResumen para el desarrollo de esta guía fue de gran comprensión el...




Economía


© 2015
contactos
e.exam-10.com