Tema anterior: solución de problemas
Página principal de la asignatura
Página del profesor
Página principal del grupo GeNeura

4. Selección y Configuración de Sistemas Informáticos: Benchmarking

Un benchmark es un programa o conjunto de programas que evalúan las prestaciones de un sistema informático reproduciendo una carga de trabajo genérica en dicho sistema informático. Al proceso de comparar dos o más sistemas mediante la obtención de medidas se le denomina benchmarking.

En general, para evaluar las prestaciones de un sistema informático es necesario conocer y caracterizar previamente cuál es la carga de trabajo, como se ha visto en temas anteriores. Sin embargo, en muchos casos tal carga no se conoce de antemano, es difícil de caracterizar o es suficientemente amplia como para considerarla una carga genérica.

Los benchmarks se agrupan en los denominados paquetes benchmark (benchmark suites), que agrupan diferentes programas para medir diferentes aspectos de un sistema informático. Para escoger o diseñar un buen paquete benchmark deben de seguirse los siguientes pasos [Puigjaner94]:

Todo esto corresponde a las fases en la evaluación de un sistema comentadas en el Tema1. Y, por supuesto, finalmente, se debe de llevar a cabo algún tipo de análisis. La presentación de muchos datos no permite extraer conclusiones: todas las mediciones se deben de resumir y sintetizar en una figura de mérito (FDM) que indique, básicamente, cuál es el mejor sistema en el objetivo que se ha marcado, como por ejemplo los índices SPECint (cuyo nombre definitivo está todavía por determinar) o BYTEmark usados por SPEC-CPU y Byte, respectivamente.

Los paquetes benchmark, y, en general, las cargas de trabajo de prueba deben de reunir una serie de características para cumplir su función adecuadamente:

Este tema se estructurará en las siguientes secciones: en la sección 2 se explicará en qué aplicaciones es necesario, para pasar a comentar en la sección 3 cómo se usan. En la sección 4 se estudiarán algunos paquetes benchmark habituales, para terminar con los problemas y críticas que reciben los benchmark en general en la sección 5.

  1. Localizar por internet, y aplicarlo a un par de sistemas (de los que tenga uno a mano, claro), benchmarks para medir la velocidad de una impresora, un lector de CD y una tarjeta gráfica,

Los benchmarks son usados por una gran cantidad de personas, sus resultados son también aprovechados por una amplia gama de profesionales, y, por tanto, la mayoría tienen cierto grado de oficialidad o estandarización. Las especificaciones para los mismos, las reglas para su ejecución y la ejecución física de los mismos se llevan a cabo de forma diferente; este aspecto se examinará en el apartado 4.1. De estas ejecuciones se tienen que extraer medidas que sirvan para comparar los sistemas, que se verán en el apartado 4.2. No siempre se llevan a cabo los benchmark de forma correcta, es habitual realizar una serie de errores que se contemplarán en el apartado 4.3; muchas veces estos errores se realizan intencionadamente, como se verán en los “juegos” examinados en el apartado 4.4. Finalmente, a veces son los benchmarks los engañados, como se verá en el apartado 4.5.

Dado que los benchmarks sirven para comparar sistemas informáticos, deben de tener amplia difusión, y, de hecho, todos los sistemas informáticos deben ser evaluados por el mismo benchmark, para que efectivamente puedan ser comparados. Para que este objetivo se lleve a cabo, los benchmarks suelen

El propio interesado puede llevar a cabo los benchmarks, siempre que los diferentes sistemas informáticos estén disponibles y cuente con los recursos suficientes para hacerlo. De esta forma, se pueden enfocar claramente los objetivos del estudio, y usar las métricas y resultados que más interesen; además, tiene sentido que los usuarios conozcan como aplicar y qué suelen medir los benchmarks más importantes. Estas métricas se explican en el apartado siguiente.

Hay diferentes tipos de benchmarks, dependiendo de cómo se representa la carga de trabajo.

Las unidades dependerán totalmente del objetivo del estudio y de qué nivel del sistema informático interese medir. Evidentemente, todas estas medidas reflejan las prestaciones de un sistema completo, puesto que es imposible separar los componentes para medirlos independientemente, aunque tratan de reflejar la eficiencia del sistema a este nivel. A continuación se enumeran las métricas usadas en diferentes niveles, aunque no todas se usan actualmente:

Es habitual, en benchmarks, establecer un sistema informático como base de comparación, de forma que, en vez de dar las cantidades absolutas de las medidas, se den tales cantidades referidas al sistema base. La mayoría de los índices presentados en las revistas de Informática y los consorcios de evaluación de prestaciones se hacen de esta forma. En otros casos, el índice de prestaciones incluye el precio del sistema informático, de forma que se puedan comparar no sólo las prestaciones, sino también la relación precio/prestaciones en el caso de que el precio del equipo sea un factor a tener en cuenta.

Independientemente de las métricas que se extraigan del experimento, un benchmark mide prestaciones a todos los niveles funcionales del sistema informático, y por lo tanto todos influyen en los resultados. Desde el sistema operativo, hasta el compilador, pasando por las librerías ya compiladas que se usen para la ejecución de los programas. Por ello hay que tener en cuenta y especificar cada una de ella junto con los resultados de la medición.

En el proceso de medición de las prestaciones de un sistema informático se pueden producir una serie de errores, debidos a la inexperiencia de los realizadores, o bien por no haber tenido en cuenta ciertos factores importantes en las prestaciones de un sistema. Los errores más habituales son los siguientes [Jain91]:

Mientras que estos errores son involuntarios, puede suceder que se cometan errores con el objetivo de probar que el ordenador que se está midiendo es mejor que el de la competencia. Es lo que se llaman juegos de benchmarking, como se verá a continuación.

Se puede afirmar de antemano que cuando una compañía dé un índice de prestaciones desnudo, sin indicar las condiciones en las que se ha llevado a cabo, está mintiendo. El decir, por ejemplo, que un microprocesador puede ejecutar 22 MIPS, necesita ser cualificado por el programa o conjunto de programas con los que se alcanza tal medida. En cualquier caso, hay otras muchas formas de engañar al público con los resultados de un benchmark, lo cual se ha venido a denominar benchmarketing [Jain91]:

Sin embargo, en la mayoría de los casos, es difícil engañar con los resultados de los benchmarks, ya que ni el código de los mismos ni la presentación de sus resultados están bajo control de los fabricantes. Por eso lo más práctico es engañar directamente al benchmark, como se verá en la siguiente sección.

  1. Mostrar en un benchmark publicado la existencia de alguno de estos juegos de benchmarking.

Dado que las decisiones de compra de muchos consumidores de material informático dependerán de las prestaciones del mismo, tal como han sido medidas por organizaciones, independientes, hay una gran presión para obtener los mejores resultados posibles. Ya que es difícil manipular los resultados, por la verificación a que éstos son sometidos, se intenta mani pular los ordenadores de forma que produzcan tiempos de ejecución mejor en los benchmark. Por supuesto, esto no tiene por qué manifestarse como una mejora de prestaciones en las aplicaciones reales que el ordenador va a ejecutar. Las formas más habituales en que se suelen producir estos engaños son los siguientes:

Precisamente por esta razón, la mayoría de los benchmark estándar cambian cada cierto tiempo. SPEC se revisa cada 3 años, y hasta ahora ha habido tres versiones: SPEC89, 92, 95 y 2000 (todavía están preparando la siguiente en el año 2005). De esta forma, cuando los fabricantes han aprendido a engañar un benchmark, se propone uno nuevo.

Hoy en día hay una serie de benchmarks, que están aceptados e incluso propuestos por la comunidad de fabricantes de ordenadores y estaciones de trabajo. La mayoría están propuestos por consorcios, como los SPEC, TPC y GPC, que se verán en las tres primeras secciones, aunque hay otros propuestos por editoriales de revistas del ramo, como el ByteMark y el WinBench, que se verán en las siguientes secciones. En cada caso, se examinarán qué tipo de razonamiento ha conducido a elegir la carga de trabajo, las métricas usadas, y las críticas que se han vertido sobre ellos, algunas veces por los mismos fabricantes que los han propuesto.

SPEC, que son las iniciales de System Performance Evaluation Cooperative, es un consorcio de fabricantes de microprocesadores, ordenadores y estaciones de trabajo. La misión de SPEC es principalmente desarrollar una serie de programas que se van a utilizar para medir diversos aspectos de las prestaciones de un ordenador, y publicar los resultados de esos tests según han sido proporcionados por los fabricantes.

SPEC consiste en realidad en tres grupos diferentes:

SPEC solo especifica los programas que se van a utilizar para medir prestaciones y la forma de ejecutarlos, pero no los ejecuta, sino que confía en los fabricantes para ejecutarlos, con la condición de que los resultados serán supervisados por SPEC, y se presentarán en su página Web: http://www.spec.org. En realidad, dado el carácter público de los benchmark, cualquiera puede ejecutarlos (siempre que el ordenador cumpla las características que se especifican en la página Web, como 256 MBs de memoria y 1 GBs de disco).

Los benchmark de SPEC han tenido diversas versiones, la última de las cuales es la SPEC2000; las versiones anteriores son la 89, 92 y 95; siempre hay que tener en cuenta la versión a la hora de comparar prestaciones, y se suele especificar.

La mayoría de los fabricantes de ordenadores incluyen en sus páginas Web las medidas SPEC de sus equipos, eso sí, con las críticas correspondientes y poniendo claramente de relieve donde sobresalen. Incluso se basan en los resultados dados en estos benchmarks para tomar decisiones de diseño con respecto a sus máquinas.

En concreto, SPEC95 se compone de dos grupos de programas: CINT95, 8 programas de cálculo de enteros intensivo (como se muestran en el cuadro 2), y CFP95, 10 programas de cálculo intensivo de coma flotante (como se ve en el cuadro 3).

Tras medir lo que tardan en ejecutarse estos programas, se dan una serie de cantidades, algunas relacionadas con la velocidad, y otras relacionadas con el throughput, es decir, el número de programas del mismo tipo que un ordenador es capaz de manejar. Por ejemplo, para SPECint, se dará lo indicado en el cuadro 4.

Todas las tasas son medias geométricas de los resultados obtenidos por cada uno de los diferentes métodos, no aritméticas. Estas medias geométricas se suelen utilizar cuando las prestaciones de los diferentes componentes no se suman, sino que se acumulan, como se verá más adelante. Y además, mantienen la relación entre los tiempos de ejecución de los benchmarks independiente de la máquina que se haya escogido para normalizar.

Tras medir lo que tardan en ejecutarse estos programas, se dan una serie de cantidades, algunas relacionadas con la velocidad, y otras relacionadas con el throughput, es decir, el número de programas del mismo tipo que un ordenador es capaz de manejar. Por ejemplo, para SPECint, se dará lo indicado en el cuadro correspondiente




Compilación


Conservador


Agresivo



Tasa



Velocidad


SPECint_base95

SPECfp_base95


SPECint95

SPECfp95


Throughput


SPECint_rate_base95

SPECfp_rate_base95


SPECint_rate95

SPECfp_rate95

Se miden un total de 72 cantidades. Cada programa se compila de dos formas diferentes, una conservadora, con una serie de restricciones (por ejemplo, no más de 4 flags de ejecución), y además igual para todos los programas y máquinas, y otra agresiva, en la cual se puede usar la máxima optimización permitida por la máquina y el compilador; a la vez, para cada programa se mide el tiempo que tarda en ejecutarse, y el tiempo que tarda en ejecutarse cuando se ejecutan el máximo número de copias simultáneas del programa.Todas las velocidades se normalizan con respecto a un sistema, que depende de la versión del benchmark.

Tanto en el caso de Cint como de Cfp, los índices de “velocidad” suelen medir la eficiencia monoprocesador del sistema, aunque tenga diferentes procesadores; los índices de throughput miden la eficiencia del sistema operativo en cambios de contexto, pero también la eficiencia del mismo distribuyendo la carga entre diferentes procesadores, y la eficiencia del acceso a la memoria compartida de los mismos, en el caso de sistemas multiprocesador. Los resultados son publicados cada trimestre en una publicación periódica, y en el sitio Web.

Dado que los rates afectan más al sistema operativo que a los resultados particulares de una compilación, y éste no cambia en los índices base y los agresivos, la inversión de prestaciones comentada anteriormente no se da en este caso.

En cuanto a los índices medidos según SPECfp, mostrados en las tablas 7 y 8, se observa una vez más los Alpha de Digital dominan la escena, acampanados esta vez por los UltraSPARC de Sun; evidentemente, las arquitecturas de HP están optimizadas para una carga de tipo comercial (representada o sintetizada por SPECint), mientras que las Sun lo están para cálculo científico. Y en cuanto a los índices de throughput, aparecen los IBM, junto con las Sun y SGI. En este caso, las arquitecturas con mayor número de procesadores son las que consiguen mayor throughput.

Algunos fabricantes de ordenadores, a pesar de usar estas medidas, suelen criticar algunos de sus aspectos: la principal crítica es que la media oculta los resultados individuales de cada uno de los tests; uno de los tests puede dar mejor resultado para una máquina A que para otra B y sin embargo, la media ser mejor para B; por ello se presentan, en los informes de revelación total, los resultados individuales, para que cada persona pueda mirar los resultados que le interesan.

Estos tests miden también sólo la combinación CPU/memoria/compilador, no el sistema completo, en el cual pueden influir mucho las prestaciones de entrada/salida o las de red; sin embargo, hay otros tests que pueden medir estos subsistemas; esto causa también que algunos fabricantes, como IBM, logren optimizar sus compiladores para que reconozcan en código SPEC y conseguir así mejores resultados. Además, los “_rate” miden las prestaciones de ordenadores ejecutando muchas copias del mismo programa, no diferentes programas, y por lo tanto son poco representativos de sistemas reales.

En general, hay que hacer un análisis pormenorizado de los resultados de cada uno de los benchmarks. En tal tipo de análisis, llevado a cabo por Sun, encontraron que el test más representativo es gcc, por tener código correspondiente a una aplicación real, un compilador usado en toda la gama de estaciones de trabajo, y ser además muy difícil de optimizar. Por otro lado, compress es uno de los que más exige al sistema, haciendo énfasis en el ancho de banda entre CPU y memoria, que es esencial en todas las aplicaciones.

En estudios llevados a cabo por Intel [Bekerman95], analizando cómo responden la jerarquía de memoria y el procesador (buffer TLB, cachés, pipelines U y V) a estos benchmarks, halla también que gcc y compress tienen una baja localidad de las referencias, haciendo que el número de veces que se tiene que acceder a memoria principal es bastante alto. Esto hace, una vez más, que sean bastante buenos indicativos de las prestaciones reales del ordenador. Por otro lado, los CPI (ciclos por instrucción) alcanzados en un Pentium con estos dos benchmarks son 2.62 y 2.15, respectivamente, a pesar del diseño superescalar, de dos pipelines de enteros y uno de números reales, que teóricamente le permitiría varias instrucciones por ciclo. Estudios similares se hacen en cada generación de las diferentes familias de microprocesadores, como por ejemplo en la tercera generación del PowerPC, denominada G3. En este modelo se incluyó un segundo pipeline de enteros tras examinar trazas de ejecución de diversos modelos anteriores.

En algunos casos, las medidas aportadas por los fabricantes son erróneas, como sucedió con los SPEC92 suministrados por Intel para el Pentium Pro a 200Mhz. A causa de un error en los compiladores usados, los resultados dados por uno de los tests eran exagerados. Más adelante, Intel tuvo que reducir el SPECint92 en un 10%. Lo que no consta es hasta qué punto el error era intencionado o no.



TPC (Transaction Processing Performance Council) es un consorcio que propone benchmarks en el área de procesamiento de transacciones. Hay varios benchmarks propuestos; hoy en día los más usados son TPC-C y TPC-D. Ambos tienen como entorno de referencia el siguiente: un sistema cliente, que genera peticiones de bases de datos usando un front-end, y un sistema servidor, que ejecuta el intérprete del lenguaje de bases de datos, generalmente SQL, y desde el mismo accede a un sistema de gestión de bases de datos. Cada transacción debe de ser atómica, es decir, se lleva a cabo o no completa, y además los sistemas deben de estar disponibles 24/7, 24 horas al día 7 días a la semana.

Estos benchmarks son de muy alto nivel, o más bien, ejercitan todos los niveles del sistema, desde la jerarquía de memoria, incluyendo memoria secundaria, pasando por el sistema operativo, hasta los programas que resuelven un problema concreto.

Las métricas que se proporcionan con estos benchmarks son de dos tipos: peticiones/tiempo, número de usuarios, y precio/prestaciones; hay unas reglas estrictas para evaluar éste último. Se verá a continuación cada uno de los benchmarks por separado.

Heredero de TPC-A y B, en este benchmark se mide el número de transacciones New Order se pueden generar por minuto mientras que l sistema está ejecutando peticiones de otros cuatro tipos (Pago, Estado de la Petición, Reparto, Nivel de Stock). Las cinco peticiones tienen deben de llevarse a cabo en un tiempo máximo determinado; NewOrder debe de durar 5 segundos como máximo.

Las métricas que se usan son tpmC (transacciones por minuto de tipo C) y $/tmpC, dividiendo las mismas por el precio total del sistema.

Similar al anterior, salvo que modela un sistema de apoyo a la decisión, lo que se ha dado en llamar data warehousing o data mining, es decir, peticiones complejas a bases de datos de gran tamaño. En este tipo de entornos suele haber más peticiones de lectura que de escritura, y además se suele acceder a una gran porción de la base de datos en una sola petición.

El entorno de experimentación consiste en responder a 17 peticiones, en diferente orden, mientras que en segundo plano se efectúan operaciones de inserción y borrado. Las órdenes están codificadas en SQL. Las bases de datos a las que se accede tienen diferentes factores de escala, indicados con una @; al proporcionar las prestaciones hay que indicar el factor de escala, y no se pueden extrapolar los resultados de un factor de escala a otro superior o inferior. Los resultados obtenidos por TPC tienen valor de certificación; generalmente suelen ser bastante onerosos para una empresa, y a veces incluyen una auditoría por parte de una empresa independiente.

TPC-D tiene tres métricas, dos de prestaciones y una de precio/prestaciones:

De esta última métrica, se obtiene una métrica precio prestaciones. Por ejemplo, si el coste de un sistema es 5 millones de dólares, se ha tomado las mediciones para una base de datos de 100 GB, y se ha obtenido un índice QphD@100GB de 141.42, la métrica precio-prestaciones será 35.335'34$/QphD@100 GB. Otros índice se muestran en la tabla 9.

Dada la importancia comercial que tienen estos benchmarks, hay algunas empresas que han vertido críticas sobre ellas, atendiendo sobre todo a que no representan realmente la carga de trabajo generada por un sistema de toma de decisiones. Otra crítica es que son demasiado caros, costándole a una empresa del orden de un millón de dólares. Por tanto, algunas empresas proponen medir también el proceso de carga, la realización de consultas y los procesos de análisis.

SPECWeb2005 (http://www.spec.org/osg/web2005/) es la última versión de un benchmark que se concibió originalmente en el año 95; es un benchmark sintético para medir las prestaciones de sistemas como servidores web. Inicialmente incluía sólo páginas estáticas, pero hoy en día ha cambiado mucho. Tiene las siguientes características:

El resultado principal de este benchmark es lo que se denomina "conexiones simultáneas conformantes", es decir, peticiones simultáneas que es capaz de manejar; se suele repetir tres veces y se da la mediana de los tres resultados como resultado válido.

Al principio, este benchmark recibió bastante atención por parte de los medios; por ejemplo, este artículo cuenta como se triplica prácticamente, sobre la misma máquina, las prestaciones de un servidor RH Linux sobre un servidor IIS. Sin embargo, mirando un poco de más cerca, vemos a qué se puede deber esta ventaja. El servidor que usa el sistema RedHat es Tux, denominado actualmente Red Hat Content Accelerator, un servidor que se ejecuta como tarea en el kernel, en un sistema exclusivamente dedicado a eso (prácticamente). De hecho, los servidores web más potentes no suelen ser los más conocidos.

De hecho, el uso de este servidor web es relativamente irrelevante, ni siquiera aparece en el informe de servidores web. Por lo tanto, el hecho de que se use o no este servidor puede ser totalmente irrelevante para un caso real, donde los servidores van a ser probablemente el Apache o el IIS. Al parecer, la imposibilidad de superar a este servidor en los benchmarks ha hecho que la gente pase de ejecutarlo sobre sus máquinas, y probablemente conducirá a la revisión del mismo (igual que sucedió con el SpecWEB96, que tuvo que ser revisado por la introducción por parte de Sun del Network Caché Accelerator, un módulo del kernel que metía las páginas estáticas en un buffer de la memoria del kernel).

Otra opción puede ser el ApacheBenchmark, que está incluido en la distribución del servidor Apache, o el httpPerf. Con el primero obtenemos los siguientes resultados sobre el servidor de la UGR: Benchmarking www.ugr.es (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Finished 1000 requests Server Software: Apache Server Hostname: www.ugr.es Server Port: 80 Document Path: / Document Length: 64264 bytes Concurrency Level: 200 Time taken for tests: 75.859298 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 64502000 bytes HTML transferred: 64264000 bytes Requests per second: 13.18 [#/sec] (mean) Time per request: 15171.860 [ms] (mean) Time per request: 75.859 [ms] (mean, across all concurrent requests) Transfer rate: 830.35 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 73 35.9 72 420 Processing: 213 13429 3599.7 14743 28977 Waiting: 72 7153 4293.8 7177 14602 Total: 354 13502 3598.7 14815 29031 Percentage of the requests served within a certain time (ms) 50% 14815 66% 14907 75% 14947 80% 15003 90% 15119 95% 15456 98% 15957 99% 16414 100% 29031 (longest request)

Y sobre el de la escuela se obtienen los siguientes resultados (con 100 peticiones, porque da un timeout con 1000). Por supuesto, no se han puesto aquí para compararlos, porque son servidores y sistemas muy diferentes, pero se puede observar que el tiempo que necesita el servidor de la escuela para servir una petición es aproximadamente 5 veces mayor que el de la UGR. Un documento sobre hacer benchmarks sobre servidores estáticos se encuentra en la web (http://www.xenoclast.org/doc/benchmark/HTTP-benchmarking-HOWTO/), junto con algunas pistas sobre como mejorar las prestaciones de los mismos.

  1. Aplicar los benchmarks de medición de prestaciones sobre un ordenador conocido con dos servidores web diferentes (por ejemplo, el apache que viene de serie con Linux, y si tiene arranque dual, el IIS); o bien, aplicar la medición de prestaciones a dos servidores web conocidos y explicar los resultados en función de lo que se conozca del mismo (OS que usa, tipo de ordenadores, disposición de los mismos...)

BYTEmark es un conjunto de pruebas creada por la revista Byte, y ejecutada por la propia revista sobre cualquier ordenador que se le ponga a mano. Los programas utilizados son de dominio público, y están accesibles desde la página Web de Byte. El documento que describe BYTEmark está en http://www.byte.com/bmark/bdoc.htm.

BYTEmark pretende ser un test estándar para todo tipo de sistemas, y por ello consiste en una serie de programas escritos en ANSI C. Esto significa que evalúa tanto la CPU/FPU y memoria como la eficacia del compilador; el razonamiento de Byte es que si el compilador es malo y genera malos programas, también sufrirán los demás programas que se ejecuten en la misma plataforma. A su vez, se suelen dar dos resultados, uno de enteros y otro de coma flotante.

Las ventajas que tiene este test es que se ha diseñado para que sea escalable y multiplataforma, y fácil de usar en ordenadores personales. Se dan tanto los resultados “crudos”, es decir, el número de “iteraciones” del test, y además la relación con respecto a una máquina “base” (inicialmente un Dell con un Pentium a 90 MHz).

Clasificación numérica

Clasifica una matriz de enteros de 32 bits

Clasificación de cadenas

Clasifica cadenas de longitud arbitraria

Campo de bits

Ejecuta funciones de manipulación de bits

Emulación coma flotante

Un paquete de coma flotante

Coeficientes de Fourier

Rutina de análisis numérico para calcular aproximaciones en serie de ondas

Algoritmo de asignación

Asignación de tareas

Compresión de Huffman

Algoritmo de compresión de texto y gráficos

Encriptación IDEA

Algoritmo de cifrado por bloques

Red neuronal

Simulación de un perceptrón multicapa con retropropagación

Descomposición LU

Algoritmo robusto para resolver ecuaciones lineales

Uno de los principales problemas a los que se enfrentó este benchmark fue cuando se informó que el Pentium era más rápido que el Pentium Pro ejecutando código de 16 bits. Esto se debió a un error del compilador, que hacía que el programa fuera más lento cuando se asignaba memoria con la función malloc()sin alinear el bloque a un grupo completo de 4 bytes. En versiones posteriores, se corrigió el error.

Este benchmark lo usa la revista como base de todas las comparaciones, aunque habitualmente va corregido por un multiplicador, para que el índice tenga en cuenta otros factores, como usabilidad, y relación precio/prestaciones. Esto es bastante razonable, pues sólo la velocidad no debe ser el único factor a la hora de comparar diferentes ordenadores.

Este benchmark (cuyos resultados están disponibles en una página web de la U. Viena: http://www.complang.tuwien.ac.at/misc/doombench.html), se podría considerar una carga sintética natural, más que una carga artificial ejecutable, como en el caso de los demás benchmarks. Consiste en ejecutar el conocido juego Doom, en modo demo, y medir el tiempo empleado. El propio programa proporciona el número de gameticks y el número de realticks, cuantos menos de estos últimos se obtengan, más rápido es el sistema. El benchmark especifica cual es la versión de Doom (1.9) que se debe usar, y los demás parámetros: tamaño de pantalla, tarjeta de sonido, teclado y ratón.

Este tipo de benchmarks dan resultados más realistas que los programas sintéticos, teles como 3DBench, ya que ejercita todas las capacidades del sistema, incluyendo el subsistema gráfico. Doom incluye aplicación de texturas en tiempo real, rendering de polígonos y sombreado de Gouraud, y por lo tanto es más complejo que el simple dibujo de polígonos de algunos otros benchmarks. Además, evidentemente, gran número de programas ejecutados en sistemas personales son juegos similares al Doom, y por tanto los resultados son más realistas que en el caso de benchmarks artificiales.

Según los resultados, publicados en el Web, el sistema más rápido para ejecutar Doom es una SGI-Indy, con el microprocesador MIPS R4600 a 133 MHz, seguido por varios sistemas con el microprocesador AMD K6, SPARC, Pentium Pro 233 Mhz, y Pentium MMX.

Hoy en día, la mayoría de los productos de Id Software incluyen demos que se pueden ejecutar desde la consola tecleando timedemo. Muchos otros también tienen facilidades similares

  1. Ejecutar un benchmark sintético, tal como el mencionado anteriormente, sobre algunos sistemas y presentar y comentar los resultados.

Los benchmarks, por su propia naturaleza, tienen una serie de problemas. Mientras que los benchmarks se supone que son suficientemente representativos como para comparar diferentes sistemas, esto no siempre es cierto. Los principales problemas que se plantean son los siguientes

Los siguientes sitios Web contienen o bien información sobre benchmark, o programas de dominio público que se pueden usar para llevarlos a cabo.

Como libro dedicado específicamente al benchmarking, aconsejamos: Performance Evaluation and Benchmarking with Realistic Applications, editado por Rudolf Eigenmann, un conjunto de artículos dedicados sobre todo al análisis de los benchmarks de SPEC.

Licencia de Creative Commons
Esta obra está bajo una licencia de Creative Commons.

Realizado por
Juan Julián Merelo Guervós jmerelo at geneura.ugr.es
Depto de Arquitectura y Tecnología de Computadores
Universidad de Granada
URL:http://geneura.ugr.es/~jmerelo/DyEC/Tema4/DyEC-Tema4.html