quanti core devo utilizzare per i calcoli? #cores o #cores -1?

I principali sistemi operativi sono abbastanza maturi per sapere come gestire i processi che utilizzano tutti i core disponibili. Altri processi potrebbero (e spesso saranno) influenzati, ma il calcolo non diventerà più lento perché hai utilizzato tutti i core disponibili.

La scelta del numero di core dipende più dalla tua intenzione di fare qualcos'altro mentre il calcolo viene eseguito.

Se, su un computer desktop, vuoi essere in grado di utilizzare il tuo browser web o guardare un video mentre viene eseguito il calcolo, è meglio mantenere un core gratuito per questo. Allo stesso modo, se il server sta facendo due cose (come fare calcoli e, allo stesso tempo, elaborare e riportare le sue metriche), mantenere un core gratuito per l'attività secondaria potrebbe essere una buona idea.

D'altra parte, se la tua priorità è rendere il calcolo il più veloce possibile, devi usare tutti i core.

Dipende.

Se la macchina è dedicata a questo calcolo, dovresti utilizzare tutti i core - le risorse di calcolo inutilizzate non accelerano le cose .

Se si utilizza uno scheduler in tempo reale, uno scheduler non predittivo o un'affinità del processore, si dovrebbe essere un po 'più cauti perché è facile morire di fame accidentalmente altri processi da tutte le risorse di calcolo. Tuttavia, dovresti modificare manualmente queste impostazioni affinché qualcosa non funzioni, quindi per impostazione predefinita non ci sono problemi qui sulla maggior parte dei sistemi operativi.

Se la macchina non è dedicata al calcolo, dare il 100% al calcolo potrebbe non essere l'ideale. Ad esempio, se stai utilizzando un browser web mentre il calcolo è in esecuzione. Poiché il carico della tua macchina raggiunge occasionalmente un picco superiore al 100%, si sentirà lento. Le attività orientate al throughput come il calcolo non saranno realmente rallentate, ma le attività sensibili alla latenza come le GUI non reagiranno altrettanto rapidamente. È quindi sensato iniziare solo i thread / processi NPROC-1 per il calcolo. In alternativa, l'utilizzo esplicito di una priorità più bassa per il calcolo rispetto a compiti normali potrebbe risolvere questo problema, nel qual caso il calcolo dovrebbe utilizzare i processi NPROC per non sprecare risorse.

Sono un po 'cauto nel concordare con @motoDrizzt, di seguito, a causa dei suoi voti negativi :), ma questa è stata davvero la mia esperienza attuale - più è meglio, anche oltre il numero effettivo di core (ma non migliaia). Ad esempio, dai un'occhiata al link dove ogni piano 2D di quel 3D-voronoi_diagram può essere generato indipendentemente. E il programma accetta un attributo nfork = n query_string per sborsare i calcoli per n piani "simultaneamente".

Con un processore a quattro core, il tempo (utente) per completare il diagramma diminuisce praticamente linearmente con nfork, fino a circa nfork = 8 (quattro core hyperthreaded). Ma oltre l'8, il tempo diminuisce ancora, anche se più lentamente. E oltre a circa 16, o giù di lì, nessun ulteriore miglioramento evidente. Non ho analizzato questo comportamento, ma lo attribuisco ingenuamente ai processi di manipolazione os (linux slackware 14.2x64 in questo caso) per ridurre ulteriormente il tempo di inattività complessivo.

La scelta migliore dipende dal sistema. Quindi quello che vuoi fare è eseguire entrambe le versioni su un sistema reale, e quindi controllare come risponde il sistema. Puoi ancora utilizzare browser, editor di testo, altre cose sul tuo sistema? E le prestazioni sono migliori quando si usano n thread e non n-1? Cosa succede se si esegue l'app insieme a un'altra app che tenta di utilizzare tutte le CPU?

E quindi devi considerare l'hyperthreading. Con quattro core più hyperthreading, è possibile utilizzare 8 core o 7 core. Ancora una volta, prova la reattività del sistema e il tempo per finire.

Infine, considera la suddivisione del tuo lavoro in più blocchi rispetto ai thread. Il motivo è che thread diversi finiranno il lavoro in momenti diversi, e quindi vorresti un po 'di lavoro lasciato a disposizione per i thread più veloci. Altrimenti dovrai aspettare fino al termine dell'ultimo thread.

PS. "L'hyperthreading non può aiutare con il codice intensivo della FPU perché c'è solo una FPU". Assolutamente sbagliato È incredibilmente difficile, anche con il codice intensivo della FPU, sfruttare appieno la FPU a causa delle latenze. L'hyperthreading aiuta perché ci sono il doppio delle operazioni indipendenti disponibili per la pianificazione.

Non so come scriverlo in un modo che non suona "cattivo", quindi prendilo come commento amichevole, ok?

Dato che un PC medio ha già in genere migliaia o più thread, cosa ti fa pensare che usare 8 vs 7 farà alcuna differenza? : -)

Usa il maggior numero di thread possibile. E se non ti devi preoccupare della risposta del sistema operativo e i tuoi thread vengono eseguiti per un periodo di tempo molto lungo (più di un secondo), puoi persino sperimentare usando il doppio del numero di core.