Un vistazo a Threading Building Blocks

Según se puede leer en Ars technica: Intel open sources multicore programming tool Intel libera Threading Building Blocks, una herramienta hasta ahora propietaria que ayuda a la programación concurrente. La noticia ha salido en muchos sitios con comentarios interesantes (Slashdot, OSNews o en barrapunto)

Había oído hablar de esta herramienta en la entrevista a Sanjiv Shah de OpenMP en thinking parallel, pero como él trabaja en Intel siempre parece más sospechoso tratándose de un producto comercial. Ahora que lo han liberado he estado echándole un vistazo y bueno, creo que tiene su ámbito de aplicación y que puede ser muy interesante para facilitar algunas tareas sin reinventar alguna rueda.

Por analizar un poco la librería, consta como de cuatro partes:

• Algortimos para bucles paralelos: parallel_for, parallel_reduce, parallel_while. Me ha parecido de lo más interesante de la librería porque es muy fácil de implementar y te ahorra mucha gestión. Al algoritmo se le pasa un contenedor sobre el que operar y un functor y el lo procesa en paralelo automágicamente, aunque parece ser algo parametrizable.
• Contenedores seguros a accesos concurrentes: concurrent_hash_map, concurrent_vector, concurrent_queue. Usan internamente los bloqueos de grano fino y estructuras de datos sin bloqueos. Que bien que no haya que hacerlo por uno mismo, tiene pinta de ser complicadillo y muy fácil hacerlo mal
• Utilidades para gestión de la concurrencia: mutexes de diverso tipo (si, recursivos también), locks, operaciones atómicas
• Un gestor de tareas: una ayuda para programar orientado a tareas, threads más ligeros que los del sistema.

Desde que lo han hecho opensource le han asignado un domino propio, http://www.threadingbuildingblocks.org/ en el que hay bastante información. En particular el tutorial al que le he echado un vistazo es Intel® Threading Building Blocks: Tutorial

Por dar alguna nota no positiva... bueno, de momento solo soporta plataformas desde Intel Pentium 4, porteriores y compatibles, aunque en una de las FAQ del proyecto dicen que soportar todos los procesadores, sistemas operativos y compiladores es una las piedras angulares del proyecto. Veremos.

También me ha llamado la atención que dijesen (extraído del artículo de ars technica):

Java and .NET versions of TBB are currently being evaluated by Intel, and may eventually be announced. But Intel maintains that C++ is the company's priority, and it's where they'll be focusing the engineering resources that they're adding to the project.

Puede ayudar a hacer un poco más multiplataforma el código paralelizado en C++, aunque ya existen muchas librerías que lo hacen, como Boost.Thread. Supongo que estará bien usarlo cuando se necesita mucho rendimiento, una aproximación más sencilla no vale y paralelizarlo de este modo sale rápido y óptimo.

Un vistazo a Threading Building Blocks en barrapunto

¿Testeo o corrección?

Andaba yo descubriendo otro blog, el de Andrew Koenig, cuando, a raíz de dos post suyos seguidos (uno de aserciones contra excepciones y otro sobre la depuración) he reparado en el tema... últimamente se hace mucho hincapié en el desarrollo guiado por pruebas, pero según se puede ver en el segundo post, hay veces que las pruebas, e incluso el uso, no son garantía de corrección.

Por eso es tan importante que las pruebas sean realistas. Por eso es tan importante extraer información del sistema en todas la etapas del ciclo de vida. Por eso es tan importante un buen sistema de registro del sistema. Pero sobre todo, por eso es importante pensar bien antes de codificar.

También me ha recordado uno esos principios de desarrollo polémicos: Los fallos, cuanto antes mejor (Fail Fast). Es uno de los principios en el diseño de Erlang. Como dice Joe Armstrong en una entrevista reciente:

La filosofía de Erlang fue siempre construir sistemas con un montón de procesadores baratos y permitir que fallen. No prevenimos el fallo; vivimos con él y recuperamos el sistema cuando ocurren.

Hay que recordar que se trata de fallos irrecuperables, no de casos raros dentro de la lógica del programa. Es mejor dejar claro un error fatal que tratar de continuar cuando no se puede y que se pierda el rastro de lo sucedido...

Por supuesto el título es falaz, debería haber sido Testeo y corrección y todos contentos, pero espero que se me permita el recurso :)

¿Testeo o corrección? en barrapunto

Leyes sobre el desarrollo de software con nombre propio

Leo en haacked un listado de leyes que tienen algo que ver con el desarrollo de software y que además tienen nombre propio. Las hay serias y las hay humorísticas o simplemente pesimistas. Entre divertido, iluminador y deprimente.

De las que más me gustan:

• La ley de Postel: Sé conservador con lo que envías, liberal con lo que recibes. Ya hablé de ella por aquí en ¿Postel o Dracón?
• La ley de Parkinson: El trabajo se expande hasta consumir(*) todo el tiempo previsto para él. (*)Al menos, añadiría yo ;)
• El principio de Kerchkhoff: En criptografía un sistema debería ser seguro incluso si todo acerca del sistema es de conocimiento público excepto una pequeña cantidad de información: la clave.

Habla también de las típicas leyes de estos casos, Murphy, Pareto, Sturgeon, Brooks...

Actualización: Joey deVilla inspirado en el post anterior ha hecho una recopilación francamente impresionante de leyes o dichos referidos al desarrollo del software.

Leyes sobre el desarrollo de software con nombre propio en barrapunto

Beautiful Code

El bloguerío de esto de la programación anda revuelto por la publicación de un libro que parece muy interesante Beautiful Code: Leading Programmers Explain How They Think. Y es extraño que ande tan revolucionado sin una causa económica (al parecer lo que se saque con este libro irá a AI) pero viendo los autores quizás sea para tanto; que me suenen: Brian Kernighan, Tim Bray, Charles Petzold, Diomidis Spinellis, Douglas C. Schmidt, Yukihiro Matsumoto... aunque seguro que me dejo a alguien importante :) Cinco de ellos han sido ya nombrados por aquí, que cosas...

El libro consta de 33 capítulos en los que otros tantos autores piensan en alto sobre la arquitectura de sus proyectos (o de los proyectos de otro) los compromisos que se tomaron en su construcción y cuando fue importante romper las reglas. Dado lo heterogéneo del grupo de autores seguro que hay de todo un poco, pero el tema me parece tan interesante que inmediatamente lo he puesto en mi lista de deseos de anobii, aunque creo que dentro de poco se caerá de la lista :)

Por hacerme eco de algunos de los los comentarios que ha generado, Bryan Cantrill reflexiona sobre la recursividad en el mundo real y recibe interesantes respuestas. Alberto Savoia, uno de los autores, en "Pardon My French, But This Code Is C.R.A.P." reflexiona sobre el código malo, que es mucho más abundante, parafraseando a Strurgeon ("90% of everything is crap." - Sturgeon’s Law (one of many variants) "When applied to software, Sturgeon’s Law is hopelessly optimistic." - Savoia’s Corollary to Sturgeon’s Law) y a Sartre ("Hell is other people." - J. P. Sartre "Hell is other people’s code." - T-Shirt seen recently in Mountain View, CA) :)

Beautiful Code en barrapunto

Varios sobre concurrencia y patrones de diseño

Ración de enlaces:

• The Pillars of Concurrency por Herb Sutter Un resumen de los distintos escenarios en lo que se debe aplicar la concurrencia y de las posibles soluciones presentes y futuras. Comentado en LtU, The Pillars of Concurrency
• Un par de vídeos (que aún no he visto, pero que tienen muy buena pinta): C++ Threads por Lawrence Crowl y Concurrency/message passing Newsqueak por Rob Pike (En la tendencia de que los materiales se cuelguen más "en bruto", vídeos y entrevistas en audio y video en lugar de transcritos... más fácil de hacer pero peor para buscar algo concreto y al ser en lenguaje oral es posible que peor para los no nativos. Aunque estos parece que con las diapositivas se pueden seguir bien...)
• Un par de enlaces para reflexionar acerca de los patrones de diseño: Rethinking Design Patterns de Jeff Atwood, que viene a recordar los argumentos que se citaron por aquí en Enlaces varios (IV), que los patrones de diseño son síntomas de defectos en los lenguajes de programación. También Patterns I Hate #2: Template Method, que parece ser una serie en la que se medita sobre lo que se gana y se pierde con algunos patones.

Varios sobre concurrencia y patrones de diseño en barrapunto

Artículos de Alexandrescu sobre C++

Leo a través de la sección de programación de reddit que Andrei Alexandrescu ha puesto en su página, disponibles para descarga y consulta los artículos que ha publicado en C/C++ User's Journal. Para quienes no lo conozcan, Andrei Alexandrescu es el autor de Modern C++ Design uno de los libros más influyentes y que más bien (¿y mal?) ha hecho por el C++ y sus lectores/escritores.

Me han llamado la atención especialmente Lock-Free Data Structures, Lock-Free Data Structures with Hazard Pointers y C++ and The Perils of Double-Checked Locking aunque solo sea por la introducción a la programación con bloqueos y sin bloqueos que me ha parecido hasta didáctica. También hay otros artículos sobre punteros inteligentes, constructores de movimiento y otras técnicas y temas diversos. Más para leer...

Artículos de Alexandrescu sobre C++ en barrapunto

El mejor código es el que no existe

Bueno, la frase es demoledora y como toda frase lapidaria, conviene matizarla. Pero contiene tanta sabiduría (pesimista o realista, tu eliges) que creo que debe convertirse en uno de los mantras a repetirse frecuentemente.

Me lo recordó hace unos días la entrada de Jeff Atwood, The Best Code is No Code At All, muy recomendable. Si, antes de codificar, de desplegar miles de millones de líneas de código hay que pensárselo muy bien. Codificar es divertido, es muy estimulante... Pero antes de empezar, antes de abrir siquiera el editor debería pasar por la cabeza, en alguna milésima de segundo, al menos alguna de estas preguntas:

• ¿Debo escribir este código?
• ¿Estaré reinventado alguna rueda?
• ¿Soluciona el problema que quiero solucionar?
• ¿Se puede hacer mejor, más compacto, más legible, solo pensando un poquito antes de teclear?

Ya decía que conviene matizar: el programa vacío no hace nada y parece que es bueno que los programas hagan algo :) Se trata de un un recordatorio ¡Cuidado con el exceso de código! Creo que no hay aberración mayor que valorar la producción por líneas de código; es como si pagaran por bugs cometidos...

Jeff cita otro artículo en el que se exhorta a comenzar con código minimalista y completarlo a través de test. Es una buena idea, pero en estos tiempos de exaltación del Test-driven development conviene recordar también que los test no lo son todo, que pararse a pensar sigue siendo imprescindible.

En resumen serás esclavo de tu código, así que piénsatelo bien ;)

El mejor código es el que no existe, en barrapunto

AMQP ¿El nuevo Middleware universal?

Según leo en Toward a Commodity Enterprise Middleware John O'Hara en JPMorgan, harto de "el problema del Middleware" se construyó (diseñó e implementó) el suyo propio para sus sistemas: AMQP (Advanced Message Queuing Protocol)

Se basa en el paso de mensajes y su gestión, permite mensajes del tipo publicación/suscripción, guardar y reenviar o envío de ficheros, separa la capa de trasporte de la de gestión de colas, tiene un protocolo binario que lo hace menos pesado en cómputo y ancho de banda que los Servicios Web y está preparado para pasar los firewalls sin perdida de seguridad. Suena bien.

Para no cometer uno de los errores de CORBA, existe ya más de una implementación, la de referencia: OpenAMQ, otra de Apache incubator, Apache Qpid, y una última en Erlang, RabbitMQ todas ellas software libre.

Al parecer la industria está entendiendo (por fin) que el modo de hacer tecnologías interoperables es haciendo implementaciones de referencia funcionales y libres, teniendo comunidad de usuarios (y no clientes) De todos modos habrá que ver si tiene una adopción tan masiva como pretenden. Lo debería ser si efectivamente el middleware se logra convertir (ojalá) en una Comoddity

(En El auge y la caída de CORBA (y lo que podemos aprender) se comentaba que existía ICE otro prometedor middleware libre, en este caso más parecido a CORBA, según parece)

AMQP ¿El nuevo Middleware universal? en barrapunto

Repasando Python 3000 (o Python 3.0)

En su bitácora de Artima Guido van Rossum ha actualizado las previsiones que tiene acerca del proyecto llamado Python 3000 (que acabará siendo python 3.0)

Repasa las novedades de las versiones 2.6, que será versión puente y la 3.0. De esta última destacan el tratamiento de Unicode y entradas y salidas, el sistema de clases y tipos (con "anotaciones" que se podrán usar como tipado estático opcional), cambios en excepciones y enteros y algunos otros cambios como la eliminación de reduce() (que fue explicada en The fate of reduce() in Python 3000)

Al parecer romperá uno de los tabúes más sagrados de la informática: la compatibilidad hacia atrás, aunque habrá herramientas de conversión entre la versión 2.6 y la 3.0.

Lo comentan entre otros sitios en Lambda the Ultimate: Python 3000 Status Update, en donde, por supuesto, van a echar a faltar reduce()

Repasando Python 3000 (o Python 3.0) en barrapunto

Errores en el diseño e interpretación de experimentos

Nota: Esto en planeta código es un poco offtopic, pero me parece lo suficientemente interesante para publicarlo en YAPW. Disculpen las molestias :)

Acabo de leer en la página de Peter Norvig una interesantísima recopilación de errores comunes en el diseño e interpretación de experimentos. Estamos demasiado acostumbrados a que se les den publicidad a determinados "estudios" que cometen algunos de los errores que Norvig repasa. Por ejemplo, hacer estudios sin una Prueba controlada aleatoria, confundir correlación con causa o mal entendimiento de la probabilidad condicionada(*) Una lectura recomendable y como decía el otro día, también de cultura general, porque afecta a la base de la metodología científica.

(*)Aunque ya comentaba Tío Petros que el ser humano parece peor equipado de lo que debería para entender intuitivamente la probabilidad, así que tenemos que hacer un esfuerzo adicional...

Errores en el diseño e interpretación de experimentos en barrapunto