En el post anterior decía que el hecho de trabajar con software de código abierto es una ventaja para poder escalar, optimizar y/o sacarle mayor provecho a nuestros sistemas. Esta tarea no es fácil ya que:
- Hace falta saber programar (y que te guste ;)
- Hace falta conocer las herramientas de desarrollo (compiladores, depuradores, profilers, tracers…).
- Hace falta conocer la arquitectura hardware en la que estamos trabajando.
- Hace falta tener conocimientos matemáticos.
- Hace falta error y ensayo.
- Hace falta ponerse manos a la obra.
Esto no quiere decir que ahora esté negando lo que he escrito anteriormente ya que, recordemos, en el post anterior hablaba de científicos ;) En este caso, hablo de los que somos meros usuarios de nuestros sistemas o bien somos usuarios más avanzados, pero no nos hemos metido a fondo en el tema. También quisiera dirigirme a aquellos usuarios que creen que las cosas son más sencillas de lo que parecen ;)
La idea de escribir este post me ha venido de este otro publicado en LinuxPlanet y es que muchas veces tenemos la idea de que sólo por el hecho de tener un sistema multicore de 64 bits, nuestro equipo va a ir mejor o que por usar más opciones de compilación mejorará el rendimiento. Eso no siempre es así. Vamos a ver:
- Algunas aplicaciones no han sido programadas para sistemas multiprocesador, luego nos da igual el número de procesadores que tengamos ya que dicha aplicación sólo va a usar un procesador.
- Algunas aplicaciones sí se han desarrollado para sistemas multiprocesador (en el post de LinuxPlanet ponen el ejemplo de ffmpeg), pero los datos que manejan no se pueden dividir entre los procesadores, como ocurre con algunos streams de vídeo en cuyo caso un frame depende del anterior.
- Supongamos que nuestra aplicación y nuestros datos se han diseñado/desarrollado teniendo en cuenta sistemas multiprocesador, aparece ahora un nuevo problema: depuración. Depurar un programa multiprocesador no es nada fácil.
Primer paso: sistemas multiprocesador … comprendido.
Siguiente paso: 64 bits. Los 64 bits no necesariamente tienen por qué ser mejores. Para empezar, a lo mejor nuestra aplicación no ha sido migrada de 32 bits a 64 bits. ¿Por qué? Pues dependerá del desarrollador (si tiene tiempo y/o si tiene conocimientos) y de los datos que maneja la aplicación. Por ejemplo, ¿usar 64 puro y duro en escritorio “es mejor”? Pues hombre, depende de lo que hagas en el escritorio:
- Si usas un paquete ofimático, un navegador y un cliente de correo… poco vas a notar.
- Si te dedicas a diseño gráfico, 3D, edición de audio y/o vídeo, aplicaciones científicas… sí notarás mejora siempre y cuando la aplicación se haya diseñado para 64 bits, los datos que manejes bla, bla, bla, …
Opciones de compilación … madre mía, ya entramos en terreno peligroso. Hay quien piensa que al usar más opciones de compilación tendrá un sistema más “rápido” (sea lo que sea qué es eso de “rápido”). Esto es muy típico en distribuciones del tipo Gentoo o Linux From Scratch. Como he dicho al principio, una de las cosas que necesitamos es saber de matemáticas (aunque sean cosas muy básicas).
Voy a basarme en lo que dicen los desarrolladores de Gentoo para no postear mucho rollo, en todo caso, podéis buscar en Internet las opiniones de desarrolladores de otras distribuciones. Por ejemplo, Flameeyes lo explica muy bien en su post:
First of all, not all compiler flags are the same: there are flags that change behaviour of the source code, and others that should not change that behaviour. For instance the -ffast-math flag enables some more loose mathematical rules, this change the behaviour of the math source code as it’s no longer perfect; on the other hand the -ftree-vectorize only changes the output code and not the meaning of the source code, and should then be counted in as a safe flag.
Es decir, no siempre podemos basarnos en lo que debería hacer una opción de compilación ya que puede cambiar el comportamiento de la aplicación. Esto se puede deber a muchas cosas, como por ejemplo errores en el propio compilador y/o errores en la aplicación que estemos compilando, como dice Flameeyes:
[...] with the exception of the mplayer bug, most of the build and runtime failures aren’t straightforward to fix; and when the problem is in GCC, it might take quite a while before the issue is fixed; how should we work those situations out then, if not by filtering?
En su último párrafo dice:
And finally, users please understand that the flags like -ffast-math or -fvisibility that do change the meaning of the source code should not be used by users but should rather be applied directly by upstream if they are safe!
Este es un ejemplo concreto de utilización de opciones de compilación que pueden afectar al rendimiento de una aplicación. En la web de Gentoo hablan también en líneas generales del uso de opciones de compilación. Concretamente tiene un FAQ en el punto 3 en el que contestan a preguntas habituales y una de las respuestas es:
[...] You don’t need dangerous flags like these. Don’t use them. Stick to the basics: -march, -O, and -pipe.
Otro caso concreto es el de un usuario de Gentoo que anda compilando el Firefox. En una de sus respuestas en el foro de Gentoo dice:
Yeah.. my cflags are simple. -Os -fomit-frame-pointer -pipe.
In the mozconfig file I commented out the “strip-flags” option and just made the “mozilla-fallback” option to use -Os since it defaults to that anyways.
I finally got around to cold booting my newly recompiled -Os system.
1. The ram usage is MUCH lower than it was before, for my whole system overall. Now I idle around 240MB of usage with full X and effects going. Before it was like 320.
2. Everything starts up faster and with less disk usage than -O2.
3. Firefox starts up slightly faster than before.. it’s only a subjective test because I didn’t actually time it, but firefox starts in about 3 seconds now from cold boot. I know that the binary’s are not really that much smaller, but when the many parts of the system are recompiled with -Os it helps.
4. I still haven’t figured out how to completely eliminate disk usage by firefox. I suspect I may have to copy my entire profile into memory because firefox still spins the disk up from time to time.
5. Personally I like the newer gtk because it blends so well with my gnome environment. I also saw that firefox has support for qt too.
I think this thread is pretty good. Maybe i’ll start a wiki on optimizing firefox/thunderbird and see what people contribute.
Podemos ver que la opción -Os parece dar mejor rendimiento que la opción -O2. Otro caso en el que vemos que -Os da mejor resultado es este:
/*
* Ed. note
* “Reboant” dropped a note about how using -Os (optimize for size) showed
* incredibly good results. So if you want is small binary size rather than fast
* execution time, you might want to take a look at this.
*/
Pero ojo, eso no significa que le funcione a todo el mundo, no es tan sencillo. De hecho, hay un proyecto llamado ACOVEA que se basa en algoritmos genéticos para intentar obtener las mejores opciones de compilación para una aplicación.
Como podemos ver, esto de mejorar el rendimiento no es algo trivial, pero teniendo ganas se puede colaborar en los proyectos que son de código abierto. Basta tener ganas de aprender y colaborar .
No hay comentarios:
Publicar un comentario