Sembra che NUMA sia promettente per la programmazione parallela e, se non sbaglio, gli attuali cpus di ultima generazione dispongono di un supporto integrato, come l'i7.Prevedete che il CLR adatterà presto NUMA?
Prevedete il CLR per adattare NUMA al più presto?
EDIT: Con questo intendo avere il supporto per questo, e approfittarne.
NUMA è un'architettura hardware, non necessariamente qualcosa che richiede l'adozione nel CLR direttamente. Per i dettagli, vedere NUMA FAQ.
Detto questo, ci sono dei vantaggi nel rendere il software consapevole della sua architettura. I membri del team CLR sembrano essere a conoscenza di problemi di coerenza della cache, ecc., Quindi scommetto che ci sono alcune ottimizzazioni per questo. Inoltre, la progettazione dello scheduler nella libreria parallela delle attività in C# 4 sembra essere promettente per sfruttare meglio le architetture NUMA.
In un certo senso, NUMA è ortogonale al modello di memoria del CLR. In altre parole, l'hardware/sistema operativo ha il suo metodo di accesso, il CLR ha le sue richieste di modello di memoria, e spetta all'implementatore CLR fare in modo che il gioco sia piacevole insieme. In pratica, questo è difficile e there are flaws in the current implementation. Ma poiché il CLR funziona già su hardware che supporta NUMA, non sono sicuro di cosa intendi per "adattare NUMA al più presto."
Per quanto ne so, CLR utilizza la stessa strategia di allocazione della memoria di primo tocco utilizzata dal sistema operativo sottostante. Il primo thread per toccare una pagina virtuale viene mappato (dal sistema operativo penso che non sia il CLR) nel nodo NUMA corrispondente alla CPU su cui si trova il thread. È molto probabile che un thread su una CPU diversa utilizzi la stessa memoria (che ora si trova su un nodo NUMA non valido) più avanti nel corso della durata dell'app. –
Tutte le risposte qui sono corrette per evidenziare NUMA come un'architettura hardware. sarebbe this article by Joe Duffy sulla concorrenza e il CLR.
con NUMA fondamentalmente si dispone per controller memoria del processore. Bisogna che con Intel QuickPath e con AMD HyperTransport. il fatto è che, per quanto ne so, al momento non ci sono schede madri né per i7, né per Phenom, che supporterebbe più di una CPU
In ogni caso, questo è un livello molto basso, che non ha nulla a che fare con CLR. sistema per trarne vantaggio.
Non è vero. È compito dell'heap manager (o in questo caso del gestore della memoria CLR) essere consapevole della NUMA, oppure no. Il sistema operativo probabilmente non avrà mai informazioni sufficienti per prendere decisioni migliori rispetto all'attuale strategia di primo tocco utilizzata da Windows e Linux. Vedi http://stackoverflow.com/questions/9439402/array-memory-management –
Avete riferimenti per "sembrano essere a conoscenza di problemi con coerenza della cache" e "progettazione dello scheduler ... promettente ..."? Mi piacerebbe leggere di più. –
FYI: "La coerenza della cache" non è un problema software. Questo è stato risolto da Intel e AMD, perché i NUMA mainstream sono tutti ccNUMA (NUMAs coerenti con la cache). Ciò che il software deve risolvere, tuttavia, è dove allocare memoria, per quale thread/processo, a seconda di quali core/cpu (s) su cui gira (affinità). –