- Hay que plantear objetivos reales, con cargas de trabajo reales. En particular, el tiempo que tarda en arrancar un sistema no es una carga real.
- Los objetivos no pueden ser sobre la tasa de uso de un componente (memoria, CPU)
- Las pruebas se diseñan en función del objetivo, y no al revés. Si se trata de que "este programa vaya más rápido", el programa debe ser representativo, no hecho ex profeso.
- Hay que mejorar un sistema, no cambiarlo. El sistema, en general, será un ordenador, algún subsistema del mismo, o en general las prestaciones. No se trata de decir "cambio este programa por este otro más rápido, y ahora va más rápido". O antes tenía esto en memoria, ahora lo quito, y ocupa menos menoria todo (o va más rápido).
- Tampoco se trata de bajarse "PC optimizer 2000", le doy a siguiente, siguiente siguiente, y luego mira la pantalla que pone "sistema optimizado".
- Un buen ejemplo: http://aullidosdigitales.blogspot.com/2008/05/prctica-5-medicin-de-las-prestaciones.html
- Otro, más claro: http://mdyec.blogspot.com/2008/05/practica-5.html
Vemos la práctica de LP-Spain y vemos que ha hecho un poco de trampa porque en verdad cambia un sistema viejo y malo y por uno nuevo y bueno.
Ahora vemos el resumen de la clase anterior.
Seguimos con los ejercicios de autoevalución de Davis87.
Ahora vemos un artículo sobre la arquitectura x86 y que dice que va a estar presente muchos año más.
Seguimos con el temario:
4.2 - Utilización de un benchmark
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.
Uno de los benchmark más conocidos es el SPEC, y vemos un ejemplo del SPEC.
Hay diferentes tipos de benchmarks, dependiendo de cómo se representa la carga de trabajo.
En algunos casos se pueden usar programas reales, realizando una carga de trabajo real.
- Núcleos o kernel, que representan las operaciones fundamentales de una carga de trabajo.
- Uno clásico son los bucles de Livermore (por ejemplo que multiplica matrices), que representan operaciones comunes en cálculo numérico.
- Benchmarks de juguete: miden parámeros básicos, como los megahercios o la latencia de la memoria. No representan en asoluto a ninguna carga de trabajo real.
- Sintéticos, resultan de una operación estadística que mide la carga de trabajo usada con una serie de programas, y abstrae y resume la carga. Son benchmark de bajo nivel.
Los mejores benchmark son los de núcleos o kernel, aunque hay muchos buenos que combinan los kernel y los sintéticos.
- Representar solamente comportamiento medio en la carga de trabajo.
- Ignorar la distribución desigual de las peticiones de dispositivos. Provoca que los resultados no sean muy realistas.
- No controlar el nivel de carga de forma apropiada.
- Ignorar los efectos de la cache. Puede falsear los resultados. Para evitarlo hay que hacer benchmark que no quepan en la caché o repitiendolo varias veces.
- Ignorar el overhead del monitor.
- No validar las medidas. Hacerlas varias veces. (Muy importante).
- No asegurarse de las mismas condiciones iniciales, es decir, de que el estado de la cache sea el mismo, el de los procesos que se están ejecutando también, incluso, si es posible, la fragmentación del disco duro y el espacio que queda libre, pues, como se sabe, estos son dos factores que influyen en la velocidad del mismo. (Muy importante). Por ejemplo: ejecutar el benchmark con el ordenador recién arrancado.
- No medir las prestaciones del transitorio, ya que la mayoría de los experimentos están diseñados para predecir las prestaciones bajo condiciones estables. Por ejemplo: en un sistema recién arrancado, la temperatura no va a ser la misma que la que tendrá pasado un rato.
- Utilizar los porcentajes de uso de los dispositivos para comparar prestaciones. Por ejemplo el uso de CPU. (Muy importante).
- Recoger demasiados datos con muy poco análisis. (Muy importante).
Es hacer marketing utilizando un benchmark, engañar al público con los resultados de un benchmark. Truco clásico de benchmarking de AMD frente a Intel: sus CPUs se llaman lo mismo a las equivalentes en Intel. Por ejemplo un AMD 1800 que en verdad va a 1600 equivale a un Intel que va a 1800.
- Usar configuraciones diferentes para ejecutar la misma carga de trabajo.
- Elegir las especificaciones de forma que favorezcan a una máquina determinada.
- Usar una secuencia de trabajos sincronizada.
- Elegir una carga de trabajo arbitraria.
- Usar benchmarks demasiado pequeños.
- Proyectar o interpolar resultados de un benchmark.
- Elegir el sistema base de normalización de forma arbitraria.
Y para terminar el video del día.
No hay comentarios:
Publicar un comentario