5. Experimentos
6.5. Resultados de aplicaciones en servidores
6.5.7. Bayes Network Classifier (Bayes)
Las refactorizaciones también influyeron en esta aplicación. La Tabla 6.9 muestra una reducción del 19,44% para la versión de un solo thread y del 10,20% para la versión de múltiples threads. La Figura 6.8 también muestra estas mejoras gráficamente.
Para la implementación, la aplicación mapea cada entrada o punto de datos del conjunto de datos en una clase llamada Instance. Cada una de estas instancias se procesa para capacitar al clasificador de red Bayes y obtener el modelo. La información almacenada en esta clase es dinámica y puede variar según los modelos. El conjunto completo de instancias, que representa todo el conjunto de datos, se mantiene en otra clase llamada Instances. Es decir,Instanceses una colección de objetos deInstance, que proporciona los métodos para obtener o poner información en ella y está compuesta principalmente por una lista. Además, es posible conocer el tamaño del conjunto de datos a priori. Por lo tanto, la refactorización propuesta para este caso fue muy similar a la mencionada en la Subsección 6.5.6, es decir, eliminando la Lista y usando una matriz en su lugar. Dado que esta clase se utiliza de forma recurrente en la aplicación, el impacto que tuvo esta refactorización en el consumo final fue significativo.
6.5.8. Resumen
Nuestros resultados indican que las refactorizaciones y guías propuestas generaron re- sultados útiles después de refactorizar/desarrollar la aplicación Java, ya sea móvil o no. De forma similar a los dispositivos móviles, realizamos pruebas estadísticas para eva- luar la validez de nuestros experimentos. Los párrafos siguientes explican en detalle la información tomada en cuenta y la ejecución de prueba.
Aplicación Original vs refactorizada Variación de Energía Decremento de tiempo de ejecución At 0.01? At 0.05? At 0.01? At 0.05? FFT Single-thread " " " " Multi-thread $ $ " " MMULT Single-thread " " " " Multi-thread $ " " " KP Single-thread $ $ " " Multi-thread " " " " NQ Single-thread " " " " Multi-thread " " " " SA Single-thread " " " " Multi-thread " " " " GD Single-thread " " " " Multi-thread $ $ " " Bayes Single-thread " " " " Multi-thread " " " "
Cuadro 6.10:Significancia estadística de test en aplicaciones reales en servidores
12
Como se explicó anteriormente, la energía consumida por una versión de la aplicación (original o refactorizada) que emplea o no múltiples threads se calcula en función de dos factores: potencia activa (en Watts) y tiempo transcurrido en segundos. Para cada triple T=<a,v,th>, dondea∈ {FFT,MMult,KP,NQ,SA,GD,Bayes},v∈ {original,re f actored}
yth∈ {single−thread,multi−thread}, se obtiene una sola lista con las muestras de po- tencia activas después de ejecutar i iteraciones, más i tiempos individuales transcurridos. Estudiamos la fuente de las reducciones de energía ejecutando pruebas estadísticas para comparar, dado dos triplesT1=<a,′original′,th>yT2=<a,′re f actored′,th>, si hay di-
ferencias estadísticamente significativas en la potencia activa y los tiempos transcurridos. Para determinar la significancia estadística en potencia activa, tomamos las listas de muestras de potencia activa T1 y T2 y dado que ambas listas pueden diferir en longi- tud -por las diferencias en los tiempos transcurridos- ejecutamos el test two-tailed Mann- Whitney-Wilcoxon para datos no apareados. Para determinar la importancia en el tiempo transcurrido, y dado que ambas listas tienen la misma longitud (i muestras) y las mues- tras difieren entre sí en que se aplica un tratamiento (refactorización), usamos la prueba de two-tailed Wilcoxon para datos emparejados. La Tabla 6.10 muestra los resultados de la prueba en los niveles de significancia 0.01 y 0.05. Como observamos que los códigos reajustados (T2) tendían a exigir más potencia activa pero menos tiempo para ejecutar que los códigos originales (T1), como se muestra en la Tabla, probamos la significancia estadística del incremento de potencia activa y decremento del tiempo de ejecución de los códigos refactorizados sobre los códigos originales.
De la tabla anterior se confirma que, considerando los experimentos que usan códigos de un solo thread, las versiones refactorizadas demandaron más poder activo que las ver- siones originales (2-4% en promedio). La excepción a esta regla es KP, cuya versión refac- torizada tenía 3.72% menos de potencia activa que la versión original en promedio. Sin embargo, para códigos multi-thread, esta tendencia general no es válida y, de hecho, las versiones refactorizadas introdujeron reducciones promedio de potencia activa en com- paración con los códigos originales en cuatro casos, es decir, 0,70% (FFT), 13,83% (KP), 23,18% (SA ) y 0,65% (GD). Vale la pena señalar que estas reducciones de potencia activa introducidas por códigos refactorizados son significativas en los niveles de confianza 0.01 y 0.05. En conclusión, no hay un ganador claro en términos de potencia activa, y el con- sumo puede depender de la naturaleza algorítmica de las aplicaciones. Otra observación es que, como se esperaba, los códigos multi-thread exigieron mucha más potencia activa ([90.83-125.17] Watts en promedio) que los códigos de un solo thread ([63.36-72.66] Watts en promedio).
La Tabla muestra que todas las pruebas son significativas con respecto al tiempo de ejecu- ción y confirman que los códigos refactorizados se ejecutan más rápido que los códigos originales, excepto para la versión de múltiples threads de Bayes en la que la versión
refactorizada es 1.18% más lenta que la versión original. Aceleraciones obtenidas1(es de- cir, la versión original sobre el tiempo de la versión refactorizada) varió en [1.05-47.53] para las ejecuciones de único thread y [1.15-158.30] para las ejecuciones de múltiples th- reads. Por lo tanto, se puede ver el efecto multiplicativo y beneficioso de utilizar muchos threads para ejecutar código refactorizado sensible a la energía y, por lo tanto, muchos núcleos físicos en reducciones de tiempo en comparación con el uso de un thread/nú- cleo. En general, como se muestra en la Tabla 6.9, dichas reducciones de tiempo dieron como resultado ahorros de Joules promedio por iteración de alrededor de [69-39900] (un thread) y [134-61300] (multi-thread).