Scheint wie NUMA ist vielversprechend für die parallele Programmierung, und wenn ich nicht falsch bin, haben die aktuellen neuesten CPUs eingebaute Unterstützung dafür, wie der i7.Erwarten Sie, dass die CLR die NUMA bald anpassen wird?
Erwarten Sie, dass die CLR NUMA bald anpassen wird?
EDIT: Damit meine ich, Unterstützung zu haben und davon zu profitieren.
NUMA ist eine Hardware-Architektur, die nicht unbedingt in der CLR verwendet werden muss. Weitere Informationen finden Sie unter NUMA FAQ.
. Es gibt jedoch Vorteile, Software auf ihre Architektur aufmerksam zu machen. Die Leute im CLR-Team scheinen sich der Probleme mit der Cache-Kohärenz usw. bewusst zu sein, also würde ich wetten, dass es dafür einige Optimierungen gibt. Auch der Entwurf des Schedulers in der parallelen Task-Bibliothek in C# 4 scheint vielversprechend zu sein, um Vorteile von NUMA-Architekturen zu nutzen.
In gewisser Hinsicht ist NUMA orthogonal zum Speichermodell der CLR. Mit anderen Worten, die Hardware/OS hat ihre Zugriffsmethode, die CLR hat ihre Speichermodellanforderungen, und es liegt an dem CLR-Implementierer, das zusammen zu spielen. In der Praxis ist dies schwierig und there are flaws in the current implementation. Aber da die CLR bereits auf Hardware läuft, die NUMA unterstützt, bin ich mir nicht sicher, was Sie mit "NUMA bald anpassen" meinen?
Soweit ich weiß, verwendet CLR die gleiche Speicherzuordnungsstrategie, die das zugrunde liegende Betriebssystem verwendet. Der erste Thread, der eine virtuelle Seite berührt, wird von dem Betriebssystem (ich denke nicht von der CLR) in den NUMA-Knoten gemappt, der der CPU entspricht, auf der der Thread gerade läuft. Die Chancen stehen gut, dass ein Thread auf einer anderen CPU denselben Speicher (der sich jetzt auf einem schlechten NUMA-Knoten befindet) später während der Lebensdauer der App verwenden wird. –
Alle Antworten hier sind korrekt, um NUMA als Hardware-Architektur hervorzuheben. Eine interessante Lektüre wäre this article by Joe Duffy on concurrency und der CLR
Mit NUMA haben Sie grundsätzlich pro Prozessor Speichercontroller.Das haben Sie mit Intel QuickPath und mit AMD HyperTransport.Die Sache ist, soweit ich weiß, derzeit gibt es keine Motherboards weder für i7, noch für Phenom, das würde mehr als eine CPU unterstützen
Wie auch immer, das ist ein sehr niedriger Level, der nichts mit CLR zu tun hat System, um davon zu profitieren.
Das stimmt nicht. Es ist Sache des Heap-Managers (oder in diesem Fall CLR-Speicher-Manager), NUMA-fähig zu sein oder nicht. Das Betriebssystem wird wahrscheinlich nie genug Informationen haben, um bessere Entscheidungen zu treffen als die aktuelle First-Touch-Strategie, die Windows und Linux verwenden. Siehe http://stackoverflow.com/questions/9439402/array-memory-management –
Haben Sie Referenzen für "scheinen Probleme mit Cache-Kohärenz zu kennen" und "Design des Schedulers ... vielversprechend ..."? Ich würde gerne mehr lesen. –
FYI: "Cache-Kohärenz" ist kein Softwareproblem. Dies wurde von Intel und AMD gelöst, da Mainstream-NUMAs alle ccNUMAs (cache coherence coherence NUMAs) sind. Welche Software jedoch zu lösen hat, ist, wo Speicher für welchen Thread/Prozess zugeordnet wird, abhängig davon, auf welchen Cores/CPUs er läuft (Affinität). –