[Rumor]Crysis e Xbox 360

La differenza fra hard disk e dischi ottici non è tanto nella velocità di lettura quanto nel tempo di seek (lì i dischi ottici fanno veramente onco).

Eppure il multithreading non è esattamente l'ideale per i videogiochi. E' risaputo che gli sviluppatori preferiscono lo streaming di un unico flusso di dati in quanto più adeguato alla struttura di un videogioco. Il vantaggio reale di un multicore si può avere soprattutto nella gestione della fisica. Basti vedere gli acceleratori fisici AGEIA che su pc non hanno avuto successo in quanto le cpu dual core riescono a sopperire tranquillamente. Crysis fa un uso massiccio di fisica e in questo le cpu di entrambe le console sono tranquillamente avvantaggiate. Il problema sarà ottimizzarle anche per la gestione di ambientazioni grafiche dal momento che se dovessero concentrarsi solo sulle gpu il titolo sarebbe notevolmente ridimensionato (soprattutto su PS3, dove RSX ha gli shader separati). In ogni caso non credo sia possibile fisicamente ottenere la resa delle DX10 dato che implementano i geometry shader che in Crysis ci sono seppur a livello embrionale. Non credo che sulle console siano possibili a livello di gpu.

Un paio di note.

Allora, introduciamo il concetto di "flusso esecutivo", in pratica un flusso esecutivo è un register file (cioè un set di registri) indipendente.
Ogni register file viene eseguito da un "entità" che è in genere chiamata (molto approssimativamente) "core".
S'è visto che tipicamente molte parti di un core non sono utilizzate nell'esecuzione di un singolo flusso esecutivo e per questo s'è sviluppata la tecnica del multithtreading simmetrico.
In pratica un core anzichè contenere un solo register file ne contiene più d'uno (in generale due), il processore ha al suo interno un elettronica che "destina" le varie componenti del core ad uno o all'altro flusso esecutivo a seconda della situazione.
Per migliorare la resa alcune unità all'interno del core sono sdoppiate cosicchè ogni flusso esecutivo ha la propria (ed anche perchè alcune parti del core sono sempre necessarie).
Statisticamente c'è un certo guadagno perchè "spesso" le parti del core utilizzate sono differenti e quindi è possibile eseguire più istruzioni in parallelo, tuttavia è anche vero che altre volte due istruzioni richiedono la stessa "parte" e quindi uno dei due flussi esecutivi viene "messo in pausa" per evitare un conflitto.
Oltre a questo c'è da dire che il core è sempre lo stesso, la gestione dei thread è problematica perchè in queste condizioni le cache tendono ad essere molto più sfruttate.
Per il concetto dato prima di multithreading è da dire anche che tutto funziona discretamente bene quando entrambi i flussi esecutivi condividono lo stesso spazio d'indirizzamento (cioè sono due thread dello stesso programma) mentre cominciano a sorgere molti problemi quando i due thread sono in esecuzione su programmi differenti (multitasking).

Il multitasking "vero e proprio" (quello "multicore") invece parte dal principio di avere più core, ogni core con un flusso esecutivo.
I vari core eseguono il loro codice indipendentemente dagli altri core; il "problema" nei multicore è spesso dovuto alla coerenza delle cache L1 (e L2 se parliamo di più core su più chip) e con i thread.

Facciamo un rapido esempio...
Se abbiamo due flussi esecutivi che operano su due aree completamente slegate l'una dall'altra il multithreading è meno indicato perchè permangono i limiti del multithreading ed i due flussi esecutivi continuano a "sporcarsi" vicendevolmente le cache, d'altro canto se abbiamo due flussi esecutivi che operano sulla stessa area il multithreading è più indicato perchè la cache è usata al meglio e non ci sono problemi di coerenza.

Vediamo le architetture...
Xenon ha tre core multithread, significa sei flussi esecutivi raggruppati in tre core, tutto con 1 Mbyte di cache L2 e tre blocchi "locali" di 32+32 Kbyte di L1.



La soluzione ottima per quest'architettura è avere tre processi (programmi) separati, ognuno con due (o più, schedulati) thread.
Questo perchè se un unico processo venisse eseguito su più thread in core diversi contemporaneamente si presenta il problema di coerenza delle cache... in pratica fate il caso che tre diversi thread operino contemporaneamente nelle stesse zone di memoria.
Il core '0' contiene due thread che leggono e scrivono queste locazioni; quando un thread sul core '1' vuol leggere/scrivere le stesse locazioni esse probabilmente si troveranno nella cache L1 del core '0', cosa che porterà l'elettronica della CPU a sincronizzare le due cache, a scapito delle prestazioni.

D'altro canto Cell usa un architettura diversa:
Qui la PPU è un unità dual thread con la sua cache L2 (da 512K).
Gli SPE "vedono" direttamente la loro local store (LS), ogni LS è 256K.
Gli SPE sono single thread e non hanno coerenza, ciò significa che se uno SPE prova ad accedere alla cella di memoria X accede alla cella di memoria X dall'XDR, e questo anche se il contenuto è presente anche su L1 o L2 nel PPE (magari "diverso").
Ne risulta che gli SPE non sono molto adatti al multithreading "parallelo" in quanto i singoli core non hanno coerenza.

Nel dettaglio a cosa ci porta tutto ciò ?
Semplicemente a dire che le due architetture sono molto diverse, in generale il problema della coerenza delle cache può generare errori sul Cell e rallentamenti su Xenon.
Questo rende le due architetture molto differenti e gli approcci da prendere molto diversi.