best counter

Mentiras, malditas mentiras y benchmarks

Publicado por thrash el 12 June, 2008 en Benchmarks, Hardware, Software - 3 Comentarios



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.

    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.

  1. Lo que tiene poco sentido es tener una maquina colosal, con la categoría de “la más GRANDE” del mundo que es capaz de realizar tantos hexaflops y después no hay ningún trabajo en la cola que escale los 116Kprocesadores. Hasta que punto, tiene sentido una única maquina con tantos nodos si el trabajo más escalable ocupa como mucho 500 cpu’s?

  2. Thrash says:

    Obviamente, si tus procesos requieren 16 CPUs, cómprate una máquina con 16 CPUs. Pero creeme, hay clientes/empresas/fundaciones/… que _SÍ_ tienen procesos que escalan hasta límites insospechados.

    Te pongo unos cuantos ejemplos:

    1.- Al principio, cuando se simulaban choques de coches, se simulaba cómo se deformaba el parachoques. Hoy en día se simula lo que les ocurre a tus órganos internos si tu coche choca, además de todo lo que le puede pasar a tu coche.

    2.- Hay centros de investigación que han simulado un corazón Humano para lo que han necesitado trabajar con 1 Billón de partículas.

    3.- Otro centro de investigación ha simulado el funcionamiento de un virus completo (1 millón de átomos)

    4.- El British Museum ha hecho 50 mil TACs a una momia y ahora utilizan esos TACs para ver/estudiar _en tiempo real_ la momia por dentro.

    5.- Yo he visto una simulación de un choque de trenes que representaba al 99% un choque real de trenes

    6.- También puede ocurrir que tengas 8000+ procesadores porque eres un centro de investigación europeo y vas asignando CPUs a determinados proyectos, como es el caso del LRZ.

    7.- En la NASA simulan los cambios climáticos a nivel mundial, es decir, de _toda_ la Tierra.

    8.- El proyecto COSMOS (del Sr. Hawking) estudia el nacimiento de galaxias.

    9.- Hay otros proyectos que estudian lo que podría ocurrir si chocan dos galaxias.

    10.- Cuando se hace un pozo petrolero, hay que ver _en tiempo real_ todos los datos sísmicos, de temperatura, presión, …

    Como ves, hay muchos proyectos que hacen uso de muchos procesadores. No todo el mundo los necesita, pero sí hay veces en los que 256 procesadores y 2 TB d RAM son poca cosa.

  3. Mary says:

    Hola!

    Gracias por compartir tu punto de vista. Me gustó leer tu artículo. Lo que te quería comentar es que en lo de la ausencia de las categorías en el top500, creo que es por el uso que se le da a los equipos. Es decir, como bien está en la última respuesta publicada, los que requieren equipos de súper computación usan operaciones de punto flotante, por eso el interés en hacer las pruebas en punto flotante, en realidad no importa mucho el entero sólo porque en la gran mayoría de los resultados se obtendría un número en punto flotante, por ende el resultado lo considero un estimado. Bueno, espero que me puedas comentar algo, ando por los momentos metida en este tipo de temas y no tengo gente con quien hablar de esto, quisiera aprender más. Saludos!

Escribe un comentario

muycomputer
Quiénes somos | Publicidad | Condiciones de uso | Aviso legal | Contacto
Copyright Total Publishing Network S.A. 2008. Todos los derechos reservados
muypymes Inforpress