Dhrystone

El Dhrystone es un pequeño benchmark sintético que pretende ser representativo de programación entera de sistemas. Está basado en estadísticas publicadas sobre uso de particularidades de los lenguajes de programación, sistemas operativos, compiladores, editores, etc.

La publicación original de este benchmark se puede ver en CACM 27,10 (Oct. 1984), 1013-1030, por Reinkol P. Weicker de Siemens-Nixdorf Information System. Originalmente fue publicado en ADA, aunque hoy en día la mayoría utiliza la versión en C distribuida por Rick Richardson. La versión 2 fue publicada en SIGPLAN Notices 23,8 (Ago. 1988), 49-62, junto con las reglas de medición y en tres lenguajes: Ada, C y Pascal. Meses después salió la última versión: la 2.1. La versión 1 ya no se recomienda debido a que los compiladores actuales pueden eliminar mucho del "código muerto" del benchmark (sin embargo, los números MIPS citados son frecuentemente extraídos de la versión 1). Su nombre representa un juego de palabras con su antecesor: el Whetstone ("wet" = mojado, "dry" = seco), su antecesor en el sentido de que fue también una mezcla representativa basándose en programas existentes, pero los datos eran de programas científicos en lugar de comerciales. Uno de sus usos actuales es como de otros benchmarks; sin embargo, su escasa representatividad y su alta sensibilidad frente a compiladores y optimizaciones desalientan su uso. Es un benchmark sintético y comercial. Resultado: Intenta medir la velocidad del sistema en cuanto a rendimiento no numérico, expresando los resultados en DPS (instrucciones Dhrystones Por Segundo). El rendimiento de Dhyrstone se calcula a partir de la siguiente fórmula: Iteraciones Dhrystone por segundo = reloj del procesador * número de pasadas / tiempo de ejecución. Para que el resultado sea válido el código Dhrystone debe ser ejecutado al menos por dos segundos.

Características

Contiene muchas instrucciones simples, llamadas a procedimiento y condicionales, y pocas de coma flotante y bucles. No realiza llamadas al sistema. Usa pocas variables globales y ejecuta operaciones con punteros. Está compuesto por 12 procedimientos incluidos en un bucle de medida con 94 sentencias. No se puede variar su tamaño. Está compuesto por un 53% de instrucciones de asignación, 32% de instrucciones de control y un 15% de llamadas a procedimiento. Dhrystone es compacto (no más de 1,5 KB), ampliamente disponible en el dominio público, y sencillo de ejecutar. Por ser tan pequeño el Dhrystone entra completamente en la caché interna, de esta manera no mide el resto del sistema pero presenta la ventaja de que mide solamente la capacidad del procesador para trabajar con enteros. El Dhrystone compara el rendimiento del procesador usando una máquina de referencia: la VAX 11/780 es la máquina que corre a 1 MIPS (logra 1757 Dhrystones por segundo). No se puede parametrizar, a diferencia del Whetstone donde los distintos tipos de instrucción están en bucles, aquí los mismos no existen por lo que no se puede cambiar la importancia de cada tipo de instrucción alterando la cantidad de veces que se itera cada bucle.

Problemas

Un considerable porcentaje del tiempo se gasta en funciones de manejo de cadenas de caracteres, lo que hace al test muy dependiente de la manera en que estas operaciones son ejecutadas (como ser código en línea, rutinas escritas en lenguaje ensamblador, etc.). En pocas palabras, es muy susceptible a optimizaciones de rutinas críticas por los fabricantes. El Dhrystone en realidad lo que refleja es más bien el rendimiento del compilador y sus bibliotecas que el procesador en sí mismo. Particularmente Dhrystone contiene dos instrucciones en las cuales el lenguaje de programación y su traducción se llevan el mayor tiempo de ejecución: una asignación de cadena de caracteres (en el procedimiento Proc_0 / main) y una comparación de cadena de caracteres (en la función Func_2). En la VAX 11/785 con el Berkeley UNIX (4.2) los compiladores consumieron 23% del tiempo en estas funciones de cadenas de caracteres. En máquinas RISC (donde se gasta menor tiempo en secuencias de llamadas a procedimiento que en la VAX) y con mejores compiladores optimizadores, el porcentaje varía del 21% al 65%, claramente por encima de las aplicaciones típicas de hoy en día. Es muy difícil que existan aplicaciones que posean una proporción tan importante de uso de bibliotecas de C o incluso de llamadas a bibliotecas específicas. El manejo de cadena de caracteres es muy distinto en Ada y Pascal, donde estas son parte del lenguaje, es por esto que ejecutar en C siempre otorga resultados peores y que se consume tanto tiempo en ellas (fue diseñado considerando las habilidades de Ada para manejarse).

Falta de certificación

No existe un proceso de certificación necesario para citar los resultados del Dhrystone. Esto es una ventaja en cuanto a la facilidad de trabajar con los resultados, pero una desventaja por el hecho de que uno debe examinar bien estos resultados cuando son externos antes de llegar a alguna conclusión.

Eficiencia del compilador

Es clave en el Dhrystone la dependencia del compilador y la tecnología de biblioteca usada - mucho más que cualquier otro benchmark. Se han encontrado diferencias de hasta un 100% con la misma máquina pero diferentes compiladores ANSI C En lugar de usar el formato normal de Kernighan & Ritchie (K&R) muchas veces el código es alterado para cumplir con los formatos ANSI. Este cambio puede otorgar mucha más información para el compilador, lo cual redunda en una mejor optimización.

Combinar los Archivos Fuente

Combinar los dos archivos fuentes en un módulo habilita al compilador a ejecutar optimizaciones adicionales en todas las funciones simultáneamente.

Código Inline

Habilitar el inline de procedimientos puede mejorar el rendimiento. Con la disponibilidad del ANSI C la definición de la función de cadena de caracteres no era parte del lenguaje; ahora sí, con lo que se permite explícitamente poner inline a las funciones de biblioteca. La regla Dhrystone "No usar inline en procedimientos para Dhrystone" se refiere sólo al nivel de procedimientos del usuario y no al de rutinas de biblioteca.

Forma de medir el resultado

Se basa en el reloj del procesador y la cantidad de tiempo que se ejecuta es demasiado corta (algo más de 2 segundos). Adaptar las bibliotecas de C para que acelere el código de Dhrystone puede alterar los resultados del benchmark de forma drástica, aunque esto pueda influir negativamente en la performance de código típico.