Youtube day

Hoy toca video, con canción dedicada a todas las Magdalenas.

¿Qué tendrá Linux 2.6.22?

Como parte del mantenimiento de kernelnewbies.org/LinuxChanges, aquí va un resumen de avance en españolcastellano:

• El SLUB allocator, que reemplazará al "slab allocator", y no lo traduzco por lo pedante que suena. El "slab allocator" es un mecanismo de gestión de memoria a muy bajo nivel y muy crítico para el rendimiento. El mecanismo actual no es que sea malo, de hecho es bastante bueno, pero los de SGI, que trabajan con equipos de 1024 ó 4096 CPUs, encontraban su diseño ineficiente para esos casos (se gastaban GB solo para las "colas de objetos", sin contar los objetos), y la adición de nociones NUMA a lo largo de su vida no había sido todo lo limpia que debería. En vez de intentar parchearlo poco a poco ha preferido reescribir un sistema nuevo de cero con un diseño más simple y que incluso mejora algo el rendimiento. En 2.6.22 este "SLUB" está disponible de forma opcional


• Nueva pila wifi: El soporte de drivers wireless en linux ha sido francamente un caos debido a la ausencia de una pila wifi que soportara todo tipo de características, lo que ha hecho que hayan surgido más de una pila wifi, drivers implementando caracteristicas ausentes en la pila....en 2.6.22 se incluye una pila wifi liberada por Devicescape, con completo soporte para 802.11g, capa MAC por software, wpa, wpe, módulo de "bridging" a nivel de enlace, capacidades QoS para VOIP y video...además tiene una nueva interfaz de configuración, basada en netlink, y compatibilidad con las antiguas extensiones wireless basadas en ioctls. La pega es que los drivers del kernel no han sido portados aun a esta pila y aunque hay parches en algunos casos, aun no han sido incluidos. Hay algunos drivers que han sido desarrollados de cero sobre esta pila que tambien se incluiran en el futuro.


• Nueva pila firewire. Más pequeña (8k LoC frente a los actuales 30k), mejor diseñada, compatible con la antigua a nivel de libreria. La antigua permanece ahí para quien la quiera usar. Como puede verse, Linux no ha perdido su afan por reescribir partes del código para conseguir un mejor kernel.


• Nueva arquitectura: Blackfin


• UBI, un LVM para dispositivos de almacenamiento basados en memoria flash. ¿Por qué se necesita un nuevo subsistema y no se extiende LVM? Porque los dispositivos flash son fundamentalmente diferentes.


• Gestión de eventos de señales y temporizadores a través de descriptores de archivos. Linux carece de parte de la funcionalidad equivalente a kevent/kqueue (FreeBSD, OSX y otros equivalentes en Solaris y NT). Linux implementó epoll(), una "epoll() escalable" (el poll() tradicional de Unix está seriamente limitado en cuanto a su rendimiento por cuestiones de diseño), pero epoll no cubre las señales ni los temporizadores, porque no son descriptores de archivo. Frente a la solución considerada sobrediseñada de kevent/kqueue y despues de rechazar una implementación de Linux que implementaba algo similar, se ha optado por una idea de Linus de hace 4 años más "unixy": las llamadas de sistema signalfd()/timerfd(), que asocian a un descriptor de archivo a una señal o eventos de temporizador. A esos descriptores se les puede aplicar read(), poll(), epoll(), etc; de manera que se pueden gestionar señales y temporizadores como "archivos".


• Sockets RxRPC seguros. Este es un tipo de protocolo que se utiliza con el "Andrew File System" (AFS), pero francamente no tengo ni pajolera idea de lo que hace.


• utimensat(), una extensión a futimensat(). No se que hará, pero seguro quer sirve para algo. Dicen que soporta resolución de nanosegundos, y algo que tiene la palabra "nano" no puede ser del todo malo.


• Varios algoritmos de control de congestión nuevos, varios drivers nuevos, IPV6 para CIFS, soporte de escritura en AFS, etc etc....más de lo mismo bajo el cielo azul. Con lo de arriba ya hay suficiente.

Compilador más "multicore"

Intel acaba de publicar una nueva versión de su compilador, y esta versión trae herramientas que ayudan a programar para multicore, lo que Intel llama Intel Threading Building Blocks

Dos de las herramientas son un detector de bloqueos y pausas en programas multihilo, y un analizador de rendimiento en programas multicore. La primera me intriga: Es una forma de decir que la programación multihilo es muy compleja y que el cerebro de los programadores va a tener que aguantar toda esa complejidad. Es decir, que Intel sigue sin tener una solución para que el software escale mágicamente, lo cual no es sorprendente ni vergonzoso para ellos. A mi, francamente, un detector de bloqueos que tenga que utilizarse a diario me parece tan absurdo como, por ejemplo, un detector de pausas en el pipeline del procesador: Sin duda es útil para microoptimización y casos concretos, pero no es de lo que la mayoría de los programadores debería preocuparse a diario. Y pongo ese ejemplo porque el mundo multicore tiene sus similitudes con los procesadores cuyo rendimiento sufre demasiado con las pausas, como los P4. ¿Se imaginan un procesador como el P4 pero a lo bestia, que necesitara un extremo cuidado para no hacer pausas en el pipeline? ¿Se imaginan tener que echar un ojo al ensamblador para ver qué ha generado el compilador? Pues bien, usar ese procesador sería una gloria comparado con el multicore, porque al fin y al cabo es el compilador el que genera el código optimizado para no crear pausas en el pipeline; mientras que un compilador no te va a solucionar el problema de tener que usar varios cores simultaneamente, tienes que hacertelo tú. Y miren dónde se ha quedado el P4. O el Itanium.

En cierto modo es volver al mundo del ensamblador. Bueno, la analogía correcta sería decir que volvemos a la complejidad de los días de los programas en ensamblador, cuando el programador pasaba más tiempo intentando encontrar los fallos (eso no ha cambiado mucho hoy, pero antes era peor, hoy en día los fallos se buscan en programas con decenas miles de líneas, antes los fallos te abrumaban con unos cientos) o buscando un rendimiento decente que programando funcionalidad. Volvemos a ese mundo, porque la programación en paralelo no es asequible a la mente humana, por muchos adornos que le pongan, igual que no lo es la programación de una suite ofimática en ensamblador, y la única manera de afrontar esa complejidad es que alguien, ya sea el compilador, las capas más bajas del sistema operativo, la orientación a objetos, una mezcla de todo, sea quien sea, resuelva al programador el problema.