Programación multihilo/multiproceso
A ver, mucho programador por aquí, escribiendo programas durante muchos años...
Que levante la mano quién haya escrito programas multihilo o multiproceso. Poquitos, no?
Ahora, de los que levantaron la mano, que se ponga en pié aquél que haya escrito algún programa que use más de tres hilos. Ninguno, incluido yo? ya me parecía.
Pués bién, eso se va a tener que acabar. AMD ha presentado su nuevo procesador "Barcelona", que es un opterón con cuatro núcleos y que estará disponible en verano. Y eso sólo es el principio. Intel espera tener procesadores con 80 núcleos en cinco años. Osea, duplicarán el número de núcleos cada año y medio o así. A lo que parece, ya no es posible aumentar el rendimieno aumentando la velocidad de reloj ( cuánto tiempo llevamos en los 2GHz? ) así que la forma de aprovechar los transistores extra que nos permite la ley de Moore va a ser poner más núcleos en el mismo procesador. Y va a haber que programarlos.
En servidores es fácil, ya que casi siempre los servidores sirven a más de un cliente, normalmente montones, y la estrategia es asignar un hilo por cliente. Sin embargo, estos nuevos procesadores van a acabar en todos los ordenadores. Los de sobremesa también.
De momento, los núcleos extra van a venir bién por que en el ordenador típico de uno de nosotros ya hay, yo calculo, unas tres o cuatro cosas pasando al mismo tiempo:
- El núcleo del sistema operativo haciendo sus cosillas.
- Servicios varios (indexadores tipo google desktop search, el burrito, ftp, samba, etc...)
- Si el programa que estais usando está medio bién programado, tendrá un hilo para el gui y otro para hacer las cosas que lleven tiempo.
Eso sin contar con programas de virtualización tipo VMWare, que duplicarían el número de procesos (aunque si no me equivoco, VMWare sólo es capaz de utilizar un núcleo por máquina virtual.)
Total, que de momento, un procesador de cuatro núcleos se va a aprovechar sin problemas. Pero al año siguiente tendremos 8, y después 16, y luego 32.
Como vamos a mantener ocupados a todos esos procesadores? Java se vendió como un lenguaje en el que la programación multihilo es fácil, y es cierto... comparado con C y C++. Sin embargo, el paradigma de sincronización de Java, aunque la sintaxis es mucho más cómoda y no hay punteros ( los punteros hacen mucho más difícil la sincronización), es el mismo que el de C++ (memoria compartida y cerrojos), y se rompe fácilmente cuándo el número de tareas en que quieres separar la aplicación es elevado.
Bueno, pués para un número de núcleos mayor de 8, no hay lenguajes de programación que sean una alternativa clara, y las ideas a aplicar van a tener que tomarse de de la programación de superordenadores, que normalmente son de diseño masívamente paralelo.
La cuestión es que la cosa se nos hecha encima y no hay una respuesta clara.
Yo, a cuenta de un artículo en Slashdot, me he pasado todo el Domingo leyendo sobre esto y el tema es superinteresante. Por ejemplo, tenemos este papel en el que se explica cómo los presupuestos a la hora de pensar en este tipo de cosas han cambiado. Luego intentan hacer clases de algorithmos paralelizables y se analiza sus necesidades de comunicación entre núcleos, ancho de banda y latencia.
Luego podeis mirar cosas en wikipedia, como por ejemplo "el problema de la cena de los filósofos" (no se si se traduce así), el lenguaje de programación erlang, el lenguaje E, etc...
Un tema muy interesante.
Que levante la mano quién haya escrito programas multihilo o multiproceso. Poquitos, no?
Ahora, de los que levantaron la mano, que se ponga en pié aquél que haya escrito algún programa que use más de tres hilos. Ninguno, incluido yo? ya me parecía.
Pués bién, eso se va a tener que acabar. AMD ha presentado su nuevo procesador "Barcelona", que es un opterón con cuatro núcleos y que estará disponible en verano. Y eso sólo es el principio. Intel espera tener procesadores con 80 núcleos en cinco años. Osea, duplicarán el número de núcleos cada año y medio o así. A lo que parece, ya no es posible aumentar el rendimieno aumentando la velocidad de reloj ( cuánto tiempo llevamos en los 2GHz? ) así que la forma de aprovechar los transistores extra que nos permite la ley de Moore va a ser poner más núcleos en el mismo procesador. Y va a haber que programarlos.
En servidores es fácil, ya que casi siempre los servidores sirven a más de un cliente, normalmente montones, y la estrategia es asignar un hilo por cliente. Sin embargo, estos nuevos procesadores van a acabar en todos los ordenadores. Los de sobremesa también.
De momento, los núcleos extra van a venir bién por que en el ordenador típico de uno de nosotros ya hay, yo calculo, unas tres o cuatro cosas pasando al mismo tiempo:
- El núcleo del sistema operativo haciendo sus cosillas.
- Servicios varios (indexadores tipo google desktop search, el burrito, ftp, samba, etc...)
- Si el programa que estais usando está medio bién programado, tendrá un hilo para el gui y otro para hacer las cosas que lleven tiempo.
Eso sin contar con programas de virtualización tipo VMWare, que duplicarían el número de procesos (aunque si no me equivoco, VMWare sólo es capaz de utilizar un núcleo por máquina virtual.)
Total, que de momento, un procesador de cuatro núcleos se va a aprovechar sin problemas. Pero al año siguiente tendremos 8, y después 16, y luego 32.
Como vamos a mantener ocupados a todos esos procesadores? Java se vendió como un lenguaje en el que la programación multihilo es fácil, y es cierto... comparado con C y C++. Sin embargo, el paradigma de sincronización de Java, aunque la sintaxis es mucho más cómoda y no hay punteros ( los punteros hacen mucho más difícil la sincronización), es el mismo que el de C++ (memoria compartida y cerrojos), y se rompe fácilmente cuándo el número de tareas en que quieres separar la aplicación es elevado.
Bueno, pués para un número de núcleos mayor de 8, no hay lenguajes de programación que sean una alternativa clara, y las ideas a aplicar van a tener que tomarse de de la programación de superordenadores, que normalmente son de diseño masívamente paralelo.
La cuestión es que la cosa se nos hecha encima y no hay una respuesta clara.
Yo, a cuenta de un artículo en Slashdot, me he pasado todo el Domingo leyendo sobre esto y el tema es superinteresante. Por ejemplo, tenemos este papel en el que se explica cómo los presupuestos a la hora de pensar en este tipo de cosas han cambiado. Luego intentan hacer clases de algorithmos paralelizables y se analiza sus necesidades de comunicación entre núcleos, ancho de banda y latencia.
Luego podeis mirar cosas en wikipedia, como por ejemplo "el problema de la cena de los filósofos" (no se si se traduce así), el lenguaje de programación erlang, el lenguaje E, etc...
Un tema muy interesante.
Comentarios
Esto provoca que para hilar deberiamos tirar muchas cosas a la basura, empezando por los propios sistemas operativos, y cambiar aspectos de la lógica secuencial que tan a fuego estan en las mentes de muchos programadores.
Tal y como lo veo yo, el multiprocesamiento tiende a una distribución más que a tratamiento hilado cuando el objetivo es multiple.
De hecho, las maquinas de muchos nucleos existen desde que empezo a realizarse la programacion para granjas, y ahora mismo, nosotros trabajamos con bastidores de 25 maquinas en granja con acceso a almacenamiento compartido comportandose como una única, y que basculan según servicio, por fail-over o según requerimientos.
Y eso es lo que va a suceder a nivel consumidor, cada procesador a una tarea, y punto, cuanto más procesadores, mayor facilidad de distribución de servicios o programas y más tendente a su velocidad terminal (un procesador para cada tarea).
... mucho ha de cambiar en el hombre, y no la máquina, para que esto no sea así.