Itanium 2 Montecito: livelli record in virgola mobile

[fantoibed]

Originariamente inviato da DioBrando

cioè stai dicendo che n vi sn condizioni in cui sia possibile una situazione di stallo negli Itanium?

Non può esserci "stallo per errata predizione", visto che non c'è predizione, come non può ingolfarsi il carburatore in un'auto a iniezione visto che il carburatore non c'è l'ha.

...O meglio, la "predizione" (statica, però, e demandata al compilatore e non alla CPU) esiste negli Itanium per il programmatore che decide di non avvalersi della predicazione, solo in quel caso puoi avere stallo.
Secondo me, però, sarebbe come comprare una Ferrari e metterci l'impianto a GPL. L'Itanium è fatto per sfruttare il parallellismo a livello di istruzioni (ILP) attraverso la predicazione. Scegliere di utilizzare i salti condizionati invece dei predicati equivale a scegliere di far andar piano i programmi.

[cdimauro]

Originariamente inviato da DioBrando

cioè stai dicendo che n vi sn condizioni in cui sia possibile una situazione di stallo negli Itanium?

Ovviamente sì, e dipendono da diversi fattori, fra quelli da elencati prima quando parlavo in generale di processori in-order, e a cui neppure Itanium può sottrarsi (anzi).

x Cecco BS: di niente.

[fantoibed]

Originariamente inviato da cdimauro

Ovviamente sì, e dipendono da diversi fattori, fra quelli da elencati prima quando parlavo in generale di processori in-order, e a cui neppure Itanium può sottrarsi (anzi).

Nella ignore list deve aver messo anche la predicazione. Non parlarne e far finta che non esista sembra l'unico modo per sostenere questa tesi...

[bjt2]

La predicazione è geniale... se non fosse che c'è spreco di risorse. Mi spiego meglio: ci sono unità che fanno dei calcoli che poi verranno buttati. Sarebbe stato carino avere qualche modalità del processore in cui farlo funzionare come il Niagara della SUN: 2 o più thread che si contendono le risorse. Non essendo OOO, capiterà spesso che delle unità sono libere e possono essere assegnate ad un altro thread. Considerando poi la quantità spropositata di cache che hanno... Anche per questo consumano tanta potenza: ci sono tanti calcolo fatti inutilmente. Se una pipeline stalla, non consuma potenza. Se una pipeline fa calcoli (inutili) si.

[fantoibed]

Lo spreco di risorse c'è ma è relativo: una pipeline che fa calcoli in più è sprecata tanto quanto una pipeline che non fa' calcoli. Sicuramente una che non fa' calcoli non consuma corrente, ma bisogna tener presente che nelle CPU OOO, l'unità di branch prediction consuma comunque un fottio di corrente ed è sempre attiva.
...E poi le CPU pensate per il calcolo parallelo con molte pipeline non hanno il problema di occupare una pipeline in più per quei pochi cicli che intercorrono tra quando si iniziano a riempire le pipeline stesse e quando il predicato viene processato effettivamente...
Con la tecnologia degli sleep transistors dinamici che verrà introdotta nel processo a 65nm, poi, ci sarà la possibilità di attivare o disattivare risorse inutilizzate (del core e della cache) con una notevole riduzione del leakage. Su una CPU OOO, il branch predictor deve restare comunque sempre attivo e non può essere mai disabilitato per poter ridurre il leakage.

[Cecco BS]

stavo per fare la stessa obiezione di bjt2, ma fantoibed ha ribattuto dissipando tutti i miei dubbi!

[bjt2]

Ha ragione fantoibed... ma io non criticavo lo spreco di risorse, ma la mancanza di una modalità Niagara-Like. Mi spiego meglio: se voglio un mostro di calcolo parallelo, prendo un Itanium (2). Se voglio un sistema che possa gestire bene molti thread, devo per forza aumentare le CPU. Si poteva, senza complicare troppo la CPU, adottare un'altra modalità operativa come quella Niagara (visto che la logica OOO non c'è), avendo un ultra hyper threading (riflettendoci mi pare che gli itanium 2 ce l'abbiano, ma non ne sono sicuro...), magari a 4 o più thread, vista la cache ed il numero di unità di calcolo presenti in quella CPU...

[DioBrando]

Originariamente inviato da fantoibed

Non può esserci "stallo per errata predizione", visto che non c'è predizione, come non può ingolfarsi il carburatore in un'auto a iniezione visto che il carburatore non c'è l'ha.

Io non ho parlato di stallo per errate predizione, ho detto semplicemente stallo.

...O meglio, la "predizione" (statica, però, e demandata al compilatore e non alla CPU) esiste negli Itanium per il programmatore che decide di non avvalersi della predicazione, solo in quel caso puoi avere stallo.
Secondo me, però, sarebbe come comprare una Ferrari e metterci l'impianto a GPL. L'Itanium è fatto per sfruttare il parallellismo a livello di istruzioni (ILP) attraverso la predicazione. Scegliere di utilizzare i salti condizionati invece dei predicati equivale a scegliere di far andar piano i programmi.

La predicazione non risolve tutte le possibili situazioni in cui uno stallo può verificarsi, ad es. perchè il codice per quanto il compilatore possa ottimizzare il codice per l'architettura EPIC, non riuscirà mai a "parallalelizzarlo" completamente.

[Cecco BS]

a quanto ne so la difficoltà maggiore da questo punto di vista sta nel progettare compilatori che riescano a rendere il codice il più possibile parallelizzabile esplicitamente, no?

[DioBrando]

Originariamente inviato da Cecco BS

a quanto ne so la difficoltà maggiore da questo punto di vista sta nel progettare compilatori che riescano a rendere il codice il più possibile parallelizzabile esplicitamente, no?

stanno nel fatto che un compilatore per quanto efficiente non può risolvere tutte le situazioni che si presentano.
Il codice è una sequenza di istruzioni e ci saranno casi in cui, compilatore + o - affinato, un'istruzione non potrà essere eseguita in parallelo perchè l'istruzione successiva ad es. è collegata alla precedente.
Esempio stupido:

nel mio programma mi trovo ad un certo punto a dover sommare la variabile1 alla variabile 2. Subito dopo il risultato dell'addizione dovrà essere sommato alla variabile 3.

Come faccio ad eseguire in parallelo le due istruzioni?
Non posso.

Non solo...accade n così di rado che siano i programmatori stessi a dover rivedere il codice di un programma ( ad es portandolo da una piattaforma x86 all'IA-64) perchè la macchina non può arrivare ad un certo risultato, richiesto per poter beneficiare il + possibile dell'architettura EPIC.

Queste operazioni in termini di tempo possono essere costose e tempo = denaro

[cdimauro]

Originariamente inviato da bjt2

La predicazione è geniale... se non fosse che c'è spreco di risorse.

Sarà geniale, ma alla fine si è rivelata poco adatta rispetto alla realtà, a come funziona il codice nelle applicazioni che usiamo tutti i giorni.

Predicazione e predizione alla fine sono due strumenti che nascono per risolvere lo stesso problema, anche se in maniera completamente diversa: quello di gestire le condizioni che portano o posso portare a un cambiamento nel flusso del codice.

Mi spiego meglio: ci sono unità che fanno dei calcoli che poi verranno buttati. Sarebbe stato carino avere qualche modalità del processore in cui farlo funzionare come il Niagara della SUN: 2 o più thread che si contendono le risorse. Non essendo OOO, capiterà spesso che delle unità sono libere e possono essere assegnate ad un altro thread.

Non penso che sia fattibile: proprio per la natura stessa della predicazione, quelle istruzioni DEVONO essere eseguite, e quindi impegneranno sempre e comunque quelle risorse. Quando il processore si vede costretto ad eseguire il rollback di un'istruzione la cui predicazione non è andata a buon fine, sarà comunque troppo tardi: il lavoro è già stato fatto, le risorse impegnate, usate e rilasciate.

Il discorso di Niagara è diverso, è simile a quanto avviene nel P4 con l'HT e nel Power5, ed è quel che Intel dovrebbe fare con le prossime versioni di Itanium, per utilizzare le risorse rimaste libere (perché non usate, o perché un thread è fermo a causa di uno stallo, e quindi è costretto a non usarle).
C'è da dire che, anche se sulla carta ha buone possibilità grazie alla presenza di numerose unità di esecuzione, il compito non è affatto semplice, a causa dei vincoli dell'architettura EPIC: le risorse devono essere impegnate in toto per portare a termine un intero bundle, e non qualcuna delle sue istruzioni.
Un processore con logica ooo è molto più facilitato in questo, perché può organizzare le istruzioni come vuole, e usare al meglio le risorse disponibili in quel preciso momento. "Posso eseguire 3 istruzioni liberamente, mi serve un load, una moltiplicazione intera e una somma FP, ma ho disponibile soltanto un'AGU e un sommatore FP: ne eseguo due, e per l'altra ci penso dopo".

Considerando poi la quantità spropositata di cache che hanno... Anche per questo consumano tanta potenza: ci sono tanti calcolo fatti inutilmente. Se una pipeline stalla, non consuma potenza. Se una pipeline fa calcoli (inutili) si.

Indubbiamente, e per fortuna la cache non consuma molta potenza (soltanto spazio, prezioso, su chip).

[cdimauro]

Originariamente inviato da bjt2

Ha ragione fantoibed... ma io non criticavo lo spreco di risorse, ma la mancanza di una modalità Niagara-Like. Mi spiego meglio: se voglio un mostro di calcolo parallelo, prendo un Itanium (2). Se voglio un sistema che possa gestire bene molti thread, devo per forza aumentare le CPU. Si poteva, senza complicare troppo la CPU, adottare un'altra modalità operativa come quella Niagara (visto che la logica OOO non c'è), avendo un ultra hyper threading (riflettendoci mi pare che gli itanium 2 ce l'abbiano, ma non ne sono sicuro...), magari a 4 o più thread, vista la cache ed il numero di unità di calcolo presenti in quella CPU...

Per essere precisi, l'approccio di Intel con Itanium è simile a quello di Niagara, dove la CPU cambia thread di esecuzione di fronte a uno stallo. Quindi è un approccio un po' diverso e meno efficiente di quello adottatato per il P4 o da IBM col Power5, dove i thread presenti si contendono le risorse (il Power5 ha una logica molto fine per farlo, e addirittura il s.o. può controllarne alcuni aspetti).

Francamente non ricordo se Intel ha già adottato il CMP con qualche versione di Itanium 2, o lo farà in un prossimo futuro.

[cdimauro]

Originariamente inviato da DioBrando

Io non ho parlato di stallo per errate predizione, ho detto semplicemente stallo.

Esatto: le cause sono molteplici.

La predicazione non risolve tutte le possibili situazioni in cui uno stallo può verificarsi, ad es. perchè il codice per quanto il compilatore possa ottimizzare il codice per l'architettura EPIC, non riuscirà mai a "parallalelizzarlo" completamente.

Esattamente. E comunque, anche se riesce a fare un buon lavoro, di fronte a certe situazione tutt'altro che rare, è l'architettura stessa dell'Itanium a fare da freno.

Ad esempio, con un codice "poco diffuso" come questo:

for i := 1 to n do
  [...]

alla fine di ogni ciclo la CPU sbaglierà la predizione n - 1 volte, e sarà costretta a svuotare e riempire la pipeline a causa del salto all'inizio del ciclo. Soltanto all'n-esimo ciclo continuerà l'esecuzione senza intoppi.
In questo contesto è evidente l'efficienza di un processore ooo: il salto verrà predetto correttamente n - 1 volte, e soltanto l'ultima fallirà.

Il compilatore può aiutare Itanium, mitigando la penalizzazione dovuta ai salti, effettuando loop unrolling, ma fino a un certo punto: anche la dimensione del codice è un fattore importante, per cui sarà costretto a trovare una soluzione di compromesso fra il numero di cicli da eseguire e lo spazio occupato.
Considerato che i bundle di Itanium sono costituiti da 128 bit (sono ben 16 byte), e che contengono al più 3 istruzioni "utili" (anche sui bundle ci sono parecchi vincoli: non si possono inserire arbitrariamente le istruzioni, come avviene con la maggior parte delle architetture VLIW), è facile che lo srotolamento dei cicli porti a un eccessivo consumo di memoria. Consumo di memoria -> banda consumata per caricare il codice in cache.

Anche le rose più belle hanno pur sempre le spine...

[cdimauro]

Dimenticavo: processori ooo moderni, come gli x86, che non usano il raffinato sistema di predicazione di Itanium, hanno comunque delle migliorie architetturali che aiutano molto nei casi più comuni.

Ad esempio, il vecchio PentiumPro ha introdotto le istruzioni CMOV e FCMOV, che consentono di eseguire o saltare l'istruzioni di spostamento di un registro, a seconda del verificarsi di una precisa condizione.

Inoltre con le SSE2 Intel ha introdotto anche due speciali prefissi per le istruzioni di salto, che "suggeriscono" alla logica di branch prediction se quel salto è più o meno soggetto ad essere eseguito.

Piccole migliorie, che costano poco, ma che permettono di risolvere in maniera efficace certi problemi comuni, anche se non eleganti come la soluzione di Itanium... Ma alla fine contano le prestazioni, non l'eleganza di un'architettura...

[fantoibed]

Originariamente inviato da cdimauro

Ad esempio, con un codice "poco diffuso" come questo:

for i := 1 to n do
  [...]

alla fine di ogni ciclo la CPU sbaglierà la predizione n - 1 volte, e sarà costretta a svuotare e riempire la pipeline a causa del salto all'inizio del ciclo. Soltanto all'n-esimo ciclo continuerà l'esecuzione senza intoppi.
In questo contesto è evidente l'efficienza di un processore ooo: il salto verrà predetto correttamente n - 1 volte, e soltanto l'ultima fallirà.

Nemmeno il compilatore che trovi nel Dixan non produrrebbe un codice dal comportamento simile. Esistono predicati fatti ad hoc per i cicli for e while:
br.cloop, br.ctop e br.cexit per i cicli for e br.wtop e br.wexit per i cicli while.

...E poi esistono delle istruzioni che permettono di effettuare predizione statica e dinamica (solo che devono essere inserite nel codice dal compilatore): spnt, sptk, dpnt e dptk.
...Poi ci sono i prefetch hints ed i predictor deallocation hints.

La pipeline dell'Itanium, inoltre, ha solo 8 stadi (con un instruction buffer inserito tra i primi 2 stadi di front-end e gli ultimi 6 di back-end) quindi soffre poco lo stallo anche per quello...