DEC Tema 6 Selección y configuración de computadores: BENCHMARKING Benchmarks Para conseguir un buen paquete de programas benchmark se debe seguir los siguientes pasos: Los benchmarks son programas utilizados para medir el rendimiento de un sistema informático o de alguna de sus partes. Al proceso de comparar dos o más programas mediante la obtención de medidas se le denomina benchmarking 1. 2. 3. 4. Definiciones 1. 2. Determinar qué y por qué se quiere estudiar. Debe existir una relación directa entre las propiedades de los programas (benchmarks) y los parámetros a estudiar. Se debe estudiar la influencia de los elementos externos (S.O., compilador, caché) con los elementos a estudiar y comprobar la igualdad o no con todos los elementos objetivos del estudio. Se deben analizar los resultados para obtener conclusiones. Forma de evaluar las prestaciones de un sistema informático, en conjunto o sobre partes determinadas. Si el benchmark está estandarizado, los resultados se podrán comparar con los obtenidos en distintos sistemas. Conjunto de programas completos escritos en lenguaje de alto nivel extraídos de la carga real y que se consideran representativos de esta carga real. Uso de los benchmark: Adquisición de equipos. Sintonización de sistemas. Planificación de la capacidad de un sistema informático. Comparación de compiladores. Diseño de sistemas informáticos o de procesadores. 6.3 Factores que influyen en el benchmarking 1. El rendimiento puede depender del tipo y versión del sistema operativo que tenga instalado el sistema estudiado. Por ello se recomienda que las comparaciones se realicen sobre el mismo sistema operativo o en caso de no ser posible se aconseja que las características y parámetros de los sistemas operativos sean lo más parecidos posible. El compilador usado en la prueba es realmente un elemento determinante del rendimiento obtenido en el sistema, ya que, según la facilidad que tenga el compilador en generar código eficiente, el modelo de carga se ejecutará más o menos rápidamente. Los lenguajes de programación influyen ya que tienen facilidades diferentes en secuencias de llamadas, punteros, manejo de cadenas de caracteres, repercutirá directamente sobre los tiempos de ejecución. El sistema de librerías de ejecución, ya que, según sean éstas, las funciones que implantan serán más eficientes, disminuyendo el tiempo de ejecución. El tamaño de la memoria caché es un factor muy importante en los resultados de pruebas de medición del rendimiento, sobre todo cuando se usan programas de pequeño tamaño. Los tiempos de ejecución varían dependiendo de si el programa cabe entero en la caché o si no cabe y debe acceder a la memoria principal. Realizar una verificación de los resultados obtenidos, para que el usuario sepa que el benchmark se ha ejecutado correctamente. 2. 3. 4. 5. 6. 6.4 Errores comunes en el benchmarking a) b) c) d) e) alik Representar en la carga de test sólo los comportamientos medios. Las cargas de test o de prueba se diseñan para que sean representativas de la carga real, pero se suele representar sólo el comportamiento medio ignorando la varianza. En ciertas ocasiones, será necesario introducir la varianza. Controlar de manera inadecuada el nivel de carga. La carga de test dispone de varios parámetros que se pueden modificar para incrementar el nivel de carga en el sistema: 1. Incrementar el número de usuarios. 2. Decrementar el tiempo de reflexión de los usuarios, se trata de una de las opciones más sencillas de implementar. 3. Aumentar la demanda de servicio por usuario, cambia considerablemente la carga por lo que ya no resultaría representativa de la carga real. Ignorar los efectos de la caché. Las memorias caché son muy sensibles al orden de las peticiones, por ello cada vez es más necesario modelar de manera precisa el orden de las llegadas. Ignorar el overhead del monitor. No validar las medidas. Comprobación de las medidas y cualquier valor que no pueda ser explicado debe ser investigado. Se deben incluir en las medidas comprobaciones o test automáticos. 1 f) No asegurar las mismas condiciones iniciales. Cada ejecución del benchmark altera el estado del sistema, así por ejemplo, el espacio en disco se ve reducido y los registros de datos pueden ver modificado su contenido. g) No medir las prestaciones del transitorio. Llenado de la caché, carga de programa. h) Usar las utilizaciones de los dispositivos para comparar las prestaciones. Lo correcto es utilizar la productividad del sistema como índice de comparación. i) Recoger muchos datos pero no analizarlos adecuadamente. Estos errores se suelen cometer de manera involuntaria debido a la inexperiencia pero también puede darse que analistas experimentados cometan estos errores para demostrar así la superioridad de sus sistemas. 6.5 Benchmarking games EL proceso de benchmarking no siempre se lleva a cabo de manera honesta. A continuación se proponen algunos ejemplos que pueden llevar a que el resultado de un estudio de benchmarking sea erróneo: 6.6 Descripción de algunos benchmarks Se distinguen dos grandes grupos de benchmarks: Utilizar configuraciones diferentes para ejecutar la misma carga en dos sistemas. Las configuraciones pueden tener distinta cantidad de memoria, discos diferentes o número de discos. Los compiladores pueden estar diseñados para optimizar la carga. Escoger la carga de manera arbitraria, sin verificar su representatividad de las aplicaciones reales del sistema. Utilizar benchmarks muy pequeños, que dan un 100% de aciertos de caché, ignorando las posibles ineficiencias de memoria y de organización de caché. Realizar una traducción manual de los benchmarks para optimizar las prestaciones. A menudo es necesario traducir los benchmarks de manera manual para que sean ejecutables en los distintos sistemas. Las prestaciones pueden entonces depender más de la habilidad del traductor que del sistema bajo prueba. 1) Programas generales que son programas pensados y diseñados para estudios de evaluación de prestaciones. Por ejemplo: LINPACK, DRYSTONE, WHETSTONE. 2) Programas de aplicación que son programas extraídos de las cargas reales o programas tomados como benchmarks pero que se pueden encontrar como aplicaciones en los sistemas. ejemplo: QNAP2, SMPL, MCNP, GCC, TEX. Por otra parte tres paquetes de benchmark muy utilizados en la actualidad son: • SPEC (Systems Performance Evaluation Cooperative) • TPC (Transactions Processing Performance Council) • The perfect benchmark club 6.6.1 Programas LINPACK 6.6.2 DHRYSTONE alik Es uno de los benchmarks más utilizados en estudios sobre sistemas científicos y de ingeniería. Estos programas sirven funcionalmente para resolver sistemas densos de ecuaciones lineales, y los resultados de este benchmark deben interpretarse de acuerdo con la función que desarrollan. Sus principales características son: 1) Estos benchmarks ponen particular énfasis en el cálculo en coma flotante 2) Se trata de programas fácilmente vectorizables. 3) Dependen mucho de las librerías en tiempo de ejecución porque están gran parte del tiempo ejecutando unas rutinas llamadas BLAS (Basic Linear Algebra Subroutines) de las que hay dos tipos, las codificadas en ensamblador y las que lo están en FORTRAN. El programa fue escrito inicialmente en ADA y posteriormente fue traducido a C y PASCAL. Publicado en 1984. Se trata de uno de los programas más usados como benchmark y existen varias versiones. Sus principales características son: 1) Se basa en aspectos no numéricos de la distribución de características de lenguajes fuente como sistema operativo, compiladores, editores, etc. 2) El programa no tiene instrucciones en coma flotante en su bucle de medición, y tampoco realiza llamadas al sistema. 3) Gran parte del tiempo de ejecución del programa se gasta en funciones de manejo de cadenas de caracteres. 4) Tiene pocos bucles, por lo que el tiempo de ejecución depende mucho del tamaño de la caché. 5) Dispone de pocos datos globales, y su tamaño no puede variar como ocurre en el Linpack. 2 6) No tiene mecanismos para frustrar la optimización de los compiladores, con lo que, al comparar resultados, es importante tener en cuenta el nivel de optimización usado en las distintas pruebas. 7) El programa se compone de 12 procedimientos incluidos en un bucle de medida con 94 sentencias. Los resultados se dan en dhrystones/segundo (DIPS). 6.6.3 WHETSTONE 6.7 UNIDADES UTILIZADAS EN BENCHMARKING MIPS (millones de instrucciones por segundo). Una de las unidades más usadas. Se utiliza para comparar sistemas que usan la misma familia de procesadores, ya que las instrucciones no son las mismas entre procesadores de familias distintas. MFLOPS (millones de operaciones en coma flotante por segundo). Esta unidad se ve influida por aspectos tales como la variabilidad del tamaño del problema, además de no contemplar debidamente otras operaciones que no sean de coma flotante. MWIPS (MegaWhestone Instrucciones por segundo) o los DIPS (Dhrystones por segundo). Es una forma de hacer la medida independientemente de la máquina ya que lo que hace es fijar el número de veces que se ha ejecutado el programa y el resultado es el tiempo que ha tardado en su ejecución. Otra opción consiste en comparar los resultados de la ejecución usando como unidades los milisegundos, segundos, etc. Algunas de las unidades en las que se expresan los resultados de las pruebas de evaluación del rendimiento son: alik Fue el primer programa diseñado como benchmark. Inicialmente estaba escrito en ALGOL 60. Uno de los problemas que tiene el Whetstone es que no se dispone de una versión oficialmente controlada, Sus principales características son: 1) El programa está compuesto por una serie de módulos, cada uno de los cuales contiene sentencias de un tipo determinado. 2) El programa tiene un alto uso de operaciones y datos en coma flotante, ya que representa programas numéricos. 3) Gasta mucho tiempo en funciones de librerías matemáticas y, por tanto, influye si las librerías son compiladas previamente. 4) Usa pocas variables locales. 5) Debido a su pequeño tamaño habitualmente cabe en la memoria caché. 6) Los resultados normalmente se expresan en MegaWhestones/segundo (MWIPS). 3