Come vengono distribuiti i core della CPU a ciascun kernel nel calcolo della parallelizzazione?
Voglio solo assicurarmi di aver capito correttamente prima di porre domande. Ho visto alcune persone dire che alcune funzioni in Mathematica useranno automaticamente i multi-core (non mi riferisco a quelli che parallelizziamo, ma mi riferisco a quelli come NIntegrate), quindi penso che se ho 2 core, sarà più veloce del singolo nucleo. Quindi la mia domanda è se ho un codice come il seguente:ParallelTable[NIntegrate[x, {x, 1, 3}], {loop, 1, 3}]
Penso che verranno lanciati tre kernel. Se ho 4 core, come vengono distribuiti questi quattro core a ciascun kernel? (Dal momento che penso che ogni kernel possa utilizzare multi-core in base alla proprietà di integrazione delle funzioni)
Risposte
Benvenuto noo-b, m.se è una grande comunità per l'apprendimento infinito di M!
Penso che tu abbia alcune false supposizioni:
Innanzitutto, anche le operazioni a thread singolo possono eseguire il thread su più core. Un buon sistema operativo cerca di evitarlo, ma ogni tanto può passare a un altro core, o può suddividere il carico su più core, anche se quest'ultimo di solito non per un tempo prolungato.
In secondo luogo, non si può presumere che NIntegrate si parallelizzerà sempre per tutti gli input, e in particolare non si può presumere che NIntegrate si parallelizzerà per l'intero tempo di calcolo. Può parallelizzare solo per l'inizializzazione o alla fine, o per selezionare le attività in mezzo. Per esempio,
Do[Do[NIntegrate[x,{x,1,3}],{3}],{100000}]
se guardi l'utilizzo di base (non: utilizzo del processo, come in un semplice task manager) - se sei su Linux, puoi eseguire top e premere 1 - vedrai che questo spende il 99% del tempo su un nucleo. Potrebbe cambiare il core dopo un po 'di tempo, ma poi vedi il 99% per quel core. Quindi non vedo affatto il threading NIntegrate su più core, almeno non sempre (forse per frazioni di secondo). Questo può essere diverso per diversi input di NIntegrate, ma questo semplice esempio mostra che NIntegrate non sempre parallelizza e non per l'intera durata del suo calcolo.
Con il framework di parallelismo M questo non cambia, è davvero una questione di sistema operativo. Con ParallelTable (e fratelli) stai solo fornendo attività di elaborazione da più processi e come le pianificazioni di o / s che ai core dipendono interamente dalle o / s. Quindi non puoi davvero "annullare" l'assegnazione ai core dalla comprensione dei processi paralleli.
un po 'una tangente:
In Scala, Java o C # (o molti altri linguaggi) puoi programmare le attività a livello di thread. Ma anche in questo caso spetta agli o / s programmare le pedate sui core. Con vmstat di Java hai una visualizzazione meravigliosa dei thread (barre orizzontali che crescono nel tempo, una per thread), penso che quello che ti interessa veramente è come funzionano le cose nei thread, non necessariamente come i thread sono assegnati ai core . Detto questo, i thread sono un concetto software, non un concetto hardware, un core non sa cosa sia un thread. Ma penso che un'analisi del thread ti direbbe di più per capire la concorrenza in quanto l'assegnazione ai core e lo switching dei core e le percentuali del carico di lavoro per ogni core dipendono interamente dall'o / s.
Ci sono alcune funzioni che utilizzano automaticamente più core. Il numero di core che usano è determinato da alcune delle impostazioni in SystemOptions["ParallelOptions"].
Se utilizzi tali funzioni sui subkernel, utilizzeranno solo un singolo core. Puoi verificarlo guardando ParallelEvaluate@SystemOptions["ParallelOptions"]. Si noti che tutti i conteggi dei thread sono impostati su 1 nei sottokernel.
In genere, la parallelizzazione esplicita (come ParallelTable) non è efficiente come la parallelizzazione incorporata di alcune funzioni. Pertanto, se il collo di bottiglia è una funzione che viene già eseguita in parallelo, l'implementazione della parallelizzazione aggiuntiva con ParallelTableo le funzioni correlate lo rallenterà (o almeno lo ha rallentato in tutti i casi che ho controllato).