Parece que NUMA es prometedor para la programación paralela, y si no estoy equivocado, la última versión de la CPU actual tiene soporte integrado, como el i7.¿Anticipa que CLR adaptará NUMA pronto?
¿Anticipa que la CLR adaptará NUMA pronto?
EDITAR: Con esto me refiero a tener soporte para ello y aprovecharlo.
NUMA es una arquitectura de hardware, no necesariamente algo que necesita adopción en el CLR directamente. Para obtener más información, consulte NUMA FAQ.
Dicho esto, existen ventajas para que el software conozca su arquitectura. Los miembros del equipo de CLR parecen estar al tanto de los problemas con la coherencia del caché, etc., así que apostaría a que hay algunas optimizaciones para esto. Además, el diseño del programador en la biblioteca paralela de tareas en C# 4 parece ser prometedor para aprovechar mejor las arquitecturas NUMA.
En cierto sentido, NUMA es ortogonal al modelo de memoria de CLR. En otras palabras, el hardware/sistema operativo tiene su método de acceso, el CLR tiene sus demandas de modelo de memoria, y le corresponde al implementador de CLR hacer que funcionen bien juntas. En la práctica, esto es difícil, y there are flaws in the current implementation. Pero como el CLR ya funciona con hardware compatible con NUMA, no estoy muy seguro de lo que quiere decir con "adaptar NUMA pronto.?
Hasta donde yo sé, CLR utiliza la misma estrategia de asignación de memoria de primer toque que utiliza el sistema operativo subyacente. El primer hilo para tocar una página virtual lo mapea (por el sistema operativo, creo, no por el CLR) en el nodo NUMA correspondiente a la CPU donde está el hilo. Es muy probable que un hilo en una CPU diferente use esa misma memoria (que ahora está en un nodo NUMA defectuoso) más adelante durante la vida útil de la aplicación. –
Todas las respuestas hasta ahora son correctas al resaltar NUMA como arquitectura de hardware. sería this article by Joe Duffy en concurrencia y el CLR
Con NUMA básicamente tiene por controlador de memoria del procesador. Lo tiene con Intel QuickPath y con AMD HyperTransport. El hecho es que, hasta donde yo sé, actualmente no hay placas base ni para i7, ni para Phenom, que admitiría más de una CPU.
De todos modos, este es un nivel muy bajo, que no tiene nada que ver con CLR. sistema para aprovecharlo.
Eso no es verdad. Depende del gestor de pila (o en este caso del administrador de memoria CLR) ser consciente de NUMA o no. El sistema operativo probablemente nunca tendrá suficiente información para tomar mejores decisiones que la estrategia actual de primer toque que utilizan Windows y Linux. Ver http://stackoverflow.com/questions/9439402/array-memory-management –
¿Tiene alguna referencia para "parece ser consciente de problemas con la coherencia de la memoria caché" y "diseño del planificador ... prometedor ..."? Me encantaría leer más. –
FYI: "Coherencia de caché" no es un problema de software. Eso ha sido resuelto por Intel y AMD, porque los NUMA principales son todos ccNUMA (NUMA coherentes). Sin embargo, lo que el software tiene que resolver es dónde asignar memoria, para qué hilo/proceso, dependiendo de qué núcleos/CPU se ejecuta (afinidad). –