El sistema de plugins cada vez más cerca de GCC

Hace bastante tiempo que se viene discutiendo el porqué de la falta de sistema de plugins en el compilador libre por excelencia, GCC. Al parecer el principal problema era legal, es decir, el miedo fomentar la proliferación de plugins propietarios. Pues bien, ya se ha establecido el marco de licencias que pueden regir ese sistema, que es la nueva versión de la GCC Runtime Library Exception y con ello su desarrollo está cada vez más cerca. Además esta nueva versión de la licencia permitirá la actualización a la licencia GPLv3 de algunas librerías del propio GCC. La FSF ha proporcionado un documento con las razones para esta licencia y las preguntas más frecuentes sobre ella. Más comentarios en Slashdot: Plug-In Architecture On the Way For GCC.

Actualización: Drizzt se ha puesto de acuerdo, otra vez casualmente, para hablar del mismo tema, con algunos comentarios sobre el cambio de la licencia: El valle del Viento Helado: La arquitectura de plugins del GCC y las licencias.

La misma entrada y más comentarios en El sistema de plugins cada vez más cerca de GCC en barrapunto

Trucos gcc-céntricos y porqué no usarlos

En el estupendo blog Coding Relic el autor, Denton Gentry, ha publicado recientemente dos trucos muy espectaculares pero gcccéntricos. Bueno en realidad uno es específico de la glibc y el otro sí es una extensión de gcc:

• printf-acular en el que se describe cómo personalizar printf para que admita más tipos de datos que los que normalmente admite, en el ejemplo sacar direcciones MAC formateadas.
• Variable Scoping with gcc, en el que se explica el (espectacular) funcionamiento de __attribute__(cleanup), que permite funcionalidades del tipo RAII de C++

Y ahora, después de ver un par de extensiones tan útiles, potentes y elegantes es cuando me toca desrecomendarlas :) Creo firmemente en el valor de los estándares y en desarrollar siempre en el nivel más estricto de estándar o visto de otro modo en el nivel más amplio de disponibilidad, siempre y cuando las soluciones sean comparables. Además, es bueno pensar en la gente que retocará el código y cabe la posibilidad de que si no se documenta resulte de sólo escritura. Yo sólo lo vería admisible en un hack puntual documentado como mínimo con neones. No obstante, hay gente que no opina lo mismo como se puede leer en Uso de extensiones del GCC en (el kernel) Linux.


La misma entrada y más comentarios en Trucos gcc-céntricos y porqué no usarlos en barrapunto

La ley de Postel y los programadores

El otro día leí un comentario acerca de las diferencias en la admisión de parámetros entre los comandos en BSD y GNU. Según se comentaba, los segundos son menos estrictos y se tragan más cosas. El comentarista añadía sobre el comportamiento de la GNU userland: "me gusta a pesar del programador que hay en mi".

Y, por lo que sea, me ha parecido muy revelador: a los programadores no nos gusta, desde un punto de vista egoísta, lo que nos supone la ley de Postel, el principio de robustez. Aquello de ser liberal con lo que se admite como válido da repelús. Y creo que hay más de un motivo:

• Nos gusta la precisión. Si somos estrictos en lo que generamos ¿No vamos a exigir lo mismo?
• Se suele generar más código para tener el cuenta el ser liberal: más trabajo y más testeo
• El comportamiento de nuestro soft no es tan rígido lo que choca con nuestro gusto por las especificaciones precisas, sencillas y breves.

Lo que a veces no vemos es que ser menos estricto mejora la robustez y eso al usuario final, como es normal, le encanta aunque le de igual si se es estricto, si Postel o Dracón, los estándares y todo lo demás.

Este efecto se nota más en ecosistemas heterogéneos con lo que la integración de ese software puede ser más fácil en entornos menos controlados. Así que otra cosa más a pensar antes de desarrollar ¿Nos compensará a la larga el esfuerzo de ser menos estrictos?

La misma entrada y más comentarios en La ley de Postel y los programadores en barrapunto

Facebook publica su versión modificada de memcached

[Vía reddit] Facebook acaba de publicar su versión de memcached, el sistema de cachés genéricas más usado en aplicaciones web, tras hacer modificaciones para afrontar sus necesidades de rendimiento y escalabilidad. Las modificaciones principales han sido entre otras la eliminación de un buffer por conexión en favor de un pool, reducción de bloqueos innecesarios para un mejor rendimiento en máquinas multicore y el uso intensivo de UDP. El resultado final ha sido la posibilidad de gestionar 200.000 peticiones UDP por segundo con una latencia media de 173 microsegundos. Han subido los cambios a GitHub: facebook-memcached y esperan que los cambios sean incorporados al memcached oficial. Curiosamente hemos hablado recientemente por aquí de memcached en Un vistazo al interior de memcached.

Actualización: Olvidé mencionar que habían toqueteado el kernel :/ JAM hace muy bien resumen de esos apaños
Parece relevante también comentar lo que dicen en High Scalability sobre el memcached de Facebook y las conclusiones que se pueden sacar:

A summary of potential strategies:

• Profile everything. Problems are always specific. The understanding of the problem must be specific. The fix must be specific.
• Burn profiling into your regression tests. Detect when and where performance tanks as a regular part of your build.
• Use resources in proportion to what grows slowest. This requires multiplexing, but at least your resource usage is more predictable and bounded.
• Batch work. When you have the CPU do all the work you possibly can in the quantum or the whole system grinds to a halt in processing overhead.
• Do work and maintain resources per task. Otherwise locking for shared resources takes more and more time when there's less and less time to do the work that needs to be done.
• Change algorithms. Sometimes you simply need to do things differently. Tweaking will only get you so far.

La misma entrada y más comentarios en Facebook publica su versión modificada de memcached en barrapunto

El código fuente como documento definitivo del diseño

Se trata, cómo no, de Code as Design: Three Essays by Jack W. Reeves. Son unos ensayos muy ilustrativos de la naturaleza particular del desarrollo de software, que por usar la palabra diseño de un modo no usual acaban resultando muy polémicos, pero a mi me parecen más bien esclarecedores. Se recomienda leer enteros antes de opinar :P

Suelo aprovechar cualquier mención para volver a enlazarlo y esta vez ha sido Ricardo Galli en "Los problemas derivados del abuso de las analogías" quien me da la oportunidad de volver a hacerlo :)

Se ha hablado de ellos por aquí en El código fuente visto como diseño y POO, el código como diseño y más cosas.

La misma entrada y más comentarios en El código fuente como documento definitivo del diseño en barrapunto

Memoria transaccional ¿Sólo un juguete para investigadores?

En Software Transactional Memory: why is it only a research toy? de Calin Cascaval et al. se repasan algunas de las razones por las que, tras unos años de investigación, la memoria transaccional no ha dado el salto para ser usada en otros entornos. Se nombran sobre todo razones de rendimiento, de usabilidad (semántica confusa) y de interacción con sistemas que no la usan. No obstante no todo el mundo se da por vencido y por ejemplo Larry O'Brien escribe en Cascaval et al.'s skepticism on transaction memory una visión un poco más optimista indicando que aún queda espacio para la investigación y la optimización. ¿Acabaremos usando STM o morirá antes de nacer?

La misma entrada y más comentarios en Memoria transaccional ¿Sólo un juguete para investigadores? en barrapunto

Universos paralelos, cuerdas y divulgación científica

Hay un debate, apasionante y por supuesto no resuelto acerca de cómo divulgar la ciencia, de cómo equilibrar la precisión de lo que se cuenta con lo entretenido de la forma.

Pues bueno, a mi me parece que esto en la divulgación de la ciencia más básica es especialmente importante. Suele uno leer en periódicos, revistas y últimamente en blogs artículos sobre la teoría de cuerdas y sobre universos paralelos sin hacer la menor mención acerca de lo especulativo del asunto. Por eso me ha gustado mucho un apunte de Clifford Johnson en el que lo explica estupendamente (vía Not Even Wrong de Peter Woit) Habla de su participación en un programa de divulgación sobre universos paralelos. Cito y "traduzco":

Para ser sincero estoy un poco preocupado porque es un tema que puede ser aprovechado muy fácilmente por chiflados por personas sensatas por igual, y es, de diversos modos, alimento para mucha charlatanería y sinsentido místico. Cualquier programa de ciencia sobre este tipo de material tiene que ser doblemente -triplemente- cuidadoso, para no dar a la gente una excusa para decir que "los científicos han comprobado esto".

¿Por qué estoy un poco preocupado? Bueno, yo no he visto un montaje final del espectáculo y y no me quiero exceder, pero un primer montaje en bruto que he podido ver sufre de un problema que estos programas pueden tener a veces: un conjunto de científicos en activo muy cuidadosos al hacer comentarios acerca de lo que se conoce, de lo desconocido, de lo que es probable y de lo que es poco probable, y así sucesivamente, y después mucha de esa cautela puede ser socavada por la intercalación de sus observaciones con fragmentos del favorito de cualquier cineasta de la física documental, del tipo que puede ser invocado para decir cosas salvajes y maravillosas - Michio Kaku.

Por favor, no me malinterpreten. No tengo nada en contra de Kaku, me parece un muy buen tipo, y creo que ha realizado un excelente y divertido trabajo para este tipo de programas (tales como el documental sobre Einstein de la otra noche ), pero hay momentos en que sus observaciones más, ermmm, emocionadas e imprudentes pueden ser colocadas en un lugar en el programa que no ayuda en nada a ser prudente con la ciencia. A menudo (quizás siempre?) no es su culpa, un director que no se da cuenta de cómo un detalle puede ser crucial llega a un punto en el que debe elegir entre la inserción de:

* (a) un fragmento de alguno de nosotros que tratamos de ser cuidadosos y no hacer declaraciones equivocadas y/o sensacionalistas, y
* (b) un fragmento un distinguido caballero con un entusiasmo contagioso, agitando sus brazos y diciendo cosas que suenan maravillosas

...Y 99 veces de cada 100 va a elegir la opción (b) si ninguna de las personas de (a) están ahí para orientarle. Esta es, por supuesto, la razón por la que siempre espero [...] que estos espectáculos se realicen de un modo colaborativo entre científicos y cineastas[...]

Hace ya unos días, bastante relacionado con esto, rvr en un par de entradas, El nivel de la divulgación científica (I) y El nivel de la divulgación científica (II) repasaba el mismo problema a la inversa, con la tesis de que debe haber sitio también para la divulgación más superficial.

Sin estar en desacuerdo con esta tesis si debo reconocer que me gustaría que hubiese menos confusión entre ciencia aceptada y especulación. Creo que la diferencia debería ser subrayada por todo el mundo y que conceptos como Método Científico, Reproducibilidad y Falsabilidad tuviesen mayor eco. Cuestión de educación, supongo.

Y bueno, por acabar y por ser algo constructivo recomendar una entrada sobre el tema en Ecos del futuro (que he conocido hace poco, muy bueno): La interpretación de los universos múltiples, en la que sí queda claro lo que es especulativo y lo que no, y porqué.

La misma entrada y más comentarios en Universos paralelos, cuerdas y divulgación científica en barrapunto

Varios sobre concurrencia y rivales de GCC

Ración de varios variados:

• Parallel Programming with Transactional Memory de Ulrich Drepper en el que hace una buena introducción de la memoria transaccional y de su estado actual, que es más bien de investigación, de su posible futuro y de sus posibles problemas, sobre todo de rendimiento. Por cierto, que Clojure usa STM, a ver si algún día le puedo hincar algún diente... (Se ha tratado el tema de la memoria transaccional más veces por aquí)


• Otro artículo introductorio de ACM Queue: Erlang for Concurrent Programming de Jim Larson


• Cilk++ 1.0 se liberará con una licencia dual, una open source y otra comercial. Cilk++ es un sistema que promete acercar el paralelismo a las masas. Ya veremos, pero una herramienta libre más no está mal.


• Things that go Clang in the night: LLVM 2.4 released en Ars Technica. Un poquito más profundo que las notas de prensa que se apuntaban por aquí en Publicado LLVM 2.4 pero tampoco para tirar cohetes.


• Y por último pcc, the Portable C Compiler, busca, con el apoyo de BSD Fund financiación para alcanzar una versión de ppc 1.0 usable y poder tener un entorno de desarrollo BSD completo (y puro :) )

Movidillo parece el micromundo de los compiladores libres, veremos si la competición les sirve para mejorar a todos ellos.

La misma entrada y más comentarios en Varios sobre concurrencia y rivales de GCC en barrapunto

Publicado LLVM 2.4

Acaba de ser anunciada la versión 2.4 de LLVM (Low Level Virtual Machine). A LLVM y su compilador asociado clang se les ha querido ver como un competidor de GCC, en parte por su licencia BSD, por su diseño más modular, por su novedoso enfoque de las optimizaciones y por el apoyo de Apple. La versión 2.4 trae una buena cantidad de novedades entre las que destacan la mejora en la generación de código, compilación más rápida y soporte para la arquitectura PIC16. En el propio anuncio se apunta a una serie de presentaciones y vídeos para saber más. [Vía reddit]


La misma entrada y más comentarios en Publicado LLVM 2.4 en barrapunto

Un vistazo al interior de memcached

Leo en El valle del Viento Helado un artículo acerca de la arquitectura interna de memcached. memcached es un sistema de cachés genéricas muy usado en aplicaciones web. En el artículo se repasa tanto la elección de libevent como sistema de gestión de eventos sobre descriptores de fichero, el uso de funciones de entrada/salida no bloqueantes y sobre todo una gestión de memoria basada en un slab allocator. Contiene además enlaces con más información sobre el tema aunque como siempre la información última está en el código fuente.

La misma entrada y más comentarios en Un vistazo al interior de memcached en barrapunto