Situándonos…

Para variar un poco respecto de las últimas prácticas de la asignatura
donde he centrado las evaluaciones en el rendimiento de los discos duros,
voy a dirigir la práctica final al estudio del rendimiento de diversos
navegadores.

Después de muchos años de hegemonía por parte de las diferentes
versiones de los navegadores Internet Explorer, se está produciendo un pequeño
pero constante cambio en la tendencia de los usuarios de emplear otros
navegadores. Esto supone un beneficio en dos sentidos:

• los desarrolladores no comprometidos con los estándares no hacen sus páginas
  pensando exclusivamente en Internet Explorer (el manido “Optimizado para Internet Explorer”)
• los usuarios finales descubren que esos nuevos navegadores son más rápidos,
  versátiles, seguros, etc. que el que utilizaban anteriormente, así que en cierto
  sentido obligan a Microsoft a mejorar su propio navegador (aunque por ahora sigue
  siendo decepcionante incluso con su última versión)

Sabiendo estoy voy a realizar una serie de pruebas en los distintos navegadores disponibles para
diferentes sistemas operativos y centrar el análisis en 3 puntos:

• tiempo de renderizado de páginas web
• velocidad de ejecución de javascript
• grado de cumplimiento de estándares CSS

Para ello voy a utilizar las siguientes herramientas:

• Análisis global del navegador con Peacekeeper
• Rendimiento de javascript con SunSpider.
• Rendimiento de javascript con CelticKane.
• Acid2 y Acid3 de Acid Tests para comprobar
  el grado de cumplimiento de los estándares CSS.
• Consumo de memoria con 1, 5 y 10 pestañas abiertas mediante el monitor de recursos del sistema.
• Velocidad de carga de 5 webs de referencia con el cronómetro de LifeHacker.com.

Y finalmente lo más importante, los navegadores. Estos se probaran en su versión de
desarrollo más reciente, para poder valorar los progresos que se hayan hecho desde
el lanzamiento de su última versión estable. Las pruebas se ejecutarán sobre Kubuntu 9.04
y Windows XP SP3 y se valorarán los siguientes navegadores allá donde estén disponibles:

• Mozilla Firefox
• Google Chrome
• Opera
• Arora
• Konqueror
• Apple Safari
• Internet Explorer

Para evitar en la medida de lo posible los errores de apreciación
y las posibles interferencias de terceros programas, los tests se
ejecutarán 3 veces y se tomará el mejor resultado como referencia.

Todas las pruebas se realizan sobre el sistema base recién iniciado y con una sola instancia
y una sola pestaña del navegador (cuando convenga, por ejemplo no para el test del uso de memoria
con varias pestañas abiertas) y un editor de textos activos. Para cada ejecución
de una prueba se cerrará e iniciará nuevamente el navegador.

Ejecución

La primera ejecución es la de propósito general con Peacekeeper.
Basta con acceder a su página y pinchar en Run Test. El navegador pasará a ejecutar
una serie de pruebas en las que es recomendable interactuar lo menos posible con él
y mantener una única pestaña abierta. Realizaremos esta prueba 3 veces cerrando y volviendo
a abrir el navegador.

A continuación ejecutare el test SunSpider. Este test no es necesario ejecutarlo 3 veces ya que
el propio test contempla ejecutar varias veces las pruebas y mostrar una media de los resultados.

Le sigue CelticKane, que de nuevo volveremos a ejecutar 3 veces para quedarnos con la mejor cifra.

Para los tests Acid2 y 3 se realizarán capturas de pantalla del renderizado que hace cada navegador,
a fin de poder comprar fácilmente cuánto se ajustan al estándar de un simple vistazo.

La carga de memoria del navegador con 1, 5 y 10 pestañas abierta se realizará abriendo las páginas siempre
en el mismo orden y siempre limpiando antes la caché del navegador. Las páginas que se abrirán son:

• http://www.google.es
• http://www.msn.com
• http://www.yahoo.com
• http://www.gmail.com
• http://www.youtube.com
• http://www.flickr.com
• http://www.planetkde.org
• http://www.elotrolado.net
• http://es.wikipedia.org
• http://www.tajavinagre.net

Por último mediremos el tiempo de carga de 5 páginas diferentes (siempre partiendo de una caché limpia)
mediante la herramienta “cronómetro” de LifeHacker. Las páginas que se visitarán serán:

• http://es.wikinews.org/wiki/Portada
• http://www.smashingmagazine.com/
• http://changlonet.com/blog/
• http://www.webmasterlibre.com/
• http://www.digg.com/

Resultados

Kubuntu 9.04

Pruebas Javascript

En esta batería de pruebas vemos que despunta el rendimiento que consigue Chrome, seguido
por Arora, con el que comparte el motor Webkit de renderizado pero no el intérprete de Javascript.
Konqueror y Firefox cierran la cola y dejan a Opera en la mitad de la tabla.

Acid2

• Minefield(v3.6a1pre)
• Chrome(v3.0.183.1)
• Opera (v10.00)
• Arora(v0.7.0)
• Konqueror(v4.2)

Aquí podemos ver una pequeña regresión en el motor de renderizado de Firefox, ya que no supera correctamente el test.

Acid3

• Minefield(v3.6a1pre)
• Chrome(v3.0.183.1)
• Opera (v10.00)
• Arora(v0.7.0)
• Konqueror(v4.2)

Premio para Opera, el único que pasa al 100% este test.
Esta es una prueba para preparar a los navegadores para un estándar aún en desarrollo y que aún no ha empezado a ser
explotado. Vemos como, salvo Konqueror, todos superan una puntuación de 90 y renderizan una imagen muy similar al objetivo.
Konqueror es el que peor se comporta en esta prueba llegando solo a 87 puntos. Los navegadores con motor Webkit y Konqueror
(en cuyo motor originalmente se basó Webkit) fallan al realizar el test de enlaces a iframes.

Consumo de memoria

Haciendo honor a su merecida fama, vemos como Firefox es el navegador que más memoria consume
en todos los casos. Mención especial para Konqueror, ya que aunque es el segundo más pesado con una sola pestaña,
consigue dejar la menor huella al aumentar el número de pestañas.

Tiempo de carga

Firefox es el más rápido de toda la batería de pruebas, seguido de Opera que tiene un
comportamiento especialmente regular. En el lado opuesto están Arora y Konqueror, que es el más lento.

Windows XP SP3

Pruebas Javascript

Cambiamos de sistema operativo pero en las pruebas Chromer sigue siendo, por poco,
el que mejor rendimiento ofrece. Lo sigue muy de cerca Safari, con quien también comparte motor Webkit pero
que de nuevo tiene un intérprete de Javascript diferente. El peor comportamiento con diferencia es el de
Internet Explorer 8, seguido por Konqueror en su versión para Windows que ni siquiera pudo superar
el test Celtic Kane al cerrarse inesperadamente al intentar ejecutarlo.

Acid2

• Minefield(v3.6a1pre)
• Chrome(v3.0.183.1)
• Opera (v10.00)
• Arora(v0.7.0)
• Konqueror(v4.2)
• Safari(v4)
• Explorer 8

Todos felices: todos los navegadores pasaron correctamente esta prueba.

Acid3

• Minefield(v3.6a1pre)
• Chrome(v3.0.183.1)
• Opera (v10.00)
• Arora(v0.7.0)
• Konqueror(v4.2)
• Safari(v4)
• Explorer 8

De nuevo Opera, al que se le une Safari pasan la prueba al 100%.
Horroroso el comportamiento de Internet Explorer 8.

Consumo de memoria

Opera es el más comedido a la hora de usar la memoria, seguido por Firefox y Safari
en ese orden. Vemos como Chrome dispara su consumo de memoria al pasar de 1 a 5 pestañas.

Tiempo de carga

De nuevo Firefox es el mas veloz, seguido muy de cerca por
Internet Explorer 8 en esta prueba: no preocuparse
de renderizar las cosas correctamente tiene sus ventajas.

Cara a cara

Una vez vistos y comentados los resultados de las pruebas por separados vamos a pasar a enfrentarlos. Así podremos
hacernos una idea de qué comportamiento tienen los navegadores en los diferentes sistemas operativos.

Pruebas Javascript

Firefox y Opera se comportan mejor ejecutados bajo Windows XP SP3. Chrome, Arora y Konqueror bajo Kubuntu 9.04.
No hay referencias para comparar Safari e Internet Explorer 8

Consumo de memoria

Podemos apreciar como el consumo de memoria de Firefox es muchísimo más comedido en Windows XP SP3,
comportándose también Opera mejor en este S.O. Al igual que en el apartado anterior, Chrome, Arora y Konqueror consumen
menos memoria ejecutados bajo Kubuntu 9.04

Tiempos de carga

Podemos ver claramente como, en general, el tiempo de carga de páginas es siempre menor en Kubuntu,
siendo Opera, Arora y Konqueror a los que peor les sienta el cambio de entorno.

Conclusiones

Tras comprar los resultados, se puede afirmar que para navegar con Firefox y Opera es mejor hacerlo
bajo Windows XP SP3, ya que tanto el rendimiento del intérprete de Javascript como el consumo de memoria son menores.
Los mejores navegadores para este sistema operativo son Firefox y Safari, con una diferencia muy ajustada.

En Kubuntu 9.04 los navegadores que mejor resultado ofrecen son Chrome y Firefox, que aunque
no puntúa tan alto en pruebas de Javascript y abusa de la memoria, tiene un mejor comportamiento en la velocidad de carga
de páginas web que Arora, que quedaría en tercera posición.

Finalmente, atendiendo a los criterios generales, la mejor combinación para navegar sería Chrome ejecutado sobre Kubuntu 9.04.

Para ser continuista con el resto del trabajo que he estado realizando en las últimas prácticas seguiré centrándome en el rendimiento de los discos duros en esta.

Para la ocasión desarrollaré una aplicación sencilla que determinará el rendimiento del disco duro sobre diferentes sistemas de archivo en diferentes sistemas operativos en las operaciones de lectura y escritura. Para hacer el benchmark lo más portable posible he decidido programarlo en un lenguaje interpretado que permitirá desplegarlo rápidamente en cualquier pc con sólo instalar el intérprete, en lugar de tener que andar compilando diferentes ejecutables para cada sistema operativo.

Lo que pretendo averiguar con esta batería de tests es qué sistema de archivos obtiene mejor rendimiento de mi disco duro. Para ello los tests se ejecutarán sobre Kubuntu 9.04, ArchLinux 2009.0 y Windows XP SP3. En las máquinas GNU/Linux los test se repetirán para las particiones ReiserFS y Ext4 y en Windows XP se realizarán en una partición de tipo NTFS. El referente serán los datos Kubuntu ya que es el sistema operativo que uso a diario.

Para evitar en la medida de lo posible los errores de apreciación y las posibles interferencias de terceros programas, los tests se ejecutarán 3 veces y se realizará la escritura y lectura de un fichero de 1GiB para obtener unos tiempos apreciables, ya que en las pruebas preliminares con 100MiB apenas había diferencias entre los resultados.

Finalmente se pondrán en común los resultados y se realizará una valoración de qué sistema de archivos ha presentado mejor rendimiento. Es importante recalcar que para estos tests no se realizará ningún ajuste para el rendimiento del disco duro, ya que como se comprobó en la práctica anterior, los resultados eran prácticamente idénticos.

Ejecución

El programa que va a realizar la prueba es el siguiente:

#!/usr/bin/perl

use Benchmark;

my $tiempo_inicial = new Benchmark;

open FILE, “>bench” or die $!;
binmode FILE;
# para el test final hacerlo con 1GB = 1024^3 = 1073741824
for( $i=0; $i < 1024*1024*1024; $i++ ) {
print FILE "0";
}
close FILE;

my $tiempo_final = new Benchmark;
my $tiempo_total = timediff($tiempo_final, $tiempo_inicial);
print "La escritura tardó: ",timestr($tiempo_total),"\n";

my $tiempo_inicial = new Benchmark;

open FILE, "bench" or die $!;
binmode FILE;
my ($buf, $data, $n);
while (($n = read FILE, $data, 1) != 0) {
# print "$n bytes read\n"; $buf .= $data;
}
close(FILE);

vmy $tiempo_final = new Benchmark;
my $tiempo_total = timediff($tiempo_final, $tiempo_inicial);
print "La lectura tardó: ",timestr($tiempo_total),"\n";

# borramos el archivo
unlink("bench");

Se hace uso del módulo Benchmark que nos permitirá obtener resultados de tiempo amigables para personas (segundos de reloj) y también información de los tiempos que el programa es ejecutado en el espacio del usuario y del sistema.

Resultados

Conclusiones

Como podemos observar en las gráficas los tests se han comportado de modo un tanto peculiar. Las pruebas que mejores resultados han arrojado han sido las realizadas sobre ArchLinux en un sistema de ficheros ReiserFS, aunque con Ext4 también ha superado al resto. En segundo lugar estaría Windows XP con el sistema de archivos NTFS y por último Kubuntu 9.04 con ReiserFS de nuevo. Hay que tener en cuenta que al realizarse el test con un lenguaje interpretado tal vez no se hayan obtenido resultados tan exactos como los que se hubieran recogido con tests con aplicaciones nativas, pero dado el carácter de portabilidad que requería el test esta es la mejor apuesta.

Situándonos…

He decidido centrarme en el objetivo del rendimiento del disco duro,
ya que en la anterior práctica obtuve unos rendimientos bastante diferentes sin
una razón aparente. En primer momento lo atribuí a que, al ser un equipo
portátil, puede que el descenso de rendimiento se debiera al funcionamiento de
algún tipo de rutina de ahorro de energía del sistema, de modo que esta vez me
he decidido a repetir varias veces los tests y, además, a probar EXT4, la
reciente versión del sistema de archivos que se supone que rinde mucho más que
los actuales sistemas.

El motivo de centrarme en este aspecto es, en primer lugar, por la
sensación personal de que, a menudo, los ordenadores portátiles que incluyen
discos de 5400 rpm funcionan con una lentitud muy superior a otros similares con
discos de 7200 rpm. Por otra parte la aparición de los nuevos discos SSD y de
nuevos sistemas de archivos podrían dar un gran empujón a los PCs si realmente
resulta cierto que su rendimiento es superior. Por desgracia no he podido
ejecutar los tests sobre discos SSD, ya que no tenía ninguno, ni propio ni de
algún conocido, y me parecía que ejecutarlo sobre un pendrive, una tarjeta SD o
similar no sería lo mismo que el hacerlo sobre uno de estos.

Para hacer este estudio voy a utilizar de nuevo la herramienta href="http://www.phoronix-test-suite.com/?k=downloads" >Phoronix
Test Suite, ya que permite ejecutar lotes de pruebas y luego comparar los
resultados de estas. La prueba que se realizará es la que lleva por nombre
“disk”.
Además, tal y como comenté en la anterior práctica, esta
vez está disponible la versión definitiva de Kubuntu 9.04, así que se realizarán
sobre este sistema operativo, que se supone también incluye mejoras de
rendimiento frente a su versión anterior.

El escenario ideal sería encontrar un rendimiento menor al ejecutar el test
sin hacer ningún ajuste y un rendimiento superior tras ajustar los parámetros
del disco duro. Así mismo, la prueba con Ext4 debería arrojar un rendimiento
mucho mayor que el actual.

Ejecución

Voy a llevar a cabo la evaluación mediante 4 pruebas diferentes, 2 sin
tocar los parámetros de configuración del disco duro y 2 tras tocarlo. Además,
de esas cada una será en un sistema de archivos diferente: 2 en ReiserFS y 2 en
Ext4.
Para ejectuar cada test lo haremos mediante la terminal:

phoronix-test-suite benchmark disk

Para deshabilitar todas las funciones de ahorro de energía del sistema
sobre el disco duro, ejecutaremos en la terminal, como superusuarios, los
siguientes comandos:

Hace que el disco permanezca despierto en todo momento, sin que pare a
descansar.

hdparm -B 255 -S 240 -M 254 /dev/sda

Desactivar la optimización de discos para portátiles

echo 0 > /proc/sys/vm/laptop_mode

Activar el perfil de rendimiento máximo para los discos SATA

echo max_performance >
/sys/class/scsi_host/host0/link_power_management_policy

echo max_performance >
/sys/class/scsi_host/host1/link_power_management_policy

Cada ejecución nos generará un test que tendremos que poner en común con
los demás al final mediante la ejecución del comando:

phoronix-test-suite merge

Resultados

Una vez finalizados los tests y puestos en común, la aplicación guarda los
resultados en documentos
XML que se pueden visualizar con el
navegador.

Consideraciones

Bueno, lo primero de todo decir que no me esperaba este resultado. En
realidad no esperaba ninguno de los dos, me explico:
Viendo todos los ajustes que hice de los parámetros del disco duro, esperaba
realmente que el rendimiento fuera muy distinto cuando las opciones de ahorro de
energía están activadas de cuando están desactivadas, sin embargo, la diferencia
de rendimento apenas es apreciable en el caso de ReiserFS y son inexistentes en
el caso de Ext4. En cuanto a este último, pues tampoco me esperaba que su
rendimiento fuera tan superior (en la gráfica, más es mejor).
Es que llega prácticamente a rendir el doble. Si bien en diferentes sitios de la
red ya comentaban el aumento de rendimiento que se conseguía, siempre soy un
poco excéptico con estas cosas ya que en el anonimato de internet las cosas se
pueden exagerar y distorsionar muchísimo, pero me alegra equivocarme en este
caso.

Como conclusión a este estudio, resalto los dos resultados finales: no
merece la pena el esfuerzo en encontrar información sobre aumentar el
rendimiento del disco duro ya que prácticamente no tiene ningún resultado
práctico. Existe, pero el tiempo que se tarda en encontrar la información,
corroborarla (equivocarse utilizando hdparm puede ser fatal para una unidad de
disco) y aplicarla no compensa el aumento de prestaciones.
Por otra parte, el probar diferentes sistemas de archivos sí puede ser
beneficioso ya que una decisión tan sencilla como elegir el tipo de formato al
instalar el sistema, puede tener como consecuencias un rendimiento mucho mejor,
o mucho peor, y lo lamentable es que si no se conoce bastante los sistemas de
archivos, no se tiene noción de saber cuál elegir, aparte del recomendado por
cada distribuidor.

Situándonos…

Para esta práctica decidí emplear el profiler gprof en un entorno GNU/Linux sobre una aplicación desarrollada con las bibliotecas Qt para la asignatura Nuevas Tecnologías de la Programación. No obstante, la aplicación no era lo suficientemente pesada como para que gprof produjera resultados relevantes, con lo cual pasé a emplear otra práctica para la misma asignatura desarrollada en Java y hacer uso del plugin Profiler para Netbeans, también sobre GNU/Linux.

Instalación y uso.

La herramienta puede descargarse desde el menú de “Tools”/”Plugins” y buscando por “profile”. Una vez instalada se nos añadirán algunos elementos a la interfaz de Netbeans. Además de permitirnos medir el comportamiento de la aplicación, permite guardar los análisis y realizar comparaciones, de modo que nos facilita ver si una versión modificada de una aplicación es mejor que otra.

Cuando vayamos a realizar por primera vez el perfil, nos pedirá que realicemos una prueba de calibración del sistema y que integremos la información del perfil con nuestro proyecto actual.
Lo siguiente es realizarle el perfil al proyecto. Se puede enfocar de 3 modos: el uso de memoria, el uso de tiempo de CPU y la monitorización de la aplicación. Vamos a centrarnos en el uso de tiempo de CPU.

Resultados del perfil

Análisis de los resultados

Echándole un vistazo a los resultados vemos que en general todas las funciones son llamadas alrededor de 350 veces y que las funciones tienen un tiempo de CPU bastante bajo, aunque los 3 hilos de ejecución están vivos durante el 100% del tiempo de ejecución.

La explicación a que vivan durante el 100% del tiempo y de ese número tan redondo de ejecuciones es que el programa en cuestión es un clon sencillo de Pacman, los hilos se ejecutan de principio a fin para controlar el programa y las 350 iteraciones son los movimientos que el personaje ha hecho recorriendo el mapeado para comerse las bolitas. Podemos ver también que de media se ha cambiado de dirección unas 20 veces y que en otras 40 el personaje se ha intentado mover a una posición no válida y se le ha dicho que siga por donde iba. Es curioso ver la información que se puede sacar de aquí. Desconozco sin embargo qué es el Self time, una visita a la página del plugin no me ha aclarado eso en particular, y la ayuda del plugin tampoco ofrece exactamente algo que me pueda orientar.

Pasando a lo interesante, vemos que dos funciones en particular consumen bastante tiempo de CPU, son las funciones inicializa() de Main y dibujaFondo() de la cola de eventos de la AWT.

En el caso de inicializa, podemos considerarla comprensible ya que se encarga de crear los objetos la primera vez que se ejecuta la aplicación y por eso puede tener una mayor carga que otras funciones más sencillas.

No obstante el caso de dibujaFondo() refleja perfectamente uno de los problemas a los que me enfrenté en el desarrollo, y es que al mover el personaje por el mapa, la pantalla dejaba reflejada la posición anterior del personaje y también la posición actual, con lo cual al final no se veían mas que pacmans por todas partes. Para solventar eso al final lo que hice fué emplear doblebuffering y repintar cada vez que el personaje se movía el mapa. Sin embargo, pensaba que el modo en el que lo había implementado era más rápido, ya que la primera vez tenía que crear el mapa a partir de un string de chars, y las siguientes se creaba a partir de la primera versión del mapa. Tal vez la copia del bitmap y el reemplazo en pantalla consuman aún demasiado tiempo.

Consideraciones

En vista de lo comentado en los análisis de resultados, hacer más rápida la función dibujaFondo() sería clave para acelerar la aplicación. Tal vez podría utilizarse un acercamiento más local, redibujando únicamente la posición que ha abandonado el personaje en lugar de todo el mapeado. Esto sería sencillo ya que simplemente consistiría en poner un espacio en blanco (negro según el color del mapa) en donde antes estaba el personaje (si había un punto ya se lo habrá comido).

Situándonos…

El sistema que se analizará es Kubuntu 8.10 debidamente actualizado corriendo sobre un ordenador portátil Dell XPS M1330.
El monitor de rendimiento elegido es Phoronix Test Suite (del recurso Phoronix de la 1ª práctica). Este monitor está desarrollado para ejecutarse sobre sistemas compatibles con POSIX y permite llevar acabo test individuales, módulos de pruebas y comparativas con otras pruebas realizadas por usuarios de la herramienta mediante una sencilla interfaz de línea de comandos.

Instalación y configuración de Phoronix Test Suite.

La herramienta puede descargarse desde la página de descargas de Phoronix. En particular, se ha descargado el paquete deb, que nos facilita la instalación en nuestro sistema.
Una vez descargado, lo debemos instalar. Esto puede hacerse mediante alguna interfaz que proporcione el sistema o bien desde la consola mediante el comando:
sudo dpkg -i phoronix-test-suite*.deb
Este código hace 2 cosas, primero solicita ejecutar la orden que va después de ‘sudo’ como usuario root, y luego intenta instalar el paquete .deb indicado. Habrá que sustituir el * por la versión en particular de la herramienta que se haya descargado.

Una vez instalado, pasamos a ejecutarlo desde la terminal con el comando:
phoronix-test-suite
La ejecución nos mostrará los comandos disponibles para la herramienta.

La configuración del usuario, así como las opciones de los modos “batch” se guardan en ~/.phoronix-test-suite/user-config.xml y esta última puede ser modificada ejecutando el comando:
phoronix-test-suite batch-setup

Los colores, tamaño y otros atributos de las gráficas se pueden modificar mediante el archivo ~/.phoronix-test-suite/graph-config.xml, para más información, se pueden ver las etiquetas XML válidas en los comentarios de los archivos pts-core/functions/pts-interfaces.php and pts-core/objects/pts_CustomGraph.php

Ejecución

Para evaluar el rendimiento del sistema vamos a ejecutar los siguientes lotes de pruebas:

• Compilación
• Compresión
• Tareas Multinúcleo
• Pruebas de Memoria
• Pruebas de disco
• Sistema de archivos
• Juegos libres

La evaluación se llevará acabo mediante la ejecución en la terminal del comando:
phoronix-test-suite benchmark compilation compression multicore memory disk system-disk filesystem

Resultados

Al finalizar los tests, la aplicación guarda los resultados en documentos XML que se pueden visualizar con el navegador.

Además, también ofrece la opción de subirlos a internet para que estén disponibles como referencias futuras. Esto permite, por ejemplo, volver a ejecutar exactamente el mismo test que ha ejecutado esta máquina en otro sistema GNU/Linux y poder comparar los resultados.

Esta función es muy útil ya que permite por ejemplo ver si existen diferencias y cuáles son entre la versión x86 y la amd64 de una misma distribución, entre diferentes kernels en la misma distribución, entre distintas versiones de la misma distribución, o entre distintas distribuciones, para poder ver cuál rinde mejor en nuestro sistema.

No he hecho la comparación con la siguiente versión de Kubuntu (9.04) por no estar esta aún en un estado estable (RC) pero es de suponer que el rendimiento debe ser mejor ya que se han centrado en ese aspecto. También me gustaría poder compararla con Arch, pero ya se me pasó la fiebre de probar distribuciones y desde hace tiempo el ordenador se ha quedado para trabajar y para cacharrear está VirtualBox.
En cualquier caso, hacer la comprarativa sería tan sencillo como ejecutar:
phoronix-test-suite benchmark javi-31197-15059-9289

Consideraciones

En la ejecución de los tests, particularmente los de acceso a disco duro mostraban unos resultados bastante variables entre la primera ejecución y la 2ª y 3ª, siendo estos últimos mucho más uniformes. En mi opinión, esto puede deberse a que el sistema es un ordenador portátil y que como parte de las medidas de ahorro de energía el disco duro se deja aparcado.

Otro punto de interés es la 1ª ejecución de las pruebas de compilación de ImageMagick, donde varió bastante la segunda iteración de la 1ª y 3ª, mientras que en la 2ª ejecución del test los valores fueron todos homogéneos. Es de suponer que algún proceso se habría despertado y estaría consumiendo ciclos en ese momento particular.

Aparte de eso, todos los valores fueron bastante homogéneos en el resto de pruebas, por lo que no parece necesario reseñar nada de ellas. En cualquier caso, en la carpeta benchmark que acompaña a esta práctica se incluyen los logs de cada test por si fuera de interés consultarlos.