2. Procedimientos de medida e interpretación de resultados

Unas cuantas recomendaciones semiobvias:

1. Primera y principal, identifique el rendimiento objetivo. ¿Qué es exactamente lo que trata de medir? ¿De qué forma la medida del rendimiento le ayudará después a tomar una decisión? ¿Cuánto tiempo y cuántos recursos está dispuesto a gastar en el proceso de medida?
2. Utilice herramientas estándar. Use una versión del núcleo estable y actualizada, así como un gcc, libc, y una herramienta de medida del rendimiento actualizados y estándares. Abreviando, utilice el LBT (ver más adelante).
3. Dé una descripción completa de su configuración (vea el artículo LBT más adelante).
4. Trate de aislar una variable. Las medidas comparativas dan más información que las ``absolutas''. Ya no puedo insistir más en este punto.
5. Verifique sus resultados. Ejecute sus pruebas unas cuantas veces y compruebe las fluctuaciones en los resultados, de haberlas. Las fluctuaciones inexplicables invalidarán sus resultados.
6. Si cree que su esfuerzo en la medición del rendimiento ha producido información útil, compártala con la comunidad Linux de forma breve y concisa.
7. Por favor, olvídese de los BogoMips. Me he prometido que algún día implementaré un rapidísimo ASIC con el bucle de los BogoMips enganchado en él. ¡Entonces veremos lo que tengamos que ver!

2.1 Entendiendo la elección de la herramienta

Las herramientas de medida sintéticas vs. las de aplicaciones

Antes de perder el tiempo escogiendo entre todos los tipos de herramientas de medida, se debe hacer una elección básica entre las herramientas ``sintéticas'' y las de ``aplicación''.

Las herramientas sintéticas están especialmente diseñadas para medir el rendimiento de un componente individual de un ordenador, normalmente llevando el componente escogido a su máxima capacidad. Un ejemplo de una herramienta sintética muy conocida es el Whetstone, programado originalmente en 1972 por Harold Curnow en FORTRAN (¿o fue en ALGOL?) y todavía ampliamente utilizada. El conjunto de herramientas Whetstone medirá el rendimiento de la unidad de punto flotante de la CPU.

La crítica principal que puede hacérsele a las medidas ``sintéticas'' es que no representan el rendimiento del sistema en las situaciones de la vida real. Tomemos por ejemplo las herramientas Whetstone: el blucle principal es muy pequeño y podría caber fácilmente en la caché primaria de la CPU, manteniendo el bus de la unidad de punto flotante (FPU) constantemente lleno y ejercitando, por tanto, la FPU a su máxima velocidad. No podemos criticar las herramientas Whetstone por esto, ya que hemos de tener presente que fueron programadas hace 25 años (¡y diseñadas en fechas anteriores!), pero hemos de asegurarnos de que interpretamos los resultados con cuidado cuando medimos microprocesadores modernos.

Otro punto a tener en cuenta sobre los tests sintéticos es que, idealmente, deberían darnos información acerca de un aspecto específico del sistema que estamos comprobando, independientemente del resto de componentes: un test sintético sobre la E/S de las tarjetas Ethernet debería devolver el mismo resultado (o al menos similar) independientemente de si se ejecuta en un 386SX-16 con 4 MBytes de RAM o de si se ejecuta en un Pentium 200 MMX con 64 MBytes de RAM. Sin embargo, el test medirá la rendimiento global de la combinación CPU/placa base/Bus/tarjeta Ethernet/Subsistema de memoria/DMA: no es muy útil, ya que la variación en el procesador podría causar un impacto mayor en los resultados que la variación en la tarjeta de red Ethernet (naturalmente, ésto es suponiendo que estamos utilizando la misma combinación de controlador/núcleo, que también pueden producir grandes cambios).

Para terminar, un error muy común es hacer la media de varios tests sintéticos y decir que esta media es una buena representación del rendimiento en la vida real de un sistema.

Aquí tenemos un comentario acerca de los tests FPU, citado con permiso de Cyrix Corp.:

``Una Unidad de Coma Flotante (Floating Point Unit, FPU) acelera los programas diseñados para utilizar matemáticas en coma flotante: suelen ser programas de CAD, hojas de cálculo, juegos 3D y diseño de aplicaciones. Sin embargo, hoy en día las aplicaciones más populares para PC utilizan al mismo tiempo instrucciones en enteros y en coma flotante. Como resultado, Cyrix ha decidido poner énfasis en el ``paralelismo'' a la hora de diseñar el procesador 6x86 para acelerar los programas que entremezclan estos dos tipos de instrucciones.

El modelo de exclusión de la unidad de coma flotante de los x86 permite la resolución de instrucciones con enteros mientras se ejecuta una instrucción en coma flotante. Por contra, no se puede ejecutar una segunda instrucción en coma flotante si ya se estaba ejecutando anteriormente una. Para eliminar la limitación en el rendimiento creada por el modelo de exclusión de la unidad de coma flotante, el procesador 6x86 puede realizar especulativamente hasta cuatro instrucciones en coma flotante al chip FPU mientras sigue ejecutando instrucciones enteras. Por ejemplo, en una secuencia de código con dos instrucciones en coma flotante (FLTs) seguidas por seis instrucciones enteras (INTs) y seguidas por dos FLTs más, el procesador 6x86 puede mandar las diez instrucciones anteriores a las unidades de ejecución apropiadas antes de que se termine la primera FLT. Si ninguna de las instrucciones falla (el caso típico), la ejecución continua con las unidades de enteros y de coma flotante terminando las instrucciones en paralelo. Si una de las FLTs falla (el caso atípico), la capacidad de ejecución especulativa del 6x86 permite que se restaure el estado del procesador de forma que sea compatible con el modelo de exclusión de la unidad de coma flotante del x86.

Un examen de los test de rendimiento revela que los test sintéticos de la unidad de coma flotante utiliza un código con solo operaciones de coma flotante, que no es lo que nos encontramos en las aplicaciones del mundo real. Este tipo de tests no aprovecha la capacidad de ejecución especulativa presente en el procesador 6x86. Cyrix cree que las pruebas que utilizan herramientas no sintéticas, basadas en aplicaciones del mundo real reflejan mejor el rendimiento real que pueden obtener los usuarios. Las aplicaciones del mundo real contienen instrucciones mezcladas de enteros y de coma flotante y utilizan por tanto, la capacidad de ejecución especulativa del 6x86.''

Por lo tanto, la tendencia en los tests de rendimiento es elegir las aplicaciones más comunes y utilizarlas para medir el rendimiento del sistema completo. Por ejemplo, SPEC, la organización sin ánimo de lucro que diseñó las herramientas SPECINT y SPECFP, ha lanzado un proyecto para un nuevo conjunto de herramientas basadas en aplicaciones. Pero de nuevo, sería muy raro que alguna herramienta comercial de medida del rendimiento incluya código Linux.

Resumiendo, los tests sintéticos son válidos mientras comprenda sus propósitos y limitaciones. Las herramientas basadas en aplicaciones reflejarán mejor el rendimiento global del sistema, pero no hay ninguna disponible para Linux.

Tests de alto nivel vs. test de bajo nivel

Los tests de bajo nivel miden directamente el rendimiento de los componentes: el reloj de la CPU, los tiempos de la DRAM y de la caché SRAM, tiempo de acceso medio al disco duro, latencia, tiempo de cambio de pista, etc... esto puede ser util en caso de comprar un sistema y no se sabe con que componentes viene, pero una forma mejor de comprobar estos datos es abrir la caja, hacer un listado con los nombres que pueda conseguir y obtener una hoja de características de cada componente encontrado (normalmente disponibles en la red).

Otro uso de los tests de bajo nivel es comprobar que un controlador de núcleo ha sido correctamente instalado para un componente específico: si tiene la hoja de especificaciones del componente, puede comparar los resultados del test de bajo nivel con las especificaciones teóricas (las impresas).

Los tests de alto nivel están más enfocados a medir el rendimiento de la combinación componente/controlador/SO de un aspecto específico del sistema, como por ejemplo el rendimiento de E/S con ficheros, o el rendimiento de una determinada combinación de componentes/controlador/SO/aplicación, p.e. un test Apache en diferentes sistemas.

Por supuesto, todos los tests de bajo nivel son sintéticos. Los tests de alto nivel pueden ser sintéticos o de aplicación.

2.2 Tests estándares disponibles para Linux

EMMO un test sencillo que cualquiera puede hacer cuando actualiza cualquier componentes en su Linux es hacer una compilación del núcleo antes y después de la actualización del componente o del programa y comparar los tiempos de compilación. Si todas las demás combinaciones se mantienen igual, entonces el test es válido como medida del rendimiento en la compilación, y uno ya puede decir que:

"Cambiar de A a B lleva a una mejora de un x % en el tiempo de compilación del núcleo de Linux bajo estas y estas condiciones".

¡Ni más, ni menos!

Ya que la compilación del núcleo es una tarea muy normal en Linux, y ya que ejercita muchas de las funciones que se realizan normalmente en los tests (excepto el rendimiento con las instrucciones en coma flotante), podemos concluir que es un test individual bastante bueno. Sin embargo en muchos casos, los resultados de un test no puede ser reproducido por otros usuarios Linux debido a las variaciones en la configuración de los programas/componentes y por tanto este tipo de pruebas no puede utilizarse como ``vara de medida'' para comparar distintos sistemas (a menos que nos pongamos todos de acuerdo en compilar un núcleo estándar - ver más adelante).

Desgraciadamente, no hay herramientas de medida del rendimiento específicas para Linux, exceptuando el Byte Linux Benchmarks, que son una versión modificada del The Byte Unix Benchmarks que data de Mayo de 1991 (los módulos de Linux se deben a Jon Tombs, autores originales Ben Smith, Rick Grehan y Tom Yager).

Hay una página central http://www.silkroad.com/bass/linux/bm.html para el Byte Linux Benchmarks.

David C. Niemi puso por ahí una versión del Byte Unix Benchmarks mejorada y actualizada. Para evitar confusiones con alguna versión anterior la llamó UnixBench 4.01. Aquí está lo que David escribió sobre sus modificaciones:

``La versión original y las versiones ligeramente modificadas de BYTE Unix Benchmarks se diferencian en varias cosas que los hacen ser un indicador inusualmente poco fiable del rendimiento del sistema. He hecho que los valores de mis ``índices'' parezcan muy diferentes para evitar confusiones con el viejo test.''

David ha creado una lista de correo majordomo para la discusión sobre las pruebas de rendimiento para Linux y para el resto de SOs. Puede unirse a la lista enviando un mensaje a majordomo@wauug.erols.com escribiendo en el cuerpo ``subscribe bench''. El Grupo de Usuarios de Unix del Area de Washington está en proceso de crear una página Web http://wauug.erols.com/bench sobre los test de rendimiento en Linux.

También recientemente, Uwe F. Mayer, mayer@math.vanderbilt.edu portó el conjunto de pruebas Byte Bytemark a Linux. Éste es un moderno conjunto de herramientas que Rick Grehan envió a BYTE Magazine para comprobar la CPU, FPU y el rendimiento del sistema de memoria de los modernos sistemas de microordenador (hay pruebas estrictamente orientadas al rendimiento del procesador, sin tener en cuenta el rendimiento de la E/S o del sistema).

Uwe también ha creado una página Web http://math.vanderbilt.edu:80/~mayer/linux/bmark.html con una base de datos de los resultados de las pruebas de su versión del Linux BYTEmark benchmarks.

Si busca pruebas sintéticas para Linux, en sunsite.unc.edu podrá encontrar unas cuantas. Para comprobar la velocidad relativa de los servidores X y de las tarjetas gráficas, el conjunto de herramientas xbench-0.2 creado por Claus Gittinger está disponible en sunsite.unc.edu, ftp.x.org y otros lugares. Xfree86.org rechaza (prudentemente) el llevar o recomendar ninguna prueba.

El XFree86-benchmarks Survey http://www.goof.com/xbench/ es una página Web con una base de datos de los resultados de x-bench.

Para el intercambio de E/S de disco, el programa hdparm (incluido con muchas distribuciones, si no lo tiene puede encontrarlo en sunsite.unc.edu) puede medir las tasas de transferencia si lo invoca con las opciones -t y -T.

Hay muchas otras herramientas disponibles de forma libre en Internet para comprobar varios aspectos del rendimiento de su Linux.

2.3 Enlaces y referencias

El comp.benchmarks.faq creado por Dave Sill es la referencia estándar en las pruebas de rendimiento. No es específico de Linux, pero es una lectura recomendada para cualquiera que se quiera ver seriamente implicado en las pruebas de rendimiento. Está disponible en muchos FTPs y páginas Web y muestra 56 pruebas diferentes, con enlaces a direcciones FTP o páginas Web donde se pueden recoger. Algunas de las pruebas que se mencionan son comerciales (SPEC, por ejemplo).

No voy a nombrar todos y cada uno de los tests que se mencionan en comp.benchmarks.faq, pero hay al menos una prueba de bajo nivel que me gustaría comentar: la prueba lmbench http://reality.sgi.com/lm/lmbench/lmbench.html de Larry McVoy. Citando a David C. Niemi:

``Linus y David Miller la utilizan mucho ya que es capaz de realizar medidas útiles de bajo nivel y también puede medir el trasvase y la latencia de la red si tiene dos ordenadores para hacer los tests. Pero no intenta conseguir algo así como un ``rendimiento del sistema'' general...''

Alfred Aburto puso en marcha un lugar FTP bastante completo en cuanto a utilidades libres de medida del rendimiento ( ftp://ftp.nosc.mil/pub/aburto). Las herramientas Whetstone utilizadas en el LBT se encontraron aquí.

También tenemos el FAQ multiparte de Eugene Miya que deja regularmente en comp.benchmarks; es una referencia excelente.

Hosting by: hurra.com
Generated: 2007-01-26 18:00:33