Conecta con nosotros

Hola, ¿qué estás buscando?

Actualidad

Mentiras, malditas mentiras y benchmarks

Como habréis podido sacar del título, no creo en los benchmarks. Bueno, no creo en la mayoría de los benchmarks. No voy a escribir para convenceros que los benchmarks son nefastos y hay que huir de ellos, sólo voy a daros mi opinión y explicar por qué no creo en ellos.

Son varias las razones por las que no creo en los benchmarks:

  1. No se comparan sistemas iguales: el caso más típico es el de Top500. En este caso, se comparan:
    • clusters
    • máquinas NUMA
    • máquinas SMP
    • máquinas con procesadores vectoriales

    Vamos que son máquinas que no se parecen ni en el blanco de los ojos.

    NUMA, clusters, procesadores vectoriales, ...

  2. No se ejecutan los benchmarks debidos: vuelvo otra vez al Top500. Como decía en el apartado anterior, las máquinas que se comparan son completamente diferentes, pero es que además, el software que se utiliza para medir su rendimiento es LINPACK y HPL. Es curioso, LINPACK y HPL se diseñaron para sistemas de memoria distribuida, tal y como en sus respectivas webs:

    «HPL is a software package that solves a (random) dense linear system in double precision (64 bits) arithmetic on distributed-memory computers.»

    Luego los sistemas de memoria distribuida se ven favorecidas frente a las de memoria compartida. Sí, existe LAPACK, pero como dice la web de LAPACK:

    The original goal of the LAPACK project was to make the widely used EISPACK and LINPACK libraries run efficiently on shared-memory vector and parallel processors. On these machines, LINPACK and EISPACK are inefficient because their memory access patterns disregard the multi-layered memory hierarchies of the machines, thereby spending too much time moving data instead of doing useful floating-point operations.

    Es decir, está diseñado para memoria compartida y procesadores vectoriales y paralelos. Pero, tal y como indica en la web de Linpack:

    LINPACK has been largely superceded by LAPACK, which has been designed to run efficiently on shared-memory, vector supercomputers.»

    Entonces, si LINPACK se está dejando de lado por LAPACK: ¿por qué Top500 sigue usando Linpack?

    The best performance on the Linpack benchmark is used as performance measure for ranking the computer systems.

    Si se empieza a usar LAPACK, ¿no ocurrirá al contrario? Que se vean beneficiados los sistemas de memoria compartida frente a los de memoria distribuida. Pues sí, unos se ven beneficiados y otros no. Luego no todas las herramientas de benchmark son iguales, no sirven para medir cualquier equipo, …

    Otra cosa a tener en cuenta es que LINPACK mide lo que se llama operaciones en coma flotante. Luego … no significa que dicho sistema tenga buen rendimiento en enteros, por ejemplo. Vaya, entonces porqué en Top500, por ejemplo, ¿no ponen diferentes categorías? Eso es algo qu eyo no puedo contestar.

    Advertencia, desplázate para continuar leyendo

    No quiero centrar el post en Top500, Top500 es sólo un ejemplo. Lo que quiero que se vea en este punto es que muchas veces se usan herramientas equivocadas

  3. No reflejan la realidad: Los benchmarks se ejecutan bajo unas condiciones muy estrictas que favorecen al que lo está ejecutando. Un buen benchmark se debería hacer con los datos del cliente, en casa del cliente y con todos los usuarios que tiene el cliente dando guerra. Un ejemplo curioso que me llama la atención es, por ejemplo, algunos benchmarks que se ven de BBDD. Resulta que prueban el acceso simultáneo de 1000 usuarios … pero SÓLO HAN USADO 5 PCs cliente!!!! Vamos que han metido 200 conexiones desde cada PC. Sí, sé que encontrar 1000 PCs, instalarles el sistema operativo, la aplicación cliente, instalar la aplciación que lance las peticiones, … es muy complejo, caro, … Pero no representa la realidad, que es a lo que voy.

    ¿Realidad?

  4. Otra manía que se tiene es decir que se ha sustituido un equipo antiguo por uno nuevo que da XXX veces más rendimiento (dando a entender que el antiguo no tiene lo que tiene que tener). Esto es absurdo, obviamente, el equipo antiguo no dará el mismo rendimiento que el nuevo. No estamos comparando peras con peras. Es como si los fabricantes de automóviles dicen «Mi nuevo y flamante modelo deportivo XJF-500 consume menos que el de la marca ABC de hace 5 años» … vamos, para darle un premio al tío. Normal que tu modelo nuevo corra más que el modelo antiguo de tu competencia. Vamos un benhcmark y una comparativa totalmente creible …
  5. Otra razón es que la gran mayoría de las veces se comparan cosas mediante un software que no se conoce: Por ejemplo, se comparan dos sistemas de ficheros y se llega a la conclusión que el sistema de ficheros A es mejor que el B. Pero … si te pones a ver las características de los dos sistemas de ficheros, uno ha sido diseñado para ficheros grandes y otro para ficheros pequeños, los sistemas de ficheros se han configurado de forma distinta (distinto tamaño de bloque, por ejemplo), … Además, la aplicación para medir el rendimiento no se conoce y las opciones que se han usado no se han aplicado correctamente. Otro problema relacionado con esto es que si no conoces la herramienta de benchmark, puedes estar falseando los datos. Por ejemplo, ¿hace falta borrar los buffers o cachés o lo hace automáticamente la herramienta?
  6. Monitorización… otro gran mundo. No basta hacer un benchmark sino que también hay que monitorizar. Sí, ya sé que todo software de benchmark trae un software de monitorización y al final te da el resultado. Pero sólo se ha monitorizado un punto. Pongo un ejemplo, imaginémonos que estamos monitorizando un servidor de ficheros. Es interesante monitorizar:
    • el cliente
    • el switch de red
    • el almacenamiento y todos sus elementos: switches de fibra, cabinas de disco, …
    • el servidor en sí
  7. Consumo eléctrico, económico, espacio: No basta con decir: «Mi servidor da XXXXX ExaFLOPS». Hay que tener en cuenta lo que consume. Por eso me parece bien la iniciativa de Green500 (http://www.green500.org/) que pretende enfrentar el consumo de un sistema y su potencia. En cuanto a lo que cuesta la máquina, es interesante saber la relación potencia/precio ya que si es muy potente el sistema, pero te va a costar mucho dinero … a lo mejor no te sale tan rentable. Otras relaciones a tener en cuenta son: potencia/espacio ocupado, potencia/producción de calor, …

    Green500

  8. Saber interpretar los resultados: No vale con decir «Mi máquina da 4 y la tuya 7». Hay que saber cuando es beneficioso dar 4 y cuándo es beneficioso dar 7. Es interesante ejecutar varias veces el mismo benchmark y aplicar nuestros conocimientos estadísticos.
  9. Muchas comparativas de equipos caseros comparan dos procesadores de dos fabricantes diferentes … usando diferentes placas base: Esto es horrible. Es como si comparamos dos modelos de coches de diferentes fabricantes en carreteras diferentes. Cada placa base tiene diferentes BIOS, diferentes chipsets, … Luego el rendimiento no es comparable. Os pongo un ejemplo. Un cliente hace un par de años estaba montando un sistema que requería unos rendimientos en red determinados, los PCs clientes que había comprado (si no recuerod mal, eran 50) eran todos iguales: mismo procesador, misma placa base, misma memoria, misma tarjeta de red, … Pues al hacer las prubeas de rendimiento … algunos PCs cliente daban mejor rendimiento que otros (la diferencia era notable para lo que él necesitaba, no hablo de unos pocos KB sino de varios MB). Total que desmontamos todos los equipos y comparamos placa por placa … Mira tu por donde, aunque las placas base eran el mismo modelo y de la misma marca … los componentes cambiaban (en unas había resistencias y condensadores que en otra no había) y esta diferencia estaba afectando muy negativamente al rendimiento.
  10. Como he dicho más arriba, que un benchmark no de un valor favorable no significa que el sistema sea malo y que es mejor otro. Puede significar que una parte del sistema está mal. Pongo por ejemplo este caso. Recordemos que tenemos que entender lo que se está haciendo.

Ahora que he rabiado todo lo que he podido y me he quedado tranquilo, sí me gustaría decir que:

  • Espero que nadie se tome este post como una crítica destructiva sino constructiva y que si alguien pretende hacer un benchmark tenga en cuenta lo que he comentado y así evite cometer errores y llegar a conclusiones erróneas (por su propio bien ;)
  • Que hay gente muy profesional que sabe lo que hace y cuyos benchmarks están muy bien hechos

Os dejo estos enlaces que me han parecido interesantes:

  • http://www.linuxplanet.com/linuxplanet/reports/6478/1/
  • http://www.hpcwire.com/topic/systems/HPC_Innovation_in_the_Era_of_Good_Enough.html
  • http://www.mysqlperformanceblog.com/

NOTA: NO tengo nada en contra de Top500. Lo pongo como ejemplo para que la gente sepa interpretar los resultados que aparecen en dicha lista y porque es una lista muy conocida.

7 Comentarios

Te recomendamos

Actualidad

El pasado 28 de abril de 2011 llegaba al mercado la versión final de Ubuntu 11.04 Natty Narwhal, una distribución que ya de por...

Actualidad

Hace menos de seis meses que publiqué el extenso análisis de Ubuntu 11.04, y en aquella ocasión dejé claras mis impresiones: Unity había provocado...

Actualidad

Ciertamente, tener a Linux en las escuelas o, dicho con más propiedad, tener a GNU/Linux en las escuelas, no debería ser una pregunta abierta...

Actualidad

Nos encontramos al fin ante Fedora 14, la última versión de la distribución comunitaria de Red Hat, y lo hacemos con un análisis detallado...