Perché un programma richiederebbe un numero minimo specifico di core della CPU?

È possibile scrivere codice (o software completo, anziché un pezzo di codice) che non funzionerà correttamente se eseguito su una CPU che ha meno di N numero di core? Senza verificarlo esplicitamente e fallire di proposito:

SE (noOfCores <4) ALLORA non funziona correttamente di proposito

Sto osservando i requisiti minimi di sistema di un gioco ( Dragon Age: Inquisition ) e indica un minimo di una CPU a quattro core. Molti giocatori affermano che NON funziona su CPU a due core e ANCHE su Intel Core i3 con due core fisici e due logici. E NON è un problema di potenza di calcolo.

Da quanto ho capito, i thread sono completamente isolati dalla CPU dal sistema operativo poiché non è possibile farlo.

Giusto per chiarire le cose:

NON sto chiedendo "Posso scoprire il numero di core della CPU dal codice e fallire di proposito?" ... Tale codice sarebbe mal intenzionato (ti costringe ad acquistare una CPU più costosa per eseguire un programma - senza la necessità di potenza computazionale). Sto chiedendo che il tuo codice, ad esempio, abbia quattro thread e fallisca quando due thread vengono eseguiti sullo stesso core fisico (senza controllare esplicitamente le informazioni di sistema e volutamente fallire) .

In breve, può esistere un software che richiede più core, senza la necessità di ulteriore potenza di elaborazione proveniente da più core? Richiederebbe solo N nuclei fisici separati.

Potrebbe essere possibile farlo "per caso" con un uso incurante dell'affinità di base. Considera il seguente pseudocodice:

• inizia una discussione
• in quel thread, scopri su quale core è in esecuzione
• imposta la sua affinità CPU su quel core
• iniziare a fare qualcosa di intensivamente computazionale / loop per sempre

Se ne avvii quattro su una CPU a due core, allora qualcosa va storto con l'impostazione di affinità del core o finisci con due thread che registrano i core disponibili e due thread che non vengono mai programmati. Non ha mai chiesto esplicitamente quanti core ci sono in totale.

(Se si dispone di thread con esecuzione prolungata, l'impostazione dell'affinità della CPU generalmente migliora la velocità effettiva)

L'idea che le società di giochi "costringano" le persone ad acquistare hardware più costoso senza una buona ragione non è molto plausibile. Può solo perdere loro i clienti.

Modifica: questo post ha ora 33 voti positivi, il che è parecchio dato che si basa su congetture istruite!

Sembra che la gente abbia DA: I da eseguire, malamente, su sistemi dual-core: http://www.dsogaming.com/pc-performance-analyses/dragon-age-inquisition-pc-performance-analysis/ Quell'analisi afferma che la situazione migliora notevolmente se l'hyperthreading è attivato. Dato che HT non aggiunge più unità o cache di emissione di istruzioni, consente semplicemente l'esecuzione di un thread mentre un altro si trova in uno stallo della cache, il che suggerisce fortemente che è collegato esclusivamente al numero di thread.

Un altro poster afferma che la modifica dei driver grafici funziona: http://answers.ea.com/t5/Dragon-Age-Inquisition/Working-solution-for-Intel-dual-core-CPUs/td-p/3994141 ; dato che i driver grafici tendono ad essere un miserabile alveare di feccia e malvagità, questo non è sorprendente. Un noto set di driver aveva una modalità "corretta e lenta" rispetto a "veloce e errata" che era selezionata se chiamata da QUAKE.EXE. È del tutto possibile che i driver si comportino diversamente per diversi numeri di CPU apparenti. Forse (tornando alla speculazione) viene utilizzato un meccanismo di sincronizzazione diverso. Uso improprio di spinlock ?

"L'uso improprio di primitive di blocco e sincronizzazione" è una fonte molto comune di bug. (Il bug che dovrei guardare al lavoro mentre scrivo questo è "crash se la modifica delle impostazioni della stampante allo stesso tempo al termine del lavoro di stampa").

Modifica 2: i commenti menzionano il SO che tenta di evitare la fame di thread. Nota che il gioco potrebbe avere un proprio quasi-scheduler interno per assegnare lavoro ai thread e ci sarà un meccanismo simile nella stessa scheda grafica (che è effettivamente un sistema multitasking a sé stante). Le probabilità di un bug in uno di questi o l'interazione tra di loro sono piuttosto alte.

www.ecsl.cs.sunysb.edu/tr/ashok.pdf (2008) è una tesi di laurea su una migliore pianificazione per le schede grafiche che menziona esplicitamente che usano normalmente la pianificazione primo arrivato, che è facile da implementare in sistemi non preventivi. La situazione è migliorata? Probabilmente no.

Potrebbe essere necessario disporre di 4 core poiché l'applicazione esegue quattro attività in thread paralleli e si aspetta che finiscano quasi contemporaneamente.

Quando ogni thread viene eseguito da un core separato e tutti i thread hanno lo stesso carico di lavoro computazionale, è molto probabile (ma tutt'altro che garantito) terminare all'incirca allo stesso tempo. Ma quando due thread vengono eseguiti su un core, i tempi saranno molto meno prevedibili perché il core cambierà continuamente contesto tra i due thread.

I bug che si verificano a causa di tempi di thread imprevisti vengono definiti " condizioni di gara ".

Nel contesto dello sviluppo del gioco, un'architettura plausibile con questo tipo di problema potrebbe essere quella in cui diverse funzionalità del gioco sono simulate in tempo reale da diversi thread della CPU. Quando ciascuna funzione viene eseguita su un proprio core, vengono simulati all'incirca alla stessa velocità. Ma quando due funzioni girano su un core, entrambe saranno simulate solo la metà del resto del mondo di gioco, il che potrebbe causare comportamenti strani.

Si noti che un'architettura software che dipende da thread indipendenti in esecuzione con temporizzazioni specifiche è estremamente fragile e indica una pessima comprensione della programmazione concorrente. In quasi tutte le API multithreading sono disponibili funzionalità per sincronizzare esplicitamente i thread e prevenire questo tipo di problemi.

È improbabile che questi "requisiti minimi" rappresentino qualcosa al di sotto del quale il gioco non funzionerà. Molto più probabile è che rappresentino qualcosa al di sotto del quale il gioco non funzionerà con prestazioni accettabili. Nessuna società di gioco vuole trattare con molti clienti che si lamentano di prestazioni scadenti quando lo eseguono su una scatola single core da 1 Ghz, anche se il software potrebbe funzionare tecnicamente. Quindi probabilmente progettano deliberatamente di fallire duramente su scatole con meno core di quanto darebbe loro prestazioni accettabili.

Una metrica importante nelle prestazioni di gioco è la frequenza dei fotogrammi. In genere funzionano a 30 o 60 frame al secondo. Ciò significa che il motore di gioco deve eseguire il rendering della vista corrente dallo stato del gioco in un determinato periodo di tempo. Per ottenere 60 fps, ha solo poco più di 16 msec per farlo. I giochi con grafica di fascia alta sono estremamente legati alla CPU e quindi c'è un enorme vantaggio tra il tentativo di spingere una qualità superiore (che richiede più tempo) e la necessità di rimanere in questo budget di tempo. Pertanto, il budget di tempo per ciascun frame è estremamente limitato.

Poiché il budget di tempo è limitato, lo sviluppatore desidera idealmente l'accesso esclusivo a uno o più core. Probabilmente vogliono anche essere in grado di fare le loro cose di rendering in un core, esclusivamente, poiché è ciò che deve essere fatto con quel budget di tempo, mentre altre cose, come il calcolo dello stato mondiale, avvengono in un processo separato dove non lo faranno intromettersi.

Potresti, in teoria, stipare tutto questo su un unico core, ma poi tutto diventa molto più difficile. All'improvviso devi assicurarti che tutto ciò che riguarda lo stato del gioco avvenga abbastanza velocemente e permetta il rendering. Non puoi semplicemente farli due thread software perché non c'è modo di far capire al sistema operativo "il thread A deve completare X quantità di lavoro in 16 msec indipendentemente da quale thread B fa".

Gli sviluppatori di giochi non hanno interesse a farti acquistare nuovo hardware. Il motivo per cui hanno requisiti di sistema è che non vale la pena sostenere il costo del supporto di macchine di fascia bassa.

Tre thread in tempo reale che non dormono mai e un altro thread. Se sono presenti meno di quattro core, il quarto thread non verrà mai eseguito. Se il quarto thread deve comunicare con uno dei thread in tempo reale per il completamento del thread in tempo reale, il codice non terminerà con meno di quattro core.

Ovviamente se i thread in tempo reale sono in attesa di qualcosa che non consente loro di dormire (come uno spinlock), il progettista del programma ha rovinato tutto.

Innanzitutto i thread del software non hanno nulla a che fare con i thread dell'hardware e sono spesso confusi. I thread del software sono pezzi di codice che possono essere inviati ed eseguiti da soli nel contesto del processo. I thread hardware sono gestiti principalmente dal sistema operativo e vengono inviati al core del processore quando si parla di programmi regolari. Questi thread hardware vengono inviati in base al carico; il dispatcher di thread hardware si comporta più o meno come un bilanciamento del carico.

Tuttavia, quando si tratta di giochi, in particolare giochi di fascia alta, a volte i thread hardware sono gestiti dal gioco stesso o il gioco indica al dispatcher di thread hardware cosa fare. Questo perché ogni attività o gruppo di attività non ha la stessa priorità di un normale programma. Poiché l'età del drago proviene da uno studio di gioco di fascia alta che utilizza motori di gioco di fascia alta, posso immaginare che utilizzi la spedizione "manuale" e quindi il numero di core diventa un requisito di sistema minimo. Qualsiasi programma si arresterebbe in modo anomalo quando invio un pezzo di codice al terzo core fisico in esecuzione su una macchina con solo 1 o 2 core.

Dato che è possibile utilizzare la virtualizzazione per avere più core virtuali che fisici e il software non saprebbe che è in esecuzione su una virtualizzazione e invece penserebbe che abbia così tanti core fisici, direi che tale software non è possibile.

Vale a dire, non è possibile scrivere software che si fermerà sempre su meno di N core.

Come altri hanno sottolineato, ci sono soluzioni software che possono potenzialmente verificare, specialmente se il sistema operativo e il codice utilizzati hanno poca protezione dalle condizioni di competizione quando N processi sono eseguiti su processori <N. Il vero trucco è il codice che fallirà quando hai meno di N processori ma non fallirà quando hai N processori ma hai un sistema operativo che può assegnare lavoro a meno di N processori.

È possibile che ci siano tre thread che fanno qualcosa (generano sfondi o generano movimenti NPC) e passano gli eventi a un quarto, che dovrebbe aggregare / filtrare gli eventi e aggiornare il modello di vista. Se il quarto thread non ottiene tutti gli eventi (perché non è pianificato su un core), il modello di visualizzazione non viene aggiornato correttamente. Questo può accadere solo sporadicamente, ma quei core devono essere disponibili in qualsiasi momento. Questo potrebbe spiegare perché non si vede sempre un elevato utilizzo della CPU, ma il gioco non funziona comunque correttamente.

Penso che Joshua stia seguendo la strada giusta, ma non per giungere alla sua conclusione.

Supponiamo di avere un'architettura in cui ci sono tre thread che sono scritti per fare il più possibile - quando finiscono quello che stanno facendo lo fanno di nuovo. Per migliorare le prestazioni, questi thread non rilasciano il controllo per nulla: non vogliono rischiare il ritardo dall'utilità di pianificazione di Windows. Fintanto che ci sono 4 o più core, questo funziona bene, se non ci riesce fallisce male.

In generale, si tratterebbe di una cattiva programmazione, ma i giochi sono un'altra cosa: quando ti trovi di fronte a una scelta tra un design inferiore su tutto l'hardware o un design superiore su un hardware sufficientemente buono o un guasto su un hardware inferiore, gli sviluppatori di solito scelgono per richiedere l'hardware.

Is it possible to write code (or complete software, rather than a piece of code) that won't work properly when run on a CPU that has less than N number of cores?

Assolutamente. L'uso di thread in tempo reale sarebbe un buon esempio di una situazione in cui questo non è solo possibile, ma il modo desiderato (e spesso l'unico modo corretto) per portare a termine il lavoro. Tuttavia, i thread in tempo reale sono generalmente limitati al kernel del sistema operativo, in genere per i driver che devono essere in grado di garantire che un evento hardware di qualche tipo venga gestito entro un determinato periodo di tempo. Non dovresti avere thread in tempo reale nelle normali applicazioni utente e non sono sicuro che sia anche possibile averne uno in un'applicazione Windows in modalità utente. Generalmente, i sistemi operativi rendono intenzionalmente impossibile farlo dalla terra dell'utente proprio perché consente a una determinata applicazione di assumere il controllo del sistema.

Per quanto riguarda le applicazioni utente-terra: il tuo presupposto che il controllo di un determinato numero di thread per essere eseguito sia necessariamente intenzionale non è corretto. Ad esempio, potresti avere 2 attività di lunga durata, che richiedono prestazioni elevate e che richiedono un core. Indipendentemente dalla velocità del core della CPU, la condivisione di un core con altri thread potrebbe essere un peggioramento delle prestazioni grave e inaccettabile a causa del thrashing della cache e delle normali penalità dovute al cambio di thread (che sono piuttosto sostanziali). In questo caso, sarebbe perfettamente ragionevole, specialmente per un gioco, impostare ciascuno di questi thread in modo che abbia un'affinità solo su un core particolare per ciascuno di essi e quindi impostare tutti gli altri thread in modo che non abbiano affinità su quei 2 core. Per fare ciò, però,

Qualsiasi codice che utilizza spinlock con una notevole quantità di contesa di lock funzionerà terribilmente (nella misura in cui - per un'applicazione come un gioco - puoi dire "non funziona" ) se il numero di thread supera il numero di core.

Immagina ad esempio un thread del produttore che invia attività a una coda che serve 4 thread consumer. Esistono solo due core:

Il produttore cerca di ottenere lo spinlock, ma è trattenuto da un consumatore che gira sull'altro core. I due core eseguono la sequenza di blocchi mentre il produttore gira, in attesa di rilasciare il blocco. Questo è già negativo, ma non così grave.
Sfortunatamente, il thread del consumatore è alla fine del suo tempo quantico, quindi è anticipato e viene pianificato un altro thread del consumatore. Cerca di afferrare il lucchetto, ma ovviamente il lucchetto viene preso, quindi ora due nuclei ruotano e aspettano qualcosa che non può accadere.
Il thread del produttore raggiunge la fine della sua fascia oraria ed è anticipato, un altro consumatore si sveglia. Ancora una volta, due consumatori stanno aspettando il rilascio di un blocco, e non accadrà prima che siano trascorsi altri due quanti quantum.
[...] Finalmente il consumatore che aveva in mano lo spinlock ha rilasciato il blocco. Viene immediatamente preso da chiunque gira sull'altro nucleo. C'è una probabilità del 75% (da 3 a 1) che si tratti di un altro thread di consumo. In altre parole, è probabile che il 75% del produttore sia ancora bloccato. Naturalmente questo significa che anche i consumatori si fermano. Senza il produttore che sopporta compiti, non hanno nulla da fare.

Si noti che questo funziona in linea di principio con qualsiasi tipo di blocco, non solo con gli spinlock, ma l'effetto devastante è molto più evidente con gli spinlock perché la CPU continua a bruciare i cicli mentre non ottiene nulla.

Ora immagina che oltre a quanto sopra alcuni programmatori abbiano avuto la brillante idea di usare un thread dedicato con affinità impostata sul primo core, quindi RDTSC darà risultati affidabili su tutti i processori (non lo farà comunque, ma alcune persone lo pensano).

Se capisco cosa stai chiedendo, è possibile, ma è una cosa molto, molto brutta.

L'esempio canonico di ciò che stai descrivendo sarebbe il mantenimento di un contatore che viene incrementato da più thread. Ciò non richiede quasi nulla in termini di potenza di calcolo, ma richiede un attento coordinamento tra i thread. Finché un solo thread alla volta esegue un incremento (che in realtà è una lettura seguita da un'aggiunta seguita da una scrittura), il suo valore sarà sempre corretto. Questo perché un thread leggerà sempre il valore "precedente" corretto, ne aggiungerà uno e scriverà il valore "successivo" corretto. Ottieni due thread nell'azione contemporaneamente ed entrambi leggono lo stesso valore "precedente", ottengono lo stesso risultato dall'incremento e scrivono lo stesso valore "successivo". Il contatore sarà effettivamente aumentato solo una volta, anche se due thread pensano di averlo fatto ciascuno.

Questa dipendenza tra tempismo e correttezza è ciò che l'informatica chiama una condizione di razza .

Le condizioni di gara vengono spesso evitate utilizzando i meccanismi di sincronizzazione per assicurarsi che i thread che desiderano operare su una parte di dati condivisi debbano mettersi in fila per l'accesso. Il contatore sopra descritto potrebbe usare un blocco lettura-scrittura per questo.

Senza accesso al design interno di Dragon Age: Inquisition , tutto ciò che chiunque può fare è speculare sul perché si comporti in questo modo. Ma proverò sulla base di alcune cose che ho visto fare nella mia esperienza:

È possibile che il programma si basi su quattro thread che sono stati sintonizzati in modo che tutto funzioni quando i thread vengono eseguiti per lo più ininterrottamente sui propri core fisici. La "messa a punto" potrebbe presentarsi sotto forma di riorganizzazione del codice o inserimento di sleep in luoghi strategici per mitigare i bug indotti dalle condizioni di gara che sono emersi durante lo sviluppo. Ancora una volta, questa è tutta una congettura, ma ho visto le condizioni di gara "risolte" in quel modo più volte di quanto mi importi.

L'esecuzione di un programma in questo modo su qualcosa di meno capace rispetto all'ambiente per il quale è stato messo a punto introduce cambiamenti di temporizzazione che sono il risultato del fatto che il codice non viene eseguito più rapidamente o, più probabilmente, dei cambi di contesto. I cambi di contesto avvengono in modo fisico (ovvero i nuclei fisici della CPU stanno cambiando tra il lavoro svolto dai suoi core logici) e logici (ovvero, il sistema operativo sulla CPU sta assegnando lavoro ai core), ma l'una o l'altra è una significativa divergenza rispetto a ciò sarebbe il tempismo di esecuzione "previsto". Ciò può far emergere comportamenti scorretti.

Se Dragon Age: Inquisition non fa il semplice passo per assicurarsi che ci siano abbastanza nuclei fisici disponibili prima di procedere, è colpa di EA. Probabilmente stanno spendendo una piccola fortuna mettendo in campo le chiamate di supporto e le e-mail da parte di persone che hanno cercato di eseguire il gioco su hardware troppo piccolo.

Windows ha funzionalità integrate per questo: la funzione GetLogicalProcessorInformation è nell'API di Windows . Puoi chiamarlo dal tuo programma per ottenere informazioni su core, core virtuali e hyperthreading.

Quindi la risposta alla tua domanda sarebbe: Sì.