Por qué los procesos escalan mejor que los threads

Este es el provocador título de una entrada en el weblog Assaf Arkin. En él se defiende la solución que la comunidad LAMP ha tomado para aplicaciones multitarea (procesos) frente a la de Java (threads). Según el autor, al programar en Java se emplean objetos, librerías, frameworks... APIs, en definitiva. Esto hace que los programadores no se preocupen por nada que "quede fuera de la máquina virtual" porque las abstracciones en las cuales se basan (APIs) son de muy bajo nivel.



Los programadores de LAMP sin embargo suelen construir sus aplicaciones encadenando un montón de pequeños programas. En este caso, el nivel de abstracción no es un API sino una tarea. Para el autor, el nivel de abstracción correcto deben de ser las tareas, ya que centrarse en API, de menor nivel de abstracción, hace que se pierda la visión de conjunto lo cual (aunque no explica de un modo muy claro el porqué) permite escalar mejor a los programadores LAMP.



Respecto al rendimiento de las aplicaciones, ¡también parece ser que los procesos tienen más rendimiento que los threads!. No dentro de una máquina, donde los threads efectivamente ganan a los procesos, pero si en un cluster. Y el motivo parece ser que es que al pensar en tareas (procesos) es más fácil construir soluciones que escalen mejor que al pensar en APIs.



No estoy de acuerdo con los los conclusiones del autor, porque no creo que al programar contra APIs se tenga que perder la visión del conjunto y porque el autor parece no conocer, o ha dejado fuera, la gran cantidad de optimizaciones que hacen los servidores de aplicaciones Java que nunca conseguirá obtener encadenando procesos. Alguna de las ideas que hay detrás de los servidores de aplicaciones se ha tratado de llevar al mundo de los procesos en fastCGI , pero no llegan a ser tan eficaces.



No obstante, el artículo aporta ideas interesantes y merece la pena leerlo.

Por primera vez se propone eliminar APIs del JDK

Se trata de una posibilidad que, si bien estaba contemplada, jamás se había empleado. Eliminar APIs que han formado parte de las librerías estándar de una versión del JDK en futuras versiones. El JSR 270 es en el que se está decidiendo si se eliminan o no estas APIs. En la que parece haber un mayor consenso es en la eliminación del paquete javax.sound.midi, aunque también se están discutiendo otros candidatos como CORBA.



El motivo por el cual se propone la eliminación es reducir el tamaño del JRE mediante la eliminación de APIs usadas por una parte muy pequeña de la comunidad y que, por tanto, quizás tenga más sentido que sean empaquetadas con cada aplicación particular y no que formen parte de la distribución estándar. Por ejemplo, una implementación de javax.sound.midi añade aproximadamente 500 kB al JRE.



Que estas APIs dejen de ser estándar no quiere decir que vayan a dejar de estar disponibles. Por otro lado, dado el funcionamiento del Java Community Process, como pronto estas APIs se podrían retirar en Java 7, ya que el proceso de retirada tiene dos fases: primero el comité de expertos de una determinada revisión de la plataforma (Java 6 en nuestro caso) propone que ciertas APIs sean retiradas, y a continuación el comité de expertos para la siguiente revisión (Java 7 en nuestro caso) decide si las retira o no.



¿Alguien usa o ha usado alguna de estas API?

Phillips muestra por primera vez sus dispositivos Blu-ray

Phillips ha mostrado por primera vez en la feria IFA su gama de dispositivos Blu-ray. Los DVDs Blu-ray son uno de los dos formatos que competirá en el futuro por hacerse con el mercado de DVD. En IFA Phillips presentó DVDs grabables y regrabables, lectores y grabadoras para ordenadores, y reproductores para televisiones.



Por si algún despistado no lo sabe, la relación de estos DVD con Java es que los dispositivos Blu-ray son programables en Java. A lo mejor alguno de esos usuarios de javaHispano despistados que aún no estaban al tanto de esto antes de lo que él cree tiene que ponerse a picar código para ellos.

La mitad de los managers de TI odian a sus usuarios

De entrada, no se como traducir "managers", en México sería "gerentes" pero no estoy seguro en el resto de hispanoamérica..


En fin, pues lo dicho de acuerdo a este estudio realizado en el Reino Unido, la mitad de los managers aseguran odiar a sus usuarios y dificultar su trabajo de forma deliberada. Otros datos interesantes arrojados por dicho estudio es que a el 75% de los managers les gustaría estar en otro trabajo y 50% dice que ya se ha inscrito en un servicio de Head-Hunters (servicios de colocación de empleos).


Pues al parecer el trabajo en Tecnologías de la Información no es muy satisfactorio en el Reino Unido, ¿cuál es la situación en el mundo hispano?

Titanium: Java para Supercomputadoras

Titanium es un proyecto desarrollado en la universidad de Berkeley para implementar el lenguaje Java y está enfocado al cómputo científico con alto desempeño en supercomputadoras y clusters distribuidos.



Esta implementación se basa en la especificiación 1.4 (lo siento nada de Generics o Enums para supercomputadoras) e incluye diversas mejoras como la posibilidad de sobrecargar operadores y soporte más eficiente para arreglos multidimensionales.



El lenguaje es usado para diversos proyectos científicos universitarios y ha sido probado en varias arquitecturas de supercomputadoras como IBM SP, Cray X1, Blue Gene, Cray XT3 y Origin 2000.



Pueden bajar el código fuente desde esta página, compila con cualquier compilador ANSI-C

Java a la máxima potencia :-)