Etiquetas

10/26/2006

Ubuntu Edgy Eft en la calle

Nueva versión de Ubuntu en la calle. El apt-get dist-upgrade me descarga a una media de 40 kbytes/s , así que creo que algo de éxito está teniendo.

Entre las mejoras, también incluye el recién lanzado Firefox 2.0. Todo un record.

10/12/2006

Diario Erasmus

Como dije antes, ahora estoy de Erasmus. He comenzado un nuevo diario para escribir sobre mis vivencias lejos del hogar.

10/08/2006

Usando valgrind para optimizar el uso de la caché

Valgrind es una herramienta muy usada para comprobar los fallos de memoria en un programa, con la herramienta memcheck. Pero no se habla mucho de la herramienta que incluye para comprobar fallos de caché, cachegrind.

El aprovechamiento de la memoría caché es muy importante, ya que su velocidad es muy superior a la de la memoria RAM. Por desgracia, esa velocidad es inversamente proporcional a su tamaño, y si un dato no se encuentra en la caché hay que traerlo de memoria principal, incurriendo en una gran penalización de tiempo. Si hay bucles de por medio, dicha penalización se multiplica.

La herramienta cachegrind permite comprobar esos fallos de caché, configurando incluso su tamaño (muy interesante para simular arquitecturas con otros tamaños de caché). Ésta es la forma de usarla:

$ valgrind --tool=cachegrind --D1=16384,2,128 --L2=65536,2,128 programa


  • En primer lugar "--tool=cachegrind" indica que usaremos la herramienta de simulación de caché.

  • A continuación se especifican los tamaños, asociatividad y tamaño de vía de las memorias caché (si no se especifican se usarán los de la máquina). En primer lugar está la de nivel uno, dividida en datos e instrucciones (D1 e I1, aquí no especificada), y luego la caché de nivel 2 L2 (que es única para datos e instrucciones). Para cada una de ellas se indican, en orden, tamaño en bytes (debe ser potencia de 2), asociatividad (es decir, número de operaciones de lectura/escritura simultáneas) y tamaño de la línea caché (número de bytes que pasan en cada transferencia).

  • Finalmente, el programa a comprobar.



He hecho este programa simple que no es nada óptimo a la hora de acceder a memoria:

matriz.c

#define N 512

int main(int argc, char **argv){
double matriz[N][N];
int i, j;

for (i = 0; i < N; i++)
for (j = 0; j < N; j++)
matriz[j][i] = matriz[j][i] * 2.0;
}



El problema es que el contador j es el que más cambia, y se usa para indicar las columnas de la matriz. En C, el compilador guarda los datos de las filas de forma contigua en memoria, y las columnas suelen estar lo suficientemente alejadas unas de otras como para que no quepan en caché varias columnas.

Con valgrind vamos a simular el efecto que esto tendría en una caché de nivel 2 de 16 Kbytes y líneas caché de 512 bytes (igual al tamaño de fila de la matriz), que sería este comando:

$ valgrind --tool=cachegrind --L2=16384,2,512 ./matriz

Estos son los resultados:


=9666== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==9666== For more details, rerun with: -v
==9666==
--9666-- warning: Pentium 4 with 12 KB micro-op instruction trace cache
--9666-- Simulating a 16 KB I-cache with 32 B lines
==9666==
==9666== I refs: 4,346,532
==9666== I1 misses: 959
==9666== L2i misses: 172
==9666== I1 miss rate: 0.02%
==9666== L2i miss rate: 0.00%
==9666==
==9666== D refs: 2,171,229 (1,887,833 rd + 283,396 wr)
==9666== D1 misses: 263,896 ( 263,701 rd + 195 wr)
==9666== L2d misses: 262,953 ( 262,896 rd + 57 wr)
==9666== D1 miss rate: 12.1% ( 13.9% + 0.0% )
==9666== L2d miss rate: 12.1% ( 13.9% + 0.0% )
==9666==
==9666== L2 refs: 264,855 ( 264,660 rd + 195 wr)
==9666== L2 misses: 263,125 ( 263,068 rd + 57 wr)
==9666== L2 miss rate: 4.0% ( 4.2% + 0.0% )


La tasa de fallos en la caché de nivel 2 de datos (L2d miss rate) es del 12,1%, todas ellas en la lectura (más de 260.000 fallos de lectura con un número parecido de peticiones).

Es decir, si el bucle tiene 512*512=262144 iteraciones, estamos obteniendo al menos un fallo de caché en cada acceso a la matriz debido a que procesamos el dato de una fila y la desechamos para pasar después a la fila siguiente. Tras cierto número de filas procesadas, la caché está tan llena que sobreescribe los datos de la primera fila para introducir la nueva. En la siguiente iteración del bucle en que cambia el valor de i (proceso del segundo elemento de todas las filas), los datos se han eliminado y hay que volver a captarlos.

Si en el programa intercambiamos los contadores así:

matriz[i][j] = matriz[i][j] * 2.0;

El acceso será ahora por filas, pasando a la siguiente cuando se haya procesado toda la fila actual. Es decir, primero trabajaremos con posiciones de memoria contiguas y por tanto cuando la caché se llene se librará de datos que no se volverán a necesitar. Veamos el resultado con valgrind:


==9667== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==9667== For more details, rerun with: -v
==9667==
--9667-- warning: Pentium 4 with 12 KB micro-op instruction trace cache
--9667-- Simulating a 16 KB I-cache with 32 B lines
==9667==
==9667== I refs: 4,346,542
==9667== I1 misses: 960
==9667== L2i misses: 171
==9667== I1 miss rate: 0.02%
==9667== L2i miss rate: 0.00%
==9667==
==9667== D refs: 2,171,230 (1,887,834 rd + 283,396 wr)
==9667== D1 misses: 34,525 ( 34,330 rd + 195 wr)
==9667== L2d misses: 4,912 ( 4,856 rd + 56 wr)
==9667== D1 miss rate: 1.5% ( 1.8% + 0.0% )
==9667== L2d miss rate: 0.2% ( 0.2% + 0.0% )
==9667==
==9667== L2 refs: 35,485 ( 35,290 rd + 195 wr)
==9667== L2 misses: 5,083 ( 5,027 rd + 56 wr)
==9667== L2 miss rate: 0.0% ( 0.0% + 0.0% )


Mucho mejor, ahora la tasa de fallos es de 0,2%. Ahora sólo hay unas 35.000 referencias a la caché de nivel 2 (ya que la caché de nivel 1 trabaja con una fila completamente captada antes de pasar a la siguiente no captada), y unos 5.000 fallos de caché de nivel 2.

Nota: el programa está compilado usando gcc con opciones de depuración y ninguna optimización..

La diferencia de 260.000 a 5.000 es muy importante si tenemos en cuenta que la caché de nivel 2 suele ser 10 veces más rápida que la memoria RAM.

Con esto espero que haya explicado bien la importancia de un correcto uso de la caché para aumentar la velocidad de proceso y cómo valgrind puede ayudar a lograrlo.

Estos conceptos los estudié en mayor profundidad en la asignatura de Ingeniería de Computadores, y me hubiese venido bien saber por entonces de la existencia de cachegrind.

Más IDEs, ahora multiplataforma y libres

En mi búsqueda por herramientas de desarrollo con dos bes y una g (buenas, bonitas y gratis) he redescubierto dos resultonas:
  • NetBeans 5.0, un IDE para Java (de hecho escrito en ese lenguaje) que además puede usarse para proyectos en C/C++. Lo que más interesa es que tiene un editor de interfaces gráficas bastante bueno, ocupa mucho menos en disco y consume menos memoria que otras alternativas (Eclipse y Borland JBuilder). Ha mejorado mucho desde que usé las versiones 4.X, cuyo editor gráfico era bastante problemático y en general era mucho más lento.

  • CodeBlocks, un IDE para C/C++ desarrollado con la librería multiplataforma wxWidgets. Aunque no ha habido una versión estable desde 2005, se puede descargar de su página una compilación diaria de la rama de desarrollo, que es más completa y estable. El editor de interfaces gráficas aún petardea, pero empieza a ser usable. El resto va bastante bien, con uno de los mejores depuradores que he visto en IDEs libres. También ha mejorado mucho desde que probé la versión estable, y es mucho más ligero que la mayoría de alternativas.
En ambos casos su descarga y uso es gratuita, y son multiplataforma (Netbeans funciona donde funcione Java, y CodeBlocks ha sido compilado para Windows y Linux).

Erasmus

El martes (10 de octubre) cojo el avión para Alemania.

Es posible que la próxima semana esté muy ocupado y tarde en responder al correo o actualizar este blog.

10/06/2006

GParted, redimensionando particiones

Mi partición de Windows en el portátil era mínima. Hasta ahora había tirado de VMware para ejecutar Windows desde Linux. Pero tener dos sistemas operativos ejecutándose con 512 MB de RAM no da mucho de sí (la máquina virtual de Windows renqueaba).

Así que decidí enmendar el error básico que hice al instalar linux. La partición / la creé de 10 GB y aparte creé una /home de 20, dejando sólo 10 para Windows. Tener una partición / en un ordenador casero (no un servidor ni nada parecido) de más de 6 GB es un desperdicio.

Al final usé el LiveCD de GParted para quitarle 4 GB a la partición / y ampliar la de Windows para aprovechar ese espacio. El LiveCD es una maravilla, en menos de 30 MB incluye un entorno XFCE mínimo (de hecho eché de menos algún Solitario para entretenerme) y las utilidades necesarias para gestionar un gran número de sistemas de archivo distintos.

Lo único "malo" es que es algo paranoico, así que la operación más complicada que hice (que implicaba reducir tamaño de / y desplazar el comienzo de la partición a la derecha) se alargó más de lo debido por las operaciones de simulacro en sólo lectura y las continuas comprobaciones del sistema de archivos tras cada alteración.

Aun así, ha funcionado y ya puedo instalar unas cuantas herramientas sobre las que ya he escrito antes.

Un par de consejos antes de usarlo:

  • Aseguraos de que os habéis bajado la imagen ISO correctamente antes de grabarla.

  • Guardad los datos importantes de las particiones que se modificarán, no hay garantías de que todo salga bien.

  • Es mejor hacer cada operación una por una (pulsando "aplicar cambios") en lugar de hacer todas del tirón, de esa manera es más posible encontrar fallos de programación.

  • Tras alterar particiones NTFS, en el siguiente arranque de Windows se detectarán inconsistencias y ofrecerá comprobar el sistema de archivos. No canceléis esa operación, es completamente normal.

Visual Studio Express y TurboExplorer, creando comunidad

No soy precisamente un fan de Microsoft. De hecho uso linux el 99% del tiempo y me gustaría no tener que usar Windows nunca.

Pero está claro que a veces no queda más remedio que dar el brazo a torcer y trabajar bajo Windows, la mayoría de las veces con herramientas cuya licencia cuesta un ojo de la cara. Por eso ayuda mucho encontrarte con buenas herramientas gratuitas. En este caso, Visual Studio Express. Se trata de una versión gratuita de Visual Studio dividida en varias herramientas (C#, C++, Java, etc.). Una vez descargado e instalado sólo hay que pedir una clave de registro usando tu cuenta Windows Live (la misma del messenger, vamos).

Lo bueno es que cada herramienta ocupa relativamente poco (en el caso de C#, unos 60 MB de disco sin instalar SQL Server Express ni la documentación de MSDN), y se pueden instalar todas de forma separada en el mismo equipo. Por supuesto existen diferencias con respecto a la versión profesional, como un máximo de 40 usuarios en el servidor SQL y foros para desarrolladores en lugar de soporte técnico profesional.

Visual Studio Express está creado para estudiantes, programadores aficionados y gente, como yo, demasiado pobre para comprar licencias. La idea es crear una comunidad de desarrolladores fuera del ámbito profesional que usen las tecnologías de Microsoft, al estilo de lo que lleva pasando años en el Software Libre. En ese sentido, hasta tienen la web Coding4fun con artículos y tutoriales escritos por los aficionados.

Borland está intentando lo mismo con TurboExplorer. Pero las últimas versiones de sus herramientas no me han gustado mucho, siendo más lentas y consumiendo muchos más recursos que maravillas como Delphi 2.0 (lo mejor que he usado para programar en Windows). Claro que a caballo regalado...

10/05/2006

Búsqueda de código en Google

Google ya tiene un buscador de código que permite especificar la licencia, lenguaje de programación y, lo mejor de todo, usar expresiones regulares en la búqueda.

Alguna posibilidad interesante es usar el motor de búsqueda para detectar errores, por ejemplo buscando ifs con punto y coma al final, un fallo que hace que no se evaluen las intrucciones posteriores según la condición planteada.

Todavía está en fase beta, pero tiene bastante potencial. Especialmente como apoyo a las prácticas de informática ;)

Mi anterior blog

Antes de que se me olvide, éste es mi anterior diario. He cambiado a blogger mayormente por la inestabilidad del servidor de UNIA, la imposibilidad de usar Google Analytics y los constantes apagones del edificio donde se alojaba el servidor.