En esta sección se muestran en la tablas 5.7 - 5.10 los tiempo obtenidos por cada algoritmo desarrollado. Para eso se ejecuta cada uno de los mecanismos de solución para un tablero con las mismas características en distintos procesadores. También por cada tiempo obtenido se lo compara con el tiempo que implica resolver ese tablero con la solución lineal.
Solución Tiempo resolución en segundos Tiempo resolución lineal en segundos Speed Up Manager sin divisiones dinámicas 66 137 2,07 Manager con divisiones dinámicas 77 1,78
Manager con lista de espera
77,2 1,78
MacBook Air, Intel Core i5, 1,3 GHz , 4 núcleos
Tabla 5.7: Resolución de un tablero N=8, C=8. Cantidad de hilos usados = 12.
Solución Tiempo resolución en segundos Tiempo resolución lineal en segundos Speed Up Manager sin divisiones dinámicas 48,6 103,409 2,12 Manager con divisiones dinámicas 54,64 1,89
Manager con lista de espera
52,2 1,98
Intel Core i5, 2.50GHz, 4 núcleos
Castellanos - Aguirre : Desarrollo de un solver paralelo aplicado a la resolución del puzzle Eternity II
Solución Tiempo resolución en segundos Tiempo resolución lineal en segundos Speed Up Manager sin divisiones dinámicas 25,06 86,7 3,46 Manager con divisiones dinámicas 33,7 2,57
Manager con lista de espera
32,1 2,7
Intel Core i7, 2,6 GHz , 8 núcleos
Tabla 5.9: Resolución de un tablero N=8, C=8. Cantidad de hilos usados = 24
Solución Tiempo resolución en segundos Tiempo resolución lineal en segundos Speed Up Manager sin divisiones dinámicas 7 114 16,28 Manager con divisiones dinámicas 56 2,03
Manager con lista de espera
35 3,25
Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz, 48 núcleos
Tabla 5.10: Resolución de un tablero N=8, C=8. Cantidad de hilos usados = 150. Dado los resultados se puede ver en las tablas 5.7- 5.10 que el algoritmo que obtiene mejores tiempos en recorrer todo el árbol de exploración es el “Manager sin divisiones”. Esta solución solo trabaja con la tareas creadas inicialmente por el generador de tareas y luego no agrega lógica adicional para obtener más subtrabajos sobre las tareas activas. Esto demuestra que la hipótesis inicial de agregar lógica adicional que permita dividir tareas que se encuentran en ejecución en subtrabajos que sirvan para alimentar a los distintos hilos ociosos no es favorable, al menos en los escenarios testeados, y por el contrario empeora los tiempos. Es posible visualizar tal situación en el caso del “Manager con divisiones dinámicas”.
Además por lo visto en el punto anterior, los tiempos razonables para testear resultados en este trabajo se consiguen usando como máximo tableros de tamaño N =9, estos estarán compuestos por una lista de 81 fichas distintas. Para estos tableros utilizados
Castellanos - Aguirre : Desarrollo de un solver paralelo aplicado a la resolución del puzzle Eternity II
el generador de tareas encuentra niveles debacktracking inicial que son óptimos para dividir
el árbol de exploración en una cantidad de tareas que permiten tener a los hilos la mayor parte del tiempo activos durante toda la ejecución. Tal situación queda demostrada en las tablas 5.3, 5.4, y 5.5 donde se puede ver que cuando el primer hilo se queda sin trabajos para continuar su ejecución y muere, el programa continúa hasta un segundo más con su ejecución y termina también. Entonces es coherente concluir que al agregar lógica y procesos de sincronización en la ejecución del sistema para poder generar nuevas tareas para los hilos que solo estarán ociosos durante un segundo, implica una sobrecarga de trabajo de parte de los hilos en ejecución, tanto del Master como de los esclavos, que no
justifica los potenciales beneficios a obtener.
Si se intenta entender por qué el “Manager con divisiones dinámicas” es la solución con peores resultados, es importante tener en cuenta que el generador de tareas y cantidad de hilos utilizados fueron ejecutados con los parametros optimos para la solución manager sin divisiones por lo explicado en el párrafo anterior. Por lo tanto sobre el final de una ejecución serán muchos los hilos que se encontrarán ociosos, los cuales van a estar solicitando a los hilos activos que hayan quedado que generen trabajos nuevos, cuando en realidad estos hilos activos también se encontrarán sobre el final de su ejecución y solo podrán retornar tareas cortas, que rápidamente serán consumidas por los hilos ociosos, creándose así un ciclo constante productor - consumidor sin beneficio alguno. Cabe destacar, como se aprecia en las figuras 3.8 y 3.9, que para niveles avanzados en el árbol de exploración la cantidad de nodos válidos que se puede visitar son muy pocos (1 o 2 máximo), por eso, no solo se estaría solicitando trabajos a un hilo próximo a terminar que entregará tareas muy cortas en tiempo sino que posiblemente sea el único camino que ese hilo podía continuar de manera exitosa. Lo que se obtiene en consecuencia es que el hilo activo va a delegar su único trabajo a otro hilo y a terminar su ejecución cuando quizás, se podría haber conseguido un mejor resultado si era ese hilo el que evaluaba todo el resto del árbol de exploración.
Este ciclo se soluciona con la implementación del “Manager con lista de espera”, explicado anteriormente en el capítulo 4.5, el cual va a tener la capacidad de diferenciar aquellos hilos que son óptimos para generar subtrabajos y aquellos que no se encuentren dentro de esta categoría se permitirá que terminen con su recorrido de forma normal. De todas formas se puede ver que si bien esta solución presenta mejoras en los tiempos finales del sistema, el costo que se debe pagar por tareas de sincronización, inicialización de hilos y generación de nuevos trabajos conduce a una solución con tiempos finales que no son totalmente beneficios.
Castellanos - Aguirre : Desarrollo de un solver paralelo aplicado a la resolución del puzzle Eternity II