Guettli
Leí este artículo sobre el rendimiento de PostgreSQL: http://akorotkov.github.io/blog/2016/05/09/scalability-towards-millions-tps/
Una optimización fue la “alineación de cacheline”.
¿Qué es esto? ¿Cómo ayuda y cómo aplicar esto en el código?
Los cachés de la CPU transfieren datos desde y hacia la memoria principal en fragmentos llamados líneas de caché; un tamaño típico para esto parece ser de 64 bytes.
Los datos que se encuentran más cerca uno del otro pueden terminar en la misma línea de caché.
Si estos datos son necesarios para diferentes núcleos, el sistema tiene que trabajar duro para mantener la coherencia de los datos entre las copias que residen en las memorias caché de los núcleos. Esencialmente, mientras un subproceso modifica los datos, el otro subproceso está bloqueado por un bloqueo para acceder a los datos.
El artículo al que hace referencia habla sobre uno de esos problemas que se encontró en PostgreSQL en una estructura de datos en la memoria compartida que diferentes procesos actualizan con frecuencia. Al introducir relleno en la estructura para inflarla a 64 bytes, se garantiza que ninguna de estas estructuras de datos termine en la misma línea de caché y que los procesos que acceden a ellas no se bloqueen más de lo absolutamente necesario.
Esto solo es relevante si su programa paraleliza la ejecución y accede a una región de memoria compartida, ya sea mediante subprocesos múltiples o mediante procesamiento múltiple con memoria compartida. En este caso, puede beneficiarse asegurándose de que los datos a los que acceden con frecuencia diferentes subprocesos de ejecución no estén ubicados lo suficientemente cerca de la memoria como para que puedan terminar en la misma línea de caché.
La forma típica de hacerlo es agregando un espacio de relleno “muerto” al final de una estructura de datos.
Encontré algunos artículos interesantes sobre el tema que tal vez quieras leer:
http://www.drdobbs.com/parallel/maximize-locality-minimize-contention/208200273?pgno=3
http://www.drdobbs.com/tools/memory-constraints-on-thread-performance/231300494
http://www.drdobbs.com/parallel/eliminate-false-sharing/217500206
-
Mi última programación en C se realizó hace más de diez años, pero su respuesta lo explica bien. Gracias 🙂
– Guettli
12 de octubre de 2016 a las 7:47
-
Vale la pena señalar que la diferencia de rendimiento extrema que se muestra en el artículo al que se hace referencia es en un servidor de múltiples sockets, donde el costo de mantener la coherencia de la memoria caché entre los núcleos es especialmente alto.
–Nick Barnes
12 de octubre de 2016 a las 7:55
La publicación vinculada a esa página explica lo que está sucediendo bastante bien: postgresql.org/mensaje-id/…
– arroz
11 de octubre de 2016 a las 6:47
@paddy sí, la publicación que me gustó explica que la alineación de cacheline ayudó a mejorar el rendimiento, pero creo que no explica qué es y cómo funciona.
– Guettli
11 de octubre de 2016 a las 8:01
en.wikipedia.org/wiki/Data_structure_alignment El problema es ese desalineado las estructuras de datos abarcarán más caché tragamonedas y aumentará la cantidad de tráfico de autobuses.
– joop
11 de octubre de 2016 a las 8:46