memcpy y la concurrencia

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

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

Firefox usará el asignador de memoria experimental de FreeBSD

Leo en (cómo no...) en programming.reddit que Firefox 3 beta 3 utiliza el asignador de memoria dinámica experimental de FreeBSD (jemalloc) en lugar del asignador de la plataforma de ejecución. Al parecer ha dado buenos resultados en cuanto velocidad y reducción de la fragmentación en los test de rendimiento para las tres plataformas mayoritarias (Windows, Mac OS X y Linux)

Para el que esté interesado en estos temas hay disponible un artículo muy interesante sobre jemalloc: A Scalable Concurrent malloc(3) Implementation for FreeBSD (pdf) en el que se explica su implementación, que coge ideas entre otros de hoard, y ciertamente tiene muy buena pinta. Hablé de hoard hace poco en Problemas de memoria (y algunas soluciones).

Firefox usará el asignador de memoria de FreeBSD en barrapunto

(Otros) problemas con la memoria y (otras) soluciones

Alguien en programming.reddit hizo una pregunta de esas difíciles: ¿Cómo manejar en un programa en C los casos en los que la memoria se agota? Y digo que es una de esas preguntas difíciles porque depende del tipo de software que estás haciendo, de su criticidad y del nivel requerido de robustez. Ya se sabe, el difícil compromiso de la gestión de errores críticos.

Y como se ve en las respuestas de los redditenses no sólo depende de nuestro sistema, sino de detalles de implementación de más abajo, como suele ser usual en los casos no del todo raros en los que las abstracciones que usamos comienzan a flaquear. En este caso se habla del comportamiento de Linux (el kernel) a la hora de tratar la falta de memoria, que por defecto usa una estrategia optimista que deja reservar (pero no usar, claro) más memoria de la disponible. No obstante este comportamiento se puede cambiar a uno un poco más controlable a través del parámetro overcommit_memory, que se introdujo no hace tanto... El comportamiento por defecto es llamar al OOM Killer que es un método tan drástico como poco predecible. Todo esto esta muy bien explicado en When Linux Runs Out of Memory que vi referenciado por aquí en tiempos de mayor intensidad técnica :)

Además en las respuestas se apunta a un libro online de los que vienen bien cuando las condiciones son más extremas de lo usual: Small Memory Software. Patterns for systems with limited memory. Apuntado en éste mi del.icio.us particular.

(El título es "(Otros) problemas con la memoria y (otras) soluciones " porque no hace mucho escribí Problemas de memoria (y algunas soluciones), sobre el cuello de botella que supone la gestión de memoria sobre todo en sistemas multicore)

"(Otros) problemas con la memoria y (otras) soluciones" en barrapunto

Problemas de memoria (y algunas soluciones)

Gracias a Lambda The Ultimate he encontrado un artículo muy ilustrativo sobre el típico flame de gestión automática de memoria contra gestión manual: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management de Matthew Hertz, Yi Feng, Emery D. Berger. Si hacemos caso de sus conclusiones:

Si las aplicaciones se ejecutan en sistemas con al menos tres veces más memoria RAM de la necesaria entonces la recolección de basura proporciona un rendimiento razonable. Sin embargo si el sistema dispone de menos RAM o las aplicaciones tienen que competir con otras por memoria entonces se debe esperar que la recolección de basura traiga consigo un coste de rendimiento sustancial.

Como es sabido, no es blanco ni negro, sino que es una cuestión de compromisos, pero al menos ahora tenemos algún dato para tomar la decisión. De todos modos el artículo tiene más cosas que esta conclusión: compara diversas estrategias de recolección de basura y tiene muchas referencias interesantes.

A raíz de una de esas referencias me he encontrado con un asignador de memoria dinámica (allocator): hoard, curiosamente desarrollado por Emery Berger, uno de los autores del artículo anterior. Este asignador promete evitar uno de los grandes cuellos de botella de la programación con threads y sistemas multicore: la gestión de la memoria dinámica, el heap. Citando también del primer artículo:

En particular, las versiones recientes de hoard mantiene en el espacio local del thread la lista de los espacios libres (freelist) y usa generalmente operaciones atómicas sólo cuando se sincronizan o se rellenan.

Muy interesante...

Problemas de memoria (y algunas soluciones) en barrapunto

Lo que todo programador debería saber sobre la memoria (pdf)

Ulrich Drepper ha acabado de publicar online la serie de artículos acerca de la memoria, cachés en arquitecturas modernas de uso común y de lo que el programador puede hacer al respecto. Cuando comenzó ya lo comentamos por aquí en Lo que todo programador debería saber sobre la memoria.

Y como prometió lo ha publicado ahora en pdf: "What Every Programmer Should Know About Memory" por Ulrich Drepper. Como puede ser que alguien interesado no se haya enterado de su existencia, la aparición del pdf puede ser un buen momento para recordarla...

Lo que todo programador debería saber sobre la memoria (pdf) en barrapunto

Lo que todo programador debería saber sobre la memoria

Así titula Ulrich Drepper un artículo sobre los posibles cuellos de botella que se generan en las arquitecturas modernas de uso común, explicando el comportamiento de las caches de CPU, el diseño de los controladores de memoria, el DMA... Debería ser útil para esos momentos en los que las abstracciones que usamos empiezan a fallar y debemos conocer lo que hay debajo.

El modo de publicarlo es un poco, bueno, llamémosle arcaico, pero nos conformaremos porque el contenido lo merece, y porque es el deseo del autor, claro... El caso es que se va a publicar por partes en LWN.net y al comienzo serán accesibles solo para suscriptores y posteriormente para el resto. Al final publicarán la versión pdf que probablemente será muy interesante para imprimir. Actualización (22/11/07): Ya está disponible la versión en pdf: "What Every Programmer Should Know About Memory" por Ulrich Drepper

He ido actualizando esta entrada conforme se han liberado las todas las partes del documento, muy interesantes:

• What every programmer should know about memory, Part 1
• Memory part 2: CPU caches
• Memory part 3: Virtual Memory
• Memory part 4: NUMA support
• Memory part 5: What programmers can do
• Memory part 6: More things programmers can do
• Memory part 7: Memory performance tools
• Memory part 8: Future technologies
• Memory part 9: Appendices and bibliographys

Bonus Track: Como creo que pega en esta entrada, pongo el link a unas charlas con diapositivas de Herb Sutter sobre temas similares: Machine Architecture: Things Your Programming Language Never Told You (jejeje, Sutter y Drepper ¿lo mejor de los los dos mundos?)

Lo que todo programador debería saber sobre la memoria en barrapunto