Capítulo 3

Caracterización de la carga: benchmarks



3.1 Introducción


Se puede definir carga como la demanda de recursos del sistema que realizan los usuarios en un intervalo de medición determinado.

Para medir la carga se usan los programas denominados monitores, vistos anteriormente en el capítulo 1. Sin embargo, interesa caracterizar la carga cuantitativamente para definir de forma objetiva la utilización de un sistema por parte de los usuarios. El objetivo de esta caracterización es conseguir reproducirla para evaluar ese sistema con un fin determinado. Evidentemente, una carga de un sistema particular es difícil de reproducir, pues para empezar varía en el tiempo, y, además, la carga interacciona con el sistema de modo bastante impredecible, por lo cual la interacción con un nuevo sistema no tiene por qué ser la misma.

Por ello, para caracterizar una carga es primero necesario definir los objetivos de la caracterización: en función de ellos, se determinan los parámetros que se tienen que medir y su representación. Algunos de los parámetros a medir pueden ser, por ejemplo:

Tiempo de CPU.

Número de operaciones E/S, distribuciones de las operaciones.

Uso de la memoria.

El objetivo de este capítulo es ver los métodos que se usan para reproducir una carga de prueba, es decir, los métodos de creación de una carga que, de alguna forma, reproduzca el consumo de recursos de un sistema determinado. Esta carga de prueba debe de tener las siguientes características principales:

reproductibilidad: que sea fácil de reproducir para cualquier tipo de sistema.

compacidad: que contenga poco código, y que no sobrecargue el sistema ni tarde demasiado tiempo en ejecutarse.

compatibilidad: esta es la característica más importante. La carga de prueba debe de ser compatible con todos los sistemas que sean susceptibles de ser medidos. Se verá más sobre este tema en el apartado de benchmarks.

escalabilidad: es decir, que el mismo benchmark sirva para ordenadores con una gama amplia de velocidades, que siga siendo útil a lo largo del tiempo, y que de resultados significativos, o sea, que sirvan para diferenciar las prestaciones de los sistemas que se evalúan.

En resumen, para crear un benchmark estándar se suelen seguir los siguientes pasos:

  1. Establecimiento de los objetivos del estudio.
  2. Estudio de la carga del sistema o sistemas que se van a tratar.
  3. Creación o elección de una serie de programas que sirven para medir tales prestaciones.
  4. Análisis y presentación gráfica de los resultados.


3.2 Cargas de prueba


Mientras que el establecimiento de los objetivos de un análisis de prestaciones se estudió en el capítulo primero, en este capítulo estudiaremos cómo elegir y crear las cargas de prueba.

Hay diferentes clasificaciones de las cargas de prueba:

reales, es decir, la carga reproduce exactamente la del sistema original, pero esto tiene una serie de problemas: no es excesivamente flexible; es difícil de reproducir exactamente los datos originales a los que se aplicaban los programas; muchas veces los programas son confidenciales o simplemente no se está autorizado a copiarlos, y, además, puede haber diferencias hardware y software entre el sistema original y el sistema a medir que hagan que no se puedan ejecutar los programas en el nuevo sistema.

sintéticas, son aquellas que resumen la carga original, tomando las características más sobresalientes. Estas, además de evitar los problemas de las cargas reales, pueden ser portadas a diferentes sistemas, modificadas sin afectar la operación del sistema, y pueden incluir programas que sirvan para medir las prestaciones de la carga.

Dentro de las cargas sintéticas, que son las más usadas, a su vez se dividen en dos tipos:

Naturales, que también se suelen denominar benchmarks, están formadas por un grupo de programas extraídos de la carga real. Sin embargo, hay muchos factores que influyen en la carga de un sistema, como el factor de multiprogramación, la memoria, y el número máximo de usuarios, que causan que la mayoría de las veces no se comporten de la misma forma.

Artificiales, que son diversos tipos de cargas creadas artificialmente, que intentan reproducir la carga original.

3.2.1 Cargas Artificiales

Se pueden dividir en ejecutables y no ejecutables, siendo estas últimas básicamente una simulación del comportamiento del sistema. Dentro de las primeras, a su vez, hay varios tipos:

3.2.1.1 Instrucción de suma

Consiste en medir el tiempo que se tarda en realizar esta operación. Este tipo de carga es sumamente simple, sólo mide la CPU y se ha quedado ya bastante obsoleta, aunque sirvió en las épocas en que las prestaciones de la CPU eran determinantes de las prestaciones del sistema.

3.2.1.2 Mix

Un mix de instrucciones es una especificación que incluye diferentes instrucciones en diferentes frecuencias. Para hallar las frecuencias en las que hay que incluir cada instrucción o tipo de instrucción se realiza una monitorización de las instrucciones ejecutadas, usualmente mediante un monitor hardware. Los programas no tienen porqué hacer nada útil, simplemente ejecutan instrucciones. A partir del tiempo total de ejecución del mix, se halla lo que se tarda en media en ejecutar una instrucción, a partir de lo cual se calcula los millones de instrucciones por segundo o mips.



El míx más popular es el de Gibson, desarrollado por Jack C. Gibson para los sistemas IBM 704, que se presenta en el cuadro 1

Evidentemente, un mix es un programa de bajo nivel en código máquina, y, por tanto, este tipo de pruebas son específicas de un tipo de CPU, arquitectura y sistema operativo determinado.

Hoy en día no son demasiada utilidad porque el tiempo que tarda una instrucción en los microprocesadores actuales es variable, dependiendo del estado del pipeline, la caché, el modo de direccionamiento, e incluso los argumentos que se le pasan a la instrucción.

En cualquier caso, un mix solo mide la velocidad de la CPU, y si el sistema no está limitado por la misma, el número de instrucciones sólo no refleja las prestaciones del sistema.



3.2.1.3 Kernel

Los kernel son programas que tratan de representar lo más característico de una carga, por ejemplo, la ejecución de funciones con coma flotante. Uno de ellos es, por ejemplo, la ejecución de la función de Ackerman. Evidentemente, tienen que seleccionarse en función de la carga real del sistema; sólo dará mediciones acertadas en caso de que se asemeje a la carga original.

3.2.1.4 Programas sintéticos

Son programas que simplemente consumen recursos de los diferentes subsistemas del ordenador: CPU, disco, entrada salida, sin hacer por lo demás nada útil. El consumo de recursos se regula por una serie de parámetros de control; y los resultados habrá que calibrarlos para relacionarlos con la carga real.





3.3 Benchmarks


Un benchmark es un conjunto de programas estándar, construido por alguno de los métodos anteriores, que simulan una carga genérica (a diferencia de, por ejemplo, los programas sintéticos, que simulan una carga particular).

Normalmente, los benchmarks tiene habitualmente el objetivo de comparar diferentes ordenadores, periféricos y redes, a la hora de adquirir o ampliar un sistema determinado. Pueden servir también para sintonizar y planificar la carga de un sistema, identificando los problemas de un sistema mediante la forma como se ejecuta una prueba determinada.

Hoy en día, lo más habitual en un benchmark es

Que lo lleve a cabo una empresa o institución independiente, que habitualmente es pagada por sus servicios. La empresa recibe una copia del sistema a evaluar, realiza el trabajo necesario para que se ejecuten los programas, y entrega los resultados al fabricante. Esto, más o menos, garantiza la independencia de los resultados. En muchos casos, las empresas son revistas o están contratadas por revistas, que presentan los resultados obtenidos a los lectores.

Que sean estándar, habitualmente propuestos por un consorcio de empresas. Es decir, son una serie de programas, que todos o la mayoría de los fabricantes conoce y está de acuerdo en respetar los resultados, y cada fabricante es responsable de llevar a cabo las pruebas y de publicar los resultados.

En general, un benchmark recibe dos definiciones:

es una forma de evaluar las prestaciones de un sistema informático, en general; y

es un conjunto de programas reales, escritos en lenguajes de alto nivel, que representan una carga real genérica.

Para conseguir un benchmark hace falta:

Determinar los objetivos de uso.

Escoger el programa según los objetivos.

Estudiar los factores que influyan en el rendimiento: SO, compiladores, librerías usadas, caché, etc.

Un benchmark se usa en la adquisición de equipos, sintonización de sistemas y de capacidad, comparación de compiladores y diseño de sistemas informáticos o compiladores.

En los apartados siguientes veremos una serie de benchmarks que se suelen utilizar en la actualidad.



3.3.1 LINPACK

LINPACK es un programa de álgebra lineal creado por Dongarra en 1976. Consiste en una serie de multiplicaciones de matrices, contenidas en unas subrutinas habitualmente denominadas BLAS. Dongarra ha establecido una base de datos de prestaciones, PDB o Performance Database, a la cual se puede acceder mediante la WWW.

3.3.2 SPEC

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.specbench.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 64 megas de memoria, miles de megas de disco, y tiempo y ganas).

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

Hay que tener en cuenta que los fabricantes de ordenadores, siendo como son, hacen todo lo posible para obtener los mejores resultados; por ejemplo, hay una empresa, KAP, que se dedica a optimizar los compiladores para que ejecuten bien el código SPEC y de otros benchmarks, básicamente el código que ejecuta multiplicaciones de matrices. Esto hace que den buenos resultados en las tasas "agresivas", aunque no necesariamente en las conservadoras.

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.

Como suele suceder, ya se está pensando en la siguiente versión, SPEC98, y se están solicitando conjuntos de aplicaciones que se puedan incluir en el.

3.3.2.1 Cint/Cfp

En concreto, SPEC95 se compone de dos grupos de programas: CINT95, 8 programas de cálculo de enteros intensivo, y CFP95, 10 programas de cálculo intensivo de coma flotante.

099.go Inteligencia Arficial: juega al go
124.m88ksim Simulador del Motorola 88k: ejecuta un programa de prueba
126.gcc Nueva versión de gcc, construye código SPARC.
129.compress Comprime y descomprime fichero en memoria
130.li Intérpreta código LISP
132.ijpeg Compresión y descompresión de gráficos.
134.perl Manipula cadenas (anágramas) y números primos en PERL.
147.vortex Base de datos.


El conjunto de pruebas de coma flotante es el siguiente:

101.tomcatv Programa de generación de tramas
102.swim Programa de agua poco profunda con rejilla 513x513
103.su2cor Física cuántica: simulación de Montecarlo.
104.hydro2d Astrofísica: ecuación de Navier-Stokes
107.mgrid Solución multirejilla en un campo potencial en 3 dimensiones
110.applu Ecuación diferencial parcial elíptica parabólica
125.turb3d Simulación turbulencia homogénea isotrópica en un cubo
141.apsi Resuelve problemas relacionados con la temperatura, viento, velocidad y distribución de la polución.
145.fpppp Química cuántica
146.wave5 Física de plasmas, simulación de partículas electromagnéticas.




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án

Velocidad
Conservador Agresivo
Velocidad SPECint_base95 SPECint95
Throughput SPECint_rate_base95 SPECint_rate95


Todas las tasas son medias geométricas de los resultados obtenidos por cada uno de los diferentes métodos, no aritméticas, es decir:

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.

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 siempre 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 ls prestaciones de ordenadores ejecutando muchas copias del mismo programa, no diferentes proramas, y por lo tanto son poco respresentativos de sistemas reales.

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%.

3.3.2.2 OSG Web 96

Este programa mide prestaciones de ordenadores usando el comando GET sobre páginas estáticas. Consiste en un programa que hace una serie de peticiones usando el protocolo HTTP/1.0, usando ficheros de diferente tamaño.

3.3.2.3 OSG SFS 93

Es un test para servidores de ficheros a nivel de sistema. Básicamente es un sistema completo para medir e informar de prestaciones de servidores NFS (Network file system, sistema estándar de ficheros en UNIX; véase tema 1). El resultado del test da el tiempo medio que tardan en ejecutarse las operaciones NFS, y el número de usuarios que se pueden soportar.

SFS 1.1 contiene un benchmark, 096.laddis, que genera una carga sintética basada en una abstracción de carga de trabajo. Actualmente se está trabajando en una nueva versión de SFS, la 1.2, que modifique la carga de trabajo y que incluya el protocolo NFS 3.0.

También tiene críticas este benchmark de los fabricantes de ordenadores. Según ellos:

3.3.2.4 OSG SDM 91

Benchmark para desarrollo de software en un entorno multitarea, caracteriza la capacidad de un sistema en un entorno UNIX multi-usuario. Contiene scripts de UNIX, que ejercitan el sistema operativo completo, así como los componentes de entrada/salida y la CPU. Contiene dos benchmarks: 057.sdet, que representa un entorno de desarrollo comercial en UNIX y C, y 061.kenbus1, que representa el uso de UNIX y C en un entorno de investigación y desarrollo.

El principal problema que presentan es que están obsoletos, porque no tienen en cuenta el sistema de ventanas, ni la red, y además las cargas de trabajo modeladas son las normales en sistemas más pequeños que los actuales.

3.3.2.5 SPEChpc96

Este benchmark sirve para medir prestaciones de superordenadores, incluyendo todo tipo de ordenadores masivamente paralelos y vectoriales. Incluye aplicaciones usadas realmente en la industria para resolver problemas: unos para procesamiento sísmico (SPECseis96) y otro de química computacional (SPECchem96). Ambas están escritas en C, y proporcionan información suplementaria a SPECfp96, ya que en este caso se trata de aplicaciones reales, no de aplicaciones sintéticas.

3.3.3 BYTEmark

(Obsérvese la hábil mayusculización del nombre de la revista, para que se parezca a SPECmark). 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 de 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.

3.3.4 TPC

Siguiendo con esta interminable lista de benchmarks, llegamos a TPC, propuestos por el Transaction Processing Performance Council, y destinado a medir prestaciones de sistemas completos cliente/servidor, incluyendo tanto los ordenadores cliente, como los servidores, como el sistema de comunicaciones entre ellos, y los sistemas de E/S.

Hoy en día se usan principalmente 2 benchmarks: TCP-C y TPC-D, que evalúa "sistemas de toma de decisiones", incluyendo grandes bases de datos y muchos tipos de peticiones diferentes.

El más usado, tpc-c, trata de modelar un sistema de transacciones en línea, incluye 9 tablas, y realiza 5 tipos de transacciones: nuevas pedidos, servir pedidos, incluir pagos de clientes, recuperar el último pedido de un cliente, y monitorizar el nivel de inventario de los artículos pedidos recientemente; las transacciones se envían desde un terminal con un interfaz de pantalla completo.

Los resultados se presentan de dos formas: como transacciones por segundo, y como precio por transacción. Este último incluye el coste completo del sistema, incluyendo cosas como el coste de mantenimiento a 3 años.

3.4 Consejos sobre la elaboración de un benchmark


Hay muchas equivocaciones que se pueden cometer a la hora de diseñar un benchmark, algunas de ellas a caso hecho para hacer que el ordenador de nuestros deseos sea el mejor. Por ejemplo:

A la vez, algunas de las equivocaciones hechas "a posta" pueden ser:

3.5 Análisis de resultados


Habitualmente, un benchmark da una sola figura de mérito (FDM), que resume las prestaciones de un sistema y compararlas de un solo vistazo. Sin embargo, en la mayoría de los casos, dar una sola medida puede conducir a conclusiones equivocadas, pues se están teniendo en cuenta muchas mediciones y muchos resultados diferentes. Normalmente, dar una sola figura suele ser la mejor forma de engañar al público.

Definamos algunos conceptos de estadística:

Es decir, la suma de los valores tomados por la variable aleatoria por sus probabilidades.

La varianza se suele denotar 2, y su raiz cuadrada, denominada desviación estándar, .

La media, la mediana y la moda son tres ejemplos de lo que se denominan índices de tendencia centrales, y son el tipo de índices que sirven para representar una muestra completa. La media y la mediana siempre existen y son únicos, sin embargo la moda puede no existir en algunas distribuciones. En caso de que sea una distribución normal, las tres son iguales.

El problema es seleccionar una de las tres para representar la muestra. Las reglas que se suelen seguir son las siguientes:

Por ejemplo, para representar el recurso más usado en un sistema, se usaría la moda; para representar la carga, la mediana, ya que suele ser una distrubición poco centrada, sin embargo para el tiempo de llegada de peticiones a un sistema se suele usar la media.

Algunas equivocaciones comunes a la hora de elegir un índice central son:

Además de la media habitual, o media aritmética, a veces se utiliza también la media geométrica, como se ha visto para los SPEC.

Normalmente, para resumir la variabilidad de una variable, se debe de dar la media aritmética y la varianza, o el rango de variación, o los percentiles de 10 y de 90. Pero siempre se tiene que dar algún índice de variabilidad, tanto con respecto a la variabilidad de las mediciones tomadas en las mismas condiciones como a las mediciones de una variable en distintas condiciones.

3.6 Representación gráfica de los resultados


El tipo del gráfico dependerá, sobre todo, del tipo de variable que se va a presentar: cualitativa o categórica ordenada o no, que están definidas por una serie de clases mutuamente exclusivas, y cuantitativa discreta o continua, que es aquella variable cuyos niveles se expresan mejor numéricamente.

A la hora de representar gráficamente el resultado de un benchmark, o de cualquier tipo de medición de prestaciones o de carga de trabajo, es conveniente seguir las siguientes reglas:

Algunos errores que se suelen cometer son los siguientes:

Por supuesto, a veces estas equivocaciones se suelen hacer a posta, sobre todo si uno quiere demostrar algo con los gráficos. El saber este tipo de cosas ayuda también a identificarlas cuando uno se las encuentra:

3.7 Ejercicios


  1. ¿Qué indice de tendencia central debería de usarse para informar de los siguientes variables: tiempo de respuesta, número de paquetes por día, número de paquetes por segundo, frecuencia de palabras en un lenguaje? ¿Y la configuración media de un ordenador personal por tipo de CPU, tamaño de memoria, tipo de disco, número de periféricos, coste?




Realizado por

Juan Julián Merelo Guervós

Depto de Electrónica y Tecnología de Computadores

Universidad de Granada

Fecha de última modificación: 19 de mayo de 1997