PDA

Visualizza la versione completa : Programmare su core distinti


XWolverineX
19-11-2008, 18:56
Da www.crysis.it



Questo varia a seconda del tipo di hardware su cui sa farà girare Crysis. In teoria fisica, suoni, sistemi particellari e la logica del gioco possono girare su separati core. In più il tempo speso nei driver grafici può essere scaricato su un altro core a parte, avendo un motore Direct3D molto ottimizzato.

Come hanno fatto?
Come fare a dire "questo lo fai sul core 1, questo lo fai sul core2 (sempre che c'è...)"
Con un semplice multithreading??

MItaly
19-11-2008, 21:32
Credo proprio di sì, eventualmente impostando l'affinity mask dei singoli thread in modo particolare (ma di solito basta il sistema operativo a fare un lavoro adeguato in questo senso).

oregon
19-11-2008, 21:40
Originariamente inviato da XWolverineX
Come fare a dire "questo lo fai sul core 1, questo lo fai sul core2 (sempre che c'è...)"


Non mi pare che lo dicano ... infatti affermano

in teoria ...

e si affidano alle

ottimizzazioni

delle librerie (e del sistema).

P.S. Al limite penso che si possa fissare l'affinity per la CPU, come da Task Manager, ma che lo si faccia per core ... non so, magari si deve cercare un po' di documentazione ...

P.P.S. Forse, la SetThreadAffinityMask funziona associando il thread al core considerandolo come una effettiva CPU ... domani faccio una prova, scrivendo un piccolo codice per un quad CPU - quad core ...

XWolverineX
19-11-2008, 23:04
Bhè fammi sapere, sarei proprio curioso anche io di capire qualcosa in piu'.
Sembra che sia uscito anche un libro apposito da poco: Multicore programming o qualcosa del genere, del 2008.
Chissà se ci sia scritto qualcosa in piu'

MItaly
19-11-2008, 23:07
Da quanto ne so le CPU multi-core vengono viste da Windows come più processori distinti: ho il ricordo distinto della impressionante scheda "Prestazioni" del task manager che ho visto smanettando su questa (http://h10010.www1.hp.com/wwpc/it/it/sm/WF06b/15351-15351-3328412-3328422-3328422-3454575-3547353.html) macchina nella configurazione 4 processori quad core :sbav: (nonché 16 GB di RAM).

Comunque si capisce il perché del libro che citi, visto che attualmente la velocità di clock dei processori sembra destinata a fermarsi, e per cui produttori stanno puntando sulla miniaturizzazione dei core per metterne tanti in un solo processore. A questo proposito dai un'occhiata a questo (http://www.gotw.ca/publications/concurrency-ddj.htm) articolo.

oregon
19-11-2008, 23:07
Beh ... ho fatto la prova utilizzando i processori "logici" visti dal multithreading e in effetti e' possibile indicare il numero del processore come se fosse effettivamente un processore vero e assegnare il thread in modo preciso. Credo proprio (non vedo perche' il contrario) che funzioni anche con i core.

Oltre alla SetThreadAffinityMask (che lavora con una maschera di bit) c'e' anche la piu' comoda SetThreadIdealProcessor.

MItaly
19-11-2008, 23:12
Ma in generale non è meglio lasciare al sistema operativo il lavoro di scegliere su che processore eseguire i vari thread? In che situazioni potrebbe convenire usare le affinity mask?

oregon
19-11-2008, 23:17
Originariamente inviato da MItaly
Da quanto ne so le CPU multi-core vengono viste da Windows come più processori distinti

Sì ... ne sono cosciente sin da quando fu introdotto l' hyperthreading, ma volevo provare che i core fossero effettivamente utilizzabili per l'affinita' o se, al contrario, per l'affinità viene considerato il socket ...


ho il ricordo distinto della impressionante ...

E' una delle 8 macchine che gestisco giornalmente (insieme a tante altre minori) ma con 64 GB di ram ... :) ... e su cui faro' la prova ...


Comunque si capisce il perché del libro ...

Stanno per arrivare i 12 core ...


Originariamente inviato da MItaly
Ma in generale non è meglio lasciare al sistema operativo il lavoro di scegliere su che processore eseguire i vari thread?

Ne sono convinto ... infatti, le funzioni di cui abbiamo parlato "tentano" di assegnare il thread al processore, ma "non e' detto" che lo facciano e la decisione finale e' del SO.


In che situazioni potrebbe convenire usare le affinity mask?

Mah ...

MItaly
19-11-2008, 23:35
Originariamente inviato da oregon
E' una delle 8 macchine che gestisco giornalmente (insieme a tante altre minori) ma con 64 GB di ram ... :) ... e su cui faro' la prova ...
Orco mondo, 64 GB di RAM... :oVVoVe:


Mah ...
In effetti anche Microsoft propone un unico esempio per le affinity mask:

Thread Affinity

Thread affinity forces a thread to run on a specific subset of processors.
[...]
Setting thread affinity should generally be avoided, because it can interfere with the scheduler's ability to schedule threads effectively across processors. This can decrease the performance gains produced by parallel processing. An appropriate use of thread affinity is testing each processor.

In tutto questo ho anche scoperto che la SetThreadAffinityMask differisce anche concettualmente dalla SetThreadIdealProcessor:


Thread Ideal Processor

When you specify a thread ideal processor, the scheduler runs the thread on the specified processor when possible. Use the SetThreadIdealProcessor function to specify a preferred processor for a thread. This does not guarantee that the ideal processor will be chosen, but provides a useful hint to the scheduler.
Quindi, in pratica: SetThreadAffinityMask=male; SetThreadIdealProcessor=accettabile, ma non se ne capisce neanche qui l'utilità; forse per evitare che uno stesso thread che deve lavorare a bassissima latenza sia sballottato da un processore all'altro (per evitare cache-miss), ma a questo dovrebbe già pensare lo scheduler... :master:

oregon
20-11-2008, 07:37
Originariamente inviato da MItaly
Orco mondo, 64 GB di RAM...

2008 64 bit con HyperV ... indovina per fare cosa ...


In effetti anche Microsoft ...

Indispensabile ... :madai!?:


... ma a questo dovrebbe già pensare lo scheduler...

Siamo al punto di prima ... :zizi:

Loading