Yet Another Programming Weblog

Facebook publica Tornado, servidor web usado en FriendFeed

2009-09-12T00:16:00.004+02:00

Como cuentan en LWN, Facebook ha anunciado el lanzamiento de su servidor web Tornado bajo la licencia Apache. Tornado es un servidor Web no bloqueante escrito en Python, diseñado para gestionar miles de conexiones simultáneas, lo que lo hace ideal para servicios Web de "tiempo real". Tornado es la pieza central de la infraestructura de "tiempo real" de FriendFeed, que tienen previsto mantener activamente. Tornado es similar a "frameworks" Web ya existentes (Django, webapp de Google, web.py) pero se centra en la velocidad y en manejar grandes cantidades de tráfico simultáneo. El código se puede obtener de tornadoweb.org. Lo comentan también en reddit, Slashdot y Hacker News entre otros.

Hay que recordar además que Facebook publicó su versión modificada de memcached, después de haber publicado parte de su código. También recordar que hace poco más de un mes que Facebook ha adquirido Friendfeed.

Más comentarios en Facebook publica Tornado, servidor web usado en FriendFeed en barrapunto

Enlaces varios (VI)

2009-07-27T23:31:00.002+02:00

Hace muchos días que no he podido escribir por aquí, así que quizás a alguien le pueda parecer interesante el dump de cosas que tenía semi-guardadas:

Sobre el lío de la eliminación de los conceptos en el borrador C++0x y su retraso en general:
Smaller is Faster (and Safer Too). De cómo chromium se auto-parchea con diferencias binarias.
Tech Or Management Beyond Age 39?
Dos sobre concurrencia y excepciones: 'Answering email about error handling in concurrent code' de Herb Sutter y 'Concurrency and exceptions' de Joe Duffy

La misma noticia y más comentarios en Enlaces varios (VI) en barrapunto

MinGW publica GCC 4.4.0

2009-06-25T23:25:00.006+02:00

El equipo de MinGW ha publicado los binarios de GCC 4.4.0 para Windows. De entre las novedades destacan un mejor tratamiento de excepciones, una versión de libstdc++ en forma de librería compartida, y soporte para TLS (thread-local storage), además de todas las novedades de la versión 4.4.0. Hay que recordar que la anterior versión soportada oficialmente era GCC 3.4.5. Más en reddit.

El manejo de las excepciones ha mejorado drásticamente debido a que se ha usado una implementación basada en DWARF, dejando de lado el viejo modelo SJLJ, que ya no estará disponible. Además con esta versión las excepciones ya pueden atravesar las fronteras de las DLL sin problemas.

La misma noticia y más comentarios en MinGW publica GCC 4.4.0 en barrapunto

memcpy y la concurrencia

2009-05-26T22:40:00.003+02:00

Si el otro día comentaban en barrapunto que en MS marcaban como peligroso el uso de memcpy hoy podemos encontrar otra razón para usarlo con precaución. En memcpy() concurrency curiosities David Dice habla de un comportamiento antiintuitivo de dicha función que sale a la luz en entornos fuertemente concurrentes: sobreescribir la misma secuencia constante en memoria puede tener valores no válidos temporalmente durante su llamada, leídos por otros threads con resultado catastrófico si no se tiene cuidado. Otro caso más en el que las abstracciones que usamos evolucionan a su manera, quizás con explicación pero con resultados que contradicen la intuición y exigen, a veces, conocer que se cuece allá abajo. (No mucho) más en reddit

La misma entrada y más comentarios en memcpy y la concurrencia en barrapunto

Avances en las implementaciones de C++0x

2009-05-05T19:48:00.002+02:00

Por lo que he leído hace un tiempo y ahora puedo comentar aquí, tanto gcc como VC++ se están poniendo las pilas en la implementación de C++0x.

Vía Drizzt, Qt 4.5.1 y gcc 4.4 leo que entre las más notables novedades de gcc4.4 se incluyen muchas características del C++0x, entre las cuales están declaraciones con auto y la inicialización de objetos con listas. Bien :) Se puede saber más en la página de status de la implementación de c++0x en gcc 4.4 donde se puede ver que la concurrencia no es una de las características más adelantadas, empezando por el modelo de memoria. Tiempo al tiempo...
En VC++ también van a buen ritmo, lo cual es bueno para el estándar, no como pasó con el VC++6 de infausto recuerdo y larga duración :). En el blog oficial de VisualC hablan de decltype (C++0x Features in VC10, Part 3) repasando esa característica de C++0x que por cierto ya está implementada también en gcc. Además apuntan a las dos entradas anteriores, que también resultan instructivas Lambdas, auto, and static_assert: C++0x Features in VC10, Part 1 y Rvalue References: C++0x Features in VC10, Part 2

Y ya que estamos en el tema dos enlaces de propina: Designing Multithreaded Programs in C++0x de Anthony Williams y GCC C++0x Features Exploration en C++ Soup! y por supuesto la imprescindible wikipedia que tiene un estupendo punto de entrada: C++0x

La misma entrada y más comentarios en Avances en las implementaciones de C++0x en barrapunto

Bitácoras de Programación: selección personal

2009-04-20T23:04:00.006+02:00

Llego tarde a la discusión generada con la entrada en la bitácora de leonidas en barrapunto que rvr pasó a portada acerca de blogs y feeds en general relacionados con la programación. Salen por supuesto muchos de los agregadores y planetas que consumo, como reddit, hacker news (uhmm, éste no sale), dzone o planeta código. Pero después de leer todas las respuestas me ha entrado la "necesidad" de hacer mi propia selección personal basada únicamente en gustos. Son bloggers que creo que son un poco distintos y, en su mayor parte combinan el bloguerío con un alto nivel técnico que dejan ver el sus posts. Allá van:

Mbpfernand0's Blog, el nuevo blog técnico de "nuestro" fernand0. El tema fundamental es la programación y la seguridad, aunque creo que no hace ningún asco a temas relacionados. Por cierto, que promete su propia selección de blogs sobre programación. Habrá que estar atento.
El valle del Viento Helado de Drizzt, el Drizzt de barrapunto también. Sistemas operativos, compiladores, administración y seguridad. Muy interesante.
.NET o no .NET, esa es la cuestión. Puedes no compartir sus preferencias tecnológicas, pero para mi es uno de los que mejor escribe y destila conocimiento y experiencia por todos los bits.

En inglés:

intertwingly de Sam Ruby. La web y sus estándares. Para mí, imprescindible.
jeffr_tech's Journal. Detalles internos del desarrollo de FreeBSD. No actualiza mucho pero merece la pena estar suscrito.
daniel.haxx.se de Daniel Stenberg. Del autor de curl y Rockbox entre otros, el blog de un desarrollador prolífico.
Coding Relic de Denton Gentry. Normalmente sobre Software embebido, pero toca otros palos.
Ulrich Drepper. El blog del mantenedor de la glib. Poco prolífico, pero para no perderse ni una sola entrada.
Nynaeve: Adventures in Windows debugging and reverse engineering. No se me ocurriría un mejor título nunca
Y por fin el imprescindible Sutter’s Mill: Herb Sutter on software, hardware, and concurrency

Ahora no se me ocurre ninguno más, pero pueden ser las prisas...

Actualización: He publicado este texto más o menos en un comentario por aquello de completar la información en su sitio. También lo pongo aquí y lo replicaré en mi bitácora en barrapunto, que a su vez se copiará en planeta código, por aquello de que lo que se replica queda y de que hay URLs que desaparecen...

Erlang 5.7/OTP R13A: soporte para Unicode, mejoras en multicore y SSL

2009-03-17T22:42:00.003+01:00

Acaba de salir la nueva versión del conjunto Erlang/OTP, en concreto la versión Erlang 5.7/OTP R13A. La nueva versión de un lenguaje y sus librerías no tiene por qué ser gran noticia, pero en este caso las novedades son tan notables que creo que merece una mención. Entre ellas se encuentran importantes mejoras de rendimiento en entornos multicore y SMP, que es especialmente importante teniendo en cuenta que una de las grandes bazas del lenguaje es su tratamiento de la concurrencia. Además destacan también el soporte para Unicode, posibilidad de usar WxWidgets a través del WxErlang (de momento en beta) y reescritura del soporte para SSL. Muchas de estas características eran necesarias para la introducción de este lenguaje más allá del entorno de las telecomunicaciones que históricamente ha sido su nicho natural. Más comentarios en reddit y Hacker News

La misma entrada y más comentarios en Erlang 5.7/OTP R13A: soporte para Unicode, mejoras en multicore y SSL en barrapunto

Aprendiendo de los errores (II)

2009-03-11T23:44:00.008+01:00

Dan J. Berstein reconoció una vulnerabilidad en djbdns y la recompensó con mil dólares y por supuesto no se han hecho esperar reflexiones acerca de la seguridad informática, su (im)posibilidad y su relación con lo disponible del código.

Entonces leo con interés, vía el nuevo subarrapunto de fernand0, un comentario en hispasec que no por evidente debe dejar de repetirse: no existe software sin fallos de seguridad, pero los que menos tienen son aquellos que han sido diseñados y programados desde su inicio con la seguridad y la simplicidad como guía.

Y ello descarta a casi todo el software y probablemente más al comercial, que tiene más presiones para añadir más y más cosas. Recordemos, que como decía Alan J. Perlis A la larga cualquier programa se vuelve rococó. Después escombros. Lo de siempre, funcionalidad contra robustez y simplicidad :)

De todos modos el caso de djbdns es también interesante por el tipo de fallo encontrado. En Hacker News comentaban que el problema era en la implementación de la compresión que usa en el protocolo DNS para sus paquetes, para eliminar redundancias. Y precisamente Bernstein había hablado negativamente del método de compresión (descrito, claro, en el RFC 1035, 4.1.4, página 30) Extractando de la crítica de Bernstein:

Un problema con la compresión DNS es la cantidad de código necesario para analizarla. Localizar de modo fiable los nombres lleva un trabajo que habría sido evitable para una caché DNS. La compresión LZ77 habría sido mucho más fácil de implementar.

Otro problema con la compresión DNS es la cantidad de código necesario para generarlo correctamente. [...]

Otro problema con la compresión DNS es que no es particularmente efectiva. LZ77 habría funcionado mejor en esos tipos de datos y funcionaría mejor con los tipos de registros que se popularizarían en el futuro [...](Y aquí habla de incompatibilidades de algunas versiones de BIND con el RFC)

Muy interesante todo el texto original, incluidas las elipsis ;) anque bastante específicas del caso DNS. Lo que no me ha quedado claro es la razón de no usar LZ77, si fue un caso de Síndrome NIH, de hackerismo o tenía algo que ver con las patentes sobre estos tipos de compresión que llevaban haciéndose desde 1984 como la del LZ78. Pero vamos como regla general parece mucho mejor usar un algoritmo conocido que inventar uno nuevo, a no ser que trabajes en eso, en innovar...

Creo que la moraleja es clara, como se dice a veces exagerando el mejor código es el que no existe sobre todo desde el punto de vista de la reducción de bugs y aún más si se trata de seguridad.

(Esto se llama Aprendiendo de los errores (II) porque ya escribí en su día Bugs antiguos y moralejas , que iba sobre lo mismo, también salía DJB y el DNS, en aquel caso con el bug/error de diseño que explotó Kaminsky)

La misma entrada y más comentarios en Aprendiendo de los errores (II) en barrapunto

Lo que Paul Graham ha aprendido con Hacker News

2009-02-26T20:24:00.007+01:00

Hacker news es un sitio de envío y comentario de noticias muy al modo de reddit (o digg o menéame), pero con temática muy definida (temática técnica, hacker en el sentido MIT ), con editores estrictos y con políticas severas de ontopic. Pues Paul Graham, su creador ha escrito What I've Learned from Hacker News, o sea, lo que ha aprendido con el sitio. Se puede estar de acuerdo o en desacuerdo en algunas cosas, pero es sin duda interesante. Extracto, lo que me ha llamado la atención:

Recuerda, la motivación original pata Hacker News fue testear un lenguaje nuevo, uno centrado en experimentar con el diseño de lenguajes, no en el rendimiento. Cada vez que el sitio se vuelve lento, me refuerzo a mi mismo recordando la famosa cita de McIlroy y Bentley:
La clave del rendimiento es la elegancia, no un batallón de casos especiales.

Y busco los cuellos de botella que puedo eliminar con menos código. Así he sido capaz de mantener un rendimiento mediocre a pesar de que el crecimiento se ha multiplicado por catorce.

Probablemente lo más importante que he aprendido acerca de la "disolución" es que se mide más por comportamiento que por usuarios. Es el mal comportamiento lo que hay que mantener alejado más que a las malas personas. El comportamiento de los usuarios es sorprendentemente maleable. Si se espera de la gente que se comporte bien tiende a hacerlo. Y viceversa.

Lo más peligroso de la portada son las que es demasiado fácil votar positivo. Si alguien prueba un nuevo teorema, le lleva tiempo al lector decidir si vota positivo o no.Un cómic divertido cuesta menos. Una crítica con un slogan como título cuesta cero, porque la gente lo vota sin ni siquiera visitar el enlace.

La forma más peligrosa de de comentario estúpido no es el argumento largo pero equivocado sino el chiste tonto. Los argumentos largos pero equivocados son bastante raros. Hay una gran correlación entre la calidad y la longitud del comentario.

[...]Visitar un foro online sólo cuesta un clic y se parece mucho superficialmente a trabajar. Puedes estar gastando tu tiempo, pero no estás parado. Alguien esta equivocado en Internet, y tú estás arreglando el problema.

Digg es conocido por su falta de trasparencia. La raíz del problema no son los tipos que llevan Digg sean especialmente furtivos, sino que usan un algoritmo equivocado para generar la portada. En lugar de subir conforme van teniendo más votos, como en Reddit, las historias empiezan arriba y las nuevas que van llegando las van empujando hacia abajo.

La razón de la diferencia es que Digg deriva de Slashdot mientras que Reddit de delicious/popular. Digg es Slashdot con votos en lugar de editores y Reddit es delicious/popular con votos en lugar de agregar a favoritos (Aún se pueden ver los fósiles de sus orígenes en sus diseños gráficos.)

Otra cosa que he aprendido de este experimento es que si vas a distinguir a las personas, hazlo bien. Este es uno de esos problemas en los que no funciona al prototipado rápido.

De hecho este es el argumento intelectualmente honrado para no discriminar a varios tipos de personas. La razón no es que todo el mundo es igual, sino que es malo hacerlo de modo incorrecto y es difícil hacerlo bien.

Yo particularmente estoy de acuerdo en casi todo. Sólo puntualizaría que hay honrosas excepciones en la correlación entre longitud y calidad. Un enlace relevante, una cita, a veces es breve pero muy relevante en la discusión. De todos modos por eso habla de correlación :)

La misma entrada y más comentarios en Lo que Paul Graham ha aprendido con Hacker News en barrapunto

¿Varios pájaros de un tiro?

2009-02-17T13:01:00.003+01:00

Vía intertwingly, el blog de Sam Ruby, me encuentro con una cita extraída de una de las listas del W3C que traduzco sin más:

Un error muy común que los ingenieros de software cometen al diseñar una arquitectura es fijarse en cinco problemas, ver lo que tienen en común e intentar resolver los cinco a la vez. El resultado es casi siempre una solución por debajo de lo estándar para todos ellos.

Sí, una tendencia común, más acusada curiosamente en los desarrolladores que se intentan preocupar por la calidad de su trabajo. Para no caer inercialmente en ella habría que evaluar lo económico del desarrollo con lo limitado de las soluciones, algo que demasiadas veces no se hace.

Me ha recordado además a un "cartel motivador" sobre el principio de responsabilidad única que vi hace poco en reddit (Aquí se pueden ver todos los carteles, por si a alguien le son de utilidad :)

Ah, ya que estoy aquí, recomiendo la lectura del blog de Sam y de las listas relativas al HTML5 para ver flames de altura :)

Actualización egórica: A través de una detección automática de referencias Sam se ha enterado de mi enlace y le ha gustado mi referencia al "cartel motivador", que le da más argumentos en el flame. Y me ha enlazado en un comentario. Nunca lo hubiera pensado :)

La misma entrada y más comentarios en ¿Varios pájaros de un tiro? en barrapunto

Epigramas sobre programación

2009-02-05T23:02:00.004+01:00

Siguiendo un enlace en technovelty he llegado a un artículo de Alan J. Perlis en el que a través de ciento treinta epigramas trató, en 1982, de capturar algunos de los aspectos más curiosos, desconcertantes y antiintuitivos de la computación en general y la programación en particular. Han pasado más de veintiséis años, pero mucha de su naturaleza creo que sigue intacta. Algunos creo haberlos leído en otra parte y supongo que al que lea esto le pueden sonar, pero me gustan, así que aquí van. Traduzco los que me han parecido mejores:

Epigramas:

7. Es más fácil escribir un programa incorrecto que entender uno correcto.

8. Un lenguaje de programación es de bajo nivel cuando sus programas requieren atención sobre lo irrelevante.

9. Es mejor tener 100 funciones operando sobre una estructura de datos que 10 funciones sobre 10 estructuras de datos.

14. A la larga cualquier programa se vuelve rococó. Después escombros.

15. Todo debería desarrollarse de arriba a abajo, excepto la primera vez.

17. Si alguien parece que está asintiendo cuando le explicas tu programa, despiértale.

19. Si un lenguaje no cambia el modo en el que ves la programación es que no merece la pena.

21. La optimización dificulta la evolución.

31. La simplicidad no precede a la complejidad, la sigue.

40. Hay dos modos de escribir programas sin errores. Sólo la tercera funciona.

57. Es más fácil cambiar la especificación para que se ajuste al programa que al contrario.

58. Los locos ignoran la complejidad. Los pragmáticos la sufren. Algunos pueden evitarla. Los genios la eliminan.

63. En computación, los invariantes son efímeros.

65. No te equivoques: los ordenadores procesan números, no símbolos. Medimos nuestro conocimiento (y control) de una actividad en la medida en la que podemos arimetizar.

75. Debido a su vitalidad la informática está a la busca desesperada de nuevos clichés: la banalidad calma nuestros nervios.

93. Cuando alguien diga "Quiero un lenguaje de programación en el que sólo tenga que decir lo que deseo hacer", regálale una piruleta.

95. No tengas buenas ideas si no eres capaz de responsabilizarte de ellas.

104. La prueba del valor de un sistema es su existencia.

115. Mucha gente encuentra el concepto de programar obvio, pero hacerlo les resulta imposible.

MetaEpigramas:

124. Los epigramas son macros, porque son ejecutados en tiempo de lectura.

125. Los epigramas cristalizan incongruencias.

127. Los epigramas desdeñan los detalles y lo hacen con intención: son una documentación de alto nivel excelente.

El lector atento verá que si se juntan la 8 y la 93 no existen lenguajes de alto nivel. Pero si se mezcla con la 125 ya no está tan claro. Bueno, para pensar un rato. Pero no demasiado, que luego hay que codificar :)

La misma entrada y más comentarios en Epigramas sobre programación en barrapunto

5 Secrets To Ninja Writing

2009-02-04T10:14:00.002+01:00

5 Secrets To Ninja Writing. (Vía reddit)

Es mucho más recomendable pinchar en el enlace anterior si conoces el blog de Jeff Atwood, Coding Horror.

Está muy logrado, sobre todo la parodia del abuso de la autorreferencia, un vicio muy de blogstar, muy feo :)

La misma entrada y más comentarios en 5 Secrets To Ninja Writing en barrapunto

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

2009-01-28T22:47:00.003+01:00

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

2009-01-14T22:13:00.003+01:00

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

2009-01-07T10:34:00.003+01:00

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

2008-12-13T22:53:00.003+01:00

[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

2008-12-09T12:31:00.003+01:00

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?

2008-11-27T11:36:00.005+01:00

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

2008-11-21T09:28:00.008+01:00

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

2008-11-17T18:38:00.005+01:00

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

2008-11-11T14:02:00.000+01:00

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

2008-11-10T17:07:00.002+01:00

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

Completado el borrador de C++0x

2008-10-29T13:05:00.003+01:00

Como comenta Herb Sutter en su blog, se ha publicado el borrador (pdf) de C++0x que se pasará a la votación internacional. Creo que es una buen noticia para todos los usuarios de C++, porque como dicen en reddit, map<string, string>::iterator, tu larga década de terror se ha acabado :) Además, y no menos importante, toda una serie de características como rvalues, lambdas, conceptos, librería de operaciones atómicas, librería de threads, soporte para expresiones regulares...

Y uno de los arreglos más importantes, el modelo de memoria. Del borrador:

The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain any member of the basic execution character set and the eight-bit code units of the Unicode UTF-8 encoding form and is composed of a contiguous sequence of bits, the number of which is implementationdefined.
The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. The memory available to a C++ program consists of one or more sequences of contiguous bytes. Every byte has a unique address.
[...]
A memory location is either an object of scalar type or a maximal sequence of adjacent bit-fields all having non-zero width. [...] Two threads of execution can update and access separate memory locations without interfering with each other.

Enhorabuena a los premiados. Ahora falta que los implementadores hagan su trabajo. MS VC++ parece que va avanzando para llegar a VC++2010. (Estoy seguro que la coincidencia del borrador de C++0x y la publicación este post en el blog de VC++ no es casual...) gcc, aunque más lento, también va avanzando y ya se pueden probar algunas características.

La misma entrada y más comentarios en Completado el borrador de C++0x en barrapunto

Varios sobre concurrencia y el rol de los 'arquitectos'

2008-10-23T09:48:00.003+02:00

Comenzando por el minipost de Miguel de Icaza en el que habla de programación paralela y siguiendo enlaces:

Design Considerations For Parallel Programming de David Callahan
Solving 11 Likely Problems In Your Multithreaded Code de Joe Duffy
Repasando el blog de este último también apunta a .NET Matters: False Sharing
Y también del blog de Joe Duffy, y aunque no es sobre concurrencia y probablemente sean obviedades, me ha gustado A few thoughts on the role of software architects

La misma entrada y más comentarios en Varios sobre concurrencia y el rol de los 'arquitectos' en barrapunto

Las matemáticas 'innatas' en el ser humano

2008-10-14T23:21:00.003+02:00

Nota: Para los lectores de PlanetaCódigo. Esta es una entrada sobre ciencia y matemática y no sobre programación. Si no te interesa no tienes más que saltártela :)

Ayer en la cola de pendientes de menéame leí una noticia demasiado escueta que hablaba de niños aborígenes australianos capaces de contar sin números. Rebuscando un poquito encontré la nota de prensa original, que por lo menos es un poco más explicativa.

Y es que este tipo de estudios sacan resultados que al menos a primera vista pueden resultar antiintuitivos: nuestra capacidad matemática parece estar más allá de nuestra capacidad verbal. O dicho de otro modo, parece que la evolución nos ha hecho más viables con un pequeño coprocesador matemático, aparentemente no específica a nuestra especie porque, como decía otro estudio de hace un tiempo, los monos tienen células dedicadas a contar.

También acerca del equipamiento matemático del ser humano se oyó hace un tiempo (quizás Log or Linear? Distinct Intuitions of the Number Scale in Western and Amazonian Indigene Cultures) que las escalas logarítmicas pueden resultar más intuitivas que las lineales a un humano sin formación cultural y/o matemática.

Me parecen muy reveladoras este tipo de investigaciones ¿Conocéis más publicaciones y/o artículos de este estilo? ¿Qué opináis de la relación entre el ser humano y la matemática?

La misma entrada y más comentarios en Las matemáticas 'innatas' en el ser humano en barrapunto