La plataforma software ideal para tests de rendimiento

Nunca he sido excesivamente aficionado al overclocking (no me mateis a tomatazos :P), pero me gusta bastante probar benchmarks de cara a optimizar el software de mi equipo. ¿Y que nos vienes a contar, si este foro pertenece al hardware?
Pues intento hablaros de la plataforma software, ya que al fin y al cabo, para ejecutar un test, por muy especifico que sea, el software influye en los resultados.
En el hilo del SuperPI, he tenido el gusto de iniciar una pequeña revuelta en favor del uso de linux [tomaaa] Y quiero que tengais bien claro que mi intención no es crear un flame tipico win vs. linux (los tengo muy vistos :P). Y si lo he hecho es porque creo que linux es una plataforma que puede otorgar resultados mas fieles a la realidad. Es decir, que el margen de error a la hora de extraer el rendimiento de un sistema sea menor.

Y si digo esto no es por iluminación divina. Voy a poner como ejemplo, una de las practicas de "Estructuras de Computadores". Se trataba de hacer de un analisis de stride para comprobar las características de una cache. Pues realizada en equipos windows, las graficas resultantes no eran tan claras como en linux. Incluso las conclusiones eran distintas de un SO a otro (obviamente, las correctas eran las de linux).
El código que vamos a utilizar esta disponible aqui:
http://personales.ya.com/raharu/stride.rar
y las instrucciones de la práctica, aunque si seguís lo que yo os digo, no os haran falta (va por los curiosos):
http://personales.ya.com/raharu/stride.pdf

Para reproducir el "test", haced lo siguiente, con la menor actividad del sistema posible:
En linux:


En windows:
- Extraed el rar
- Ejecutad el programa, os generara un archivo de resultados en la carpeta del ejecutable (pondremos que se llama resultados)
- Abrís el gnuplot (http://www.cs.uni.edu/Help/gnuplot/windwnld/wgnuplot.exe)
- Situad el shell del gnuplot al directorio en el que estabamos trabajando (usando cd y pwd para saber donde estais)
- Escribis las mismas lineas del "gnuplot>" en linux

Con esto obtendremos nuestro gráfico con los diferentes tiempos de acceso a los diferentes niveles de la jerarquia de memoria (cache L1, cache L2, RAM...). Si razonais un poco caereis en cuenta que las barras de los graficos deberian formar el mismo numero de grupos que niveles de memoria.
Es decir, en un SO no intrusivo ideal, las barras solo podrian tener unos valores fijos, marcados por el tiempo de acceso a L1, L2, RAM...
Pero fijaos en que hay un error de dispersion. No obstante, este error es notablemente inferior en linux que en windows.
Este test es mucho mas representativo en maquinas antiguas (lo siento, pero estaba ajustado a las maquinas que hay en los laboratorios), creo recordar, que el caso mas escandaloso era el de los k6, si alguien tiene uno, le agradeceria que hiciera la prueba y nos mostrara los resultados.

Bien, todo esto es extrapolable a cualquier test que realiceis sobre un PC, así que espero que os sea provechoso este latazo que os he dado y no os hayais aburrido excesivamente.
No pretendo que de la noche al dia todo el mundo use linux para sus benchmarks, pero no estaria mal que lo tuvierais en cuenta, cara a hacer unos tests en condiciones lo mas fieles posibles.
Por favor, cuanta mas gente realize el test (tanto en windows como en linux) más interesante será este hilo. Al fin y al cabo también lo podeis tomar como un parámetro de referencia más de vuestros micros y que en ocasiones resulta más importante que el duro megaherzio. Hablo de la cache y la memoria RAM. Si teneis cualquier duda, preguntad sin temor.

Un Saludo y perdón por la intromision
PD: Una distro de linux sin instalarla en el HD: http://www.knoppix.org

Ampliación: Explicación del test.
El test, como creo que ya ha quedado claro, no mide la potencia de calculo puro del procesador (Instrucciones por segundo), sino que mide el tiempo de acceso a los niveles de memoria. Los niveles de memoria, van como siguen:
+ Rapidos / - Capacidad
Registros del procesador
Memoria Cache
Memoria RAM
Disco duro (el tipico espacio de intercambio o swapping)
- Rapidos / + Capacidad

Los graficos representan el tiempo de acceso a los niveles de memoria. ¿Y como consigue hacerlo? Facil. La memoria hoy en dia se construye de forma que cuando el procesador pide un dato, lo pide a la caché. Si en la cache no esta disponible, la cache lo pide a la RAM. No obstante, la memoria no le da un dato, si no que le dá más (4, 8...), puesto que la construccion de las SDRAM en adelante lo facilita. Así pues, si pedimos un vector a la memoria (conjunto ordenado de datos), en vez de darnos el primer elemento nos dará X. Pues bien, los siguientes X-1 datos no hara falta ir a buscarlos a memoria, con lo que será más rapido. Pero si yo pido los datos de X en X, se acabó la jugada, toca ir a la memoria todas las veces
Jugando con el tamaño del vector (para ver la capacidad de la cache) y con el intervalo en que pedimos datos (podemos pedir 0, 1, 2, 3 o 0, 4, 8, 12...) podemos obtener datos sobre la organización de la caché. Si repetimos la operación de acceso al vector varias veces, podemos averiguar cual es la politica de reemplazamiento de la cache.

Si quereis profundizar más dadle un vistazo al pdf que adjunto más arriba.

Ampliación 2: Explicación del grafico obtenido.
Esto tendria que haberlo hecho antes
La grafica representa en el eje Y el tiempo de acceso. En el eje horizontal, los grupos son los de distintos tamaños de vector (fijaos como los primeros caben en la cache), y los diferentes valores dentro de un grupo son el "stride". El "stride" es el intervalo de acceso al vector, por ejemplo: Un vector accedido con stride 4 va a los siguientes elementos: 0, 4, 8, 12... mientras uno con stride 1 va a los siguientes elementos 0, 1, 2, 3...
Simple y llanamente, los valores más altos representan el tiempo de acceso a la RAM, mientras que los más bajitos, el tiempo de acceso a la cache. Si disponeis de más caché tendreis más barritas pequeñitas.

No os corteis en preguntar

Ampliación 3: Mis Resultados.
Linux sin optimización al compilar:


Linux optimizado: CFLAGS="-O2 -march=athlon-xp -mmmx -msse -m3dnow -fomit-frame-pointer -pipe"


Windows sin optimizar (lo siento, pero paso de buscar un compilador para ADA P) Tened cuidado con la escala del eje Y


Comentarios:
En este caso, el tiempo de acceso a la cache de primer nivel no crece con el stride. No obstante, la dispersión de los resultados se dispara aunque el programa realiza más de un test por barrita para conseguir resultados más fiables.
El tiempo de acceso a la memoria RAM, ha disminuido usando windows, de todas formas, no se hasta que punto es valido este test para la RAM, puesto que si os fijais en el grafico, es casi tan rapido el ultimo nivel de cache (el que está alrededor de 200ns), como la RAM. Lo que no tiene ninguna logica.