Después vemos el resumen de la clase anterior (esta vez me ha tocado a mí).
A continuación vemos un artículo sobre los kernel precompilados y el hecho de no ser necesario compilar elkernel para cada máquina; Y vemos que el argumento que utiliza el autor es que aunque optimices el kernel, en este caso compilandolo, es muy bajo el tiempo que se está ejecutando en CPU y por lo tanto no vas a conseguir una gran mejora. Sobre este argumento vemos que es erróneo porque si el sistema es un sistema orientado a que el tiempo del kernel en núcleo sea alto, como por ejemplo un servidor, es obvio que se reducirá bastante el tiempo de cualquier rutina.
Trabajo final: 6 de Julio de 2008
Las notas de clase saldrán en Julio y se pueden reclamar.
Seguimos con ejercicios de autoevaluación:
1. El blog de Josele
En estos ejercicios vemos que el artículo tiene varios fallos a la hora de representar los gráficos como meter un fondo, barras delimitadoras, distintos formatos (verticales y horizontales), demasiados resultados en un sólo gráfico, utilizar líneas cuando deberían ser barras, utilizar una leyenda en vez de colocar cada identificador debajo de su barra correspondiente,.... y no haber incluido el índice final.
2: Davis87 Ejercicio 4.1
3: Davis87 Ejercicio 4.2
4: Davis87 Ejercicio 4.3
Y ahora seguimos con el temario:
4.2.6 Engañando a los benchmarks
El mejor benchmark que se puede utilizar para un juego es probar ese juego, porque al utilizar un benchmark sintético te puede dar unos resultados malos y al jugar el juego te puede funcionar perfectamente y darte unos resultados buenísimos.
ATI y NVIDIA configuraron sus tarjetas para que al ejecutar el benchmark 3DMark, dejase código sin ejecutar para que obtuviesen resultados muy buenos con el 3DMark.
Dado que las decisiones de compra de muchos consumidores de
material informático dependerán de las prestaciones del mismo, tal como han sido
medidas por organizaciones, independientes, hay una gran presión para obtener
los mejores resultados posibles. Ya que es difícil manipular los resultados, por
la verificación a que éstos son sometidos, se intenta mani pular los ordenadores
de forma que produzcan tiempos de ejecución mejor en los benchmark. El problema
es que, de esta forma, los benchmarks se convierten el algo totalmente
independiente de las prestaciones reales del sistema, y, lo que es más
importante, en las diferencias relativas entre sistemas.
En algunos casos se
hace difícil comparar dos sistemas, incluso para el mismo juego, porque el
código que se ejecuta depende del hardware; por eso, usar juegos para comparar
puede ser contraproducente, porque puede dar mejores prestaciones en el hardware
peor, siempre que el código para ese hardware específico lo permita. El problema
es que al ser el código específico del sistema, si se usa un benchmark genérico,
los resultados que se van a dar no van a tener ningún sentido.
Los timos en
lso benchmarks son un problema real, habiendo artículos que hablaban de
escándalos casi diarios Las formas más habituales en
que se suelen producir estos engaños son los siguientes:
Detección y
optimización del código de un benchmark: tanto los compiladores como el código
del sistema operativo pueden examinar lo que están ejecutando o compilando, ver
su parecido con alguno de los benchmarks habituales, y optimizar sólo y
exclusivamente ese código, dando resultados mucho mejores que los que se
obtendrían con un código similar en una aplicación real o dando resultados
optimizados aún en el caso de que el compilador no haya activado esta opción.
Esto hizo IBM cuando produjo una versión nueva de su compilador de C para las
estaciones de trabajo IBM System/6000, o algunos fabricantes de tarjetas de
video que incluyeron código de aceleración de WinBench directamente en un ASIC.
Hay incluso una empresa, KAP, que mejora compiladores para que optimicen código de algún
benchmark, específicamente Matrix300, esto, a largo
plazo no sirve de mucho, porque es. Incluso en algún caso, había compiladores
que eliminaban totalmente el bucle principal del benchmark, como sucedió con
Whetstone y un compilador de IBM (hecho que no he sido capaz de comprobar, por
cierto). También lo ha hecho Sun con CaffeineMark, un benchmark para Java. Posiblemente, lo mismo haya sucedido con estos cambios de versión de driver que dieron tal diferencia entre
tarjetas..
Análisis del benchmark independiente
de la máquina. En algunos casos, los lenguajes como el Java o los compiladores
como el gcc de la GNU, crean un código independiente de la máquina, que
posteriormente se ensambla o interpreta por una máquina virtual. En tal caso, se
puede analizar ese código, como se hace en [Conte91], para concluir qué
características debe de tener un ordenador que ejecute ese código lo más rápido
posible. Esto permite, por ejemplo, dimensionar las caches para que se minimicen
los fallos de página. Sin embargo, una vez más, las mejoras sólo serán
aplicables para los programas incluidos en el benchmark, aunque en este caso los
resultados sean de aplicación más genérica.
Precisamente por esta razón, la
mayoría de los benchmark estándar cambian cada cierto tiempo. SPEC se revisa
cada 3 años, y hasta ahora ha habido tres versiones: SPEC89, 92, 95 y 2000
(todavía están preparando la siguiente en el año 2005). De esta forma, cuando
los fabricantes han aprendido a engañar un benchmark, se propone uno
nuevo.
En teoría, de todas formas, debería ser posible crear un benchmark que
no se pueda engañar, como afirman en este trabajo, que no parece
haber tenido mucho éxito. Solo que es difícil.Otra forma de engañar a un benchmark como ya hizo Sun es al usarlo con un servidor de páginas webs, servir las páginas desde la caché.
Un benchmark interesante para bases de datos es el TPC:
TPC (Transaction Processing Performance Council) es un consorcio que propone benchmarks en el área de procesamiento de transacciones. Hay varios benchmarks propuestos; hoy en día los más usados son TPC-C y TPC-D. Ambos tienen como entorno de referencia el siguiente: un sistema cliente, que genera peticiones de bases de datos usando un front-end, y un sistema servidor, que ejecuta el intérprete del lenguaje de bases de datos, generalmente SQL, y desde el mismo accede a un sistema de gestión de bases de datos. Cada transacción debe de ser atómica, es decir, se lleva a cabo o no completa, y además los sistemas deben de estar disponibles 24/7, 24 horas al día 7 días a la semana.
Estos benchmarks son de muy alto nivel, o más bien, ejercitan todos los niveles del sistema, desde la jerarquía de memoria, incluyendo memoria secundaria, pasando por el sistema operativo, hasta los programas que resuelven un problema concreto.
Las métricas que se proporcionan con estos benchmarks son de dos tipos: peticiones/tiempo, número de usuarios, y precio/prestaciones; hay unas reglas estrictas para evaluar éste último. Se verá a continuación cada uno de los benchmarks por separado.
h5e.incWrite('TPC-C')Otros benchmark interesantes son los creados para la Web:
4.3.2 SPECWebxxx y otros benchmarks de servidores web
SPECWeb2005 (http://www.spec.org/osg/web2005/) es la última versión de un benchmark que se concibió originalmente en el año 95; es un benchmark sintético para medir las prestaciones de sistemas como servidores web. Inicialmente incluía sólo páginas estáticas, pero hoy en día ha cambiado mucho. Tiene las siguientes características:
Combina contenido estático y dinámico, pero se basa más en el estático que en el dinámico.
El contenido estático contiene ficheros de diferente tamaño y frecuencia decreciente; y dentro de cada "nivel", los ficheros tienen tamaños que se incrementan en un número fijo de Ks. Por ejemplo, los del nivel de 100Ks se incrementan de 10 en 10 Ks. Se sigue una ley de Zipf (número de peticiones exponencialmente decreciente con el tamaño) para decidir qué fichero se pide.
El resultado principal de este benchmark es lo que se denomina "conexiones simultáneas conformantes", es decir, peticiones simultáneas que es capaz de manejar; se suele repetir tres veces y se da la mediana de los tres resultados como resultado válido.
Al principio, este benchmark recibió bastante atención por parte de los medios; por ejemplo, este artículo cuenta como se triplica prácticamente, sobre la misma máquina, las prestaciones de un servidor RH Linux sobre un servidor IIS. Sin embargo, mirando un poco de más cerca, vemos a qué se puede deber esta ventaja. El servidor que usa el sistema RedHat es Tux, denominado actualmente Red Hat Content Accelerator, un servidor que se ejecuta como tarea en el kernel, en un sistema exclusivamente dedicado a eso (prácticamente). De hecho, los servidores web más potentes no suelen ser los más conocidos.
De hecho, el uso de este servidor web es relativamente irrelevante, ni siquiera aparece en el informe de servidores web. Por lo tanto, el hecho de que se use o no este servidor puede ser totalmente irrelevante para un caso real, donde los servidores van a ser probablemente el Apache o el IIS. Al parecer, la imposibilidad de superar a este servidor en los benchmarks ha hecho que la gente pase de ejecutarlo sobre sus máquinas, y probablemente conducirá a la revisión del mismo (igual que sucedió con el SpecWEB96, que tuvo que ser revisado por la introducción por parte de Sun del Network Caché Accelerator, un módulo del kernel que metía las páginas estáticas en un buffer de la memoria del kernel).Terminamos el tema 4 y para terminar la clase vemos el último video del día.
