[Thread Ufficiale] Aspettando ZEN

[Ren]

Originariamente inviato da tuttodigitale

mi stava venendo un colpo, quando ho letto che c'era una fase di pre-decodifica, assente anche in Jaguar, figuriamoci se poteva esserci in un'architettura in RISC poi ho letto che era Haswell.

Insomma, le similutidini sono molte, sembra di vedere Sandy Bridge...è identico

Quasi da denuncia...(si fa per dire)

cmq 3ghz di clock su design Custom 16FF+ (per ora di più nin zo )

Manca solo il qualcomm Hydra con il Kryo pompato.

[cdimauro]

Originariamente inviato da bjt2

Ma infatti io ho parlato di consumo della sola FPU ed ho moltiplicato per 4 in altri miei post il consumo della FPU per stimare il consumo del core...

Sì, lo so: ne abbiamo già parlato. Ma già ci sono parecchi dubbi sull'uso dell'FPU Neon, e qui IMO è ancora peggio, visto che quel sistema ha un'FPU molto più semplice perfino di Neon.

La verità è che ci sono tante incognite... Dalle misure ad occhio sulle foto del die di Zen, si è stimato da 150 a 250mmq il die di 8 Zen. Come vedi è una forbice piuttosto ampia. Siccome sappiamo che l'IPC ST è +40% e quello MT dovrebbe essere pari o poco superiore, si è supposto che in AMD non sappiano fare miracoli e che quindi il numero di transistors di un core Zen sia pari a quello di un modulo XV... Ma la L2 è inferiore e mancano 2 AGU e, forse, 4 decoder... Quindi il dubbio viene...

Beh, i transistor sono utilizzati in maniera diversa. E' vero che XV ha una cache L2 molto più grandi e 4+4 decoder, però Zen ha pure 4 porte per operazioni FP a 128 bit, mentre XV ne ha solo 2 di questo tipo.

Quanto alle dimensioni, dovrebbe essere possibile ricavare l'area di un modulo XV e quella di un core Zen e fare le dovute proporzioni. In genere lo fanno siti come Chip Architect.

Ma non parlavo delle unità singole attaccate alle porte, ovviamente, ma alle singole porte. XV ne ha 2+2ALU, 2+2AGU e 4FPU. Considerando che ha 8 decoder e che una MOP può anche avere una uop ALU+AGU, è possibile scrivere un powerhog virus con sole istruzioni registro-registro con throughput 1...

Se con una uop riesci a impegnare sia un'ALU sia un'AGU, allora sì: con 8 uop riesci a usare tutte le porte.

A quanto ho capito, CPU e GPU sono paritarie. E' come se la GPU fosse una grossa CPU SMT che accetta n thread (con n dipendente dalla GPU) che possono accedere liberamente alla memoria, anche virtuale, e quindi, a parte la diversa ISA, possono comunicare con i processi GPU e CPU con le normali funzioni per l'IPC... Paritarie nel senso che processi CPU e GPU possono creare e comunicare con altri processi CPU e GPU... Non conosco i dettagli, ma sembra interessante...

Sì, questo mi era chiaro. Il punto è che senza conoscere la latenza dell'offloading, non puoi sapere se sia conveniente o meno smistare un'operazione alla GPU o fargli fare il lavoro alla CPU.

Ultimamente si usano molto la sintetizzazione... Ricordo vagamente le lezioni sulla minimizzazione delle porte logiche per una data funzione... Il mux sarà implementato con il minimo delle porte (ad esempio un mux a 6 vie avrà meno porte di uno 8 vie anche se ha sempre 3 bit), ma penso ci voglia sempre un mux...

Io credo che se ne possa fare a meno.

Preciso che, però, non so come Intel abbia implementato il tutto nei suoi processori.

Perchè mischiare int e fp porta problemi nell'SMT

Non vedo perché: alla fine è compito dello scheduler smistare opportunamente le operazioni alle giuste porte, tenendo conto delle priorità che ho esposto prima.

Lo so... Ma sul codice legacy vedi che Zen (e anche BD) possono avere un vantaggio...

Tu stesso hai riportato prima un IPC di 2,4 nell'uso di codice floating point intensivo. Non di sole FADD/FMUL/FMAC/FMA vive l'FPU, ma anche di FMOV, FLOAD, FSTORE, ecc... e persino istruzioni "intere".

Detto in altri termini, è difficile impegnare tutte e 4 le porte FP a 128 bit allo stesso momento.

Io spero che siano di più... AMD ha già avuto esperienza con il primo BD di soli 4 decoder per 2 thread, senza cache L0...

Anche i precedenti processori Intel facevano lo stesso, ma facendo uso dell'LSD (non quello che pensi ).

O la cache L0 è in grado di sparare 8 mops per ciclo, oppure ci vogliono 8 decoder per sperare di eguagliare XV in MT...

Mi sembrano numeri troppo elevati, e poi funzionerebbe soltanto nei cicli, per l'appunto.

Ricordo che il P4 aveva pochi decoder (2 mi pare) affidandosi alla cache L0...

Non so se erano 2, ma il P4 non aveva alcuna cache codice L1: tutte le istruzioni venivano decodificate e memorizzate nella trace cache (tipo cache L0), ed è stato proprio questa la causa dei suoi problemi di prestazioni (oltre alla microscopica cache L1 dati).

E' ovvio che le 4+2+4 unità di Zen non saranno simmetriche... Ma più porte mi fanno sperare per meno vincoli e più potenziale IPC...

Sulla carta. Però ricorda sempre che stiamo parlando di processori out-of-order, ed è per questo che in un altro commento dicevo che un processore con meno porte potrebbe benissimo avere prestazioni simili a uno che ne ha di più.

La realtà è che le porte vengono selezionate dinamicamente in base al codice eseguito, e se una porta è impegnata per un'operazione, non si ferma tutta la macchina: se ne possono sfruttare altre nel frattempo. Quando sarà libera, verrà utilizzata dall'istruzione in attesa. E così via.

Potenza dell'esecuzione OoO.

[tuttodigitale]

Originariamente inviato da Ren

Quasi da denuncia...(si fa per dire)

cmq 3ghz di clock su design Custom 16FF+ (per ora di più nin zo )

Manca solo il qualcomm Hydra con il Kryo pompato.

è da denuncia si....dicono che sarà la CPU ARM più veloce del mondo....quando lo sanno anche i sassi che è il fratello maggiore di ZEN

[tuttodigitale]

Originariamente inviato da Ren

Bene, sono arrivati al 15%, ma non dicono nulla delle librerie. Rimangono sul generico. Conoscendo i reparti marketing, si parla di sicuro del migliori dei casi...

Se non ricordo male adesso hanno un CPP molto simile al TSMC16. (peccato, ma fa niente)

non dicono niente, ma pubblicizzano un SoC da smartphone. Poi mi pare difficile che oltre ad omettere il minor livello di integrazione rincarano la dose, facendo pensare che questa sia pure migliorata...poi si parla anche di minor consumi....e le librerie a più alte prestazioni sono penalizzanti da questo punto di vista.

Poi stiamo parlando dei partner di coloro che avevano detto fino al +50% di clock a parità di TDP, per i 32nm...

[Ren]

Originariamente inviato da tuttodigitale

non dicono niente, ma pubblicizzano un SoC da smartphone. Poi mi pare difficile che oltre ad omettere il minor livello di integrazione rincarano la dose, facendo pensare che questa sia pure migliorata...poi si parla anche di minor consumi....e le librerie a più alte prestazioni sono penalizzanti da questo punto di vista.

Poi stiamo parlando dei partner di coloro che avevano detto fino al +50% di clock a parità di TDP, per i 32nm...

Fidati poco dei proclami markettari, possono infinocchiarci come gli pare. (margine di variabili "illimitato").

Voglio vedere cammello, non numerini e buone intenzioni ...

Su carta il TSMC16 era peggio del 14LPE.

[tuttodigitale]

Originariamente inviato da cdimauro

Quanto alle dimensioni, dovrebbe essere possibile ricavare l'area di un modulo XV e quella di un core Zen e fare le dovute proporzioni. In genere lo fanno siti come Chip Architect.

lo abbiamo fatto su questo sito...purtroppo ci manca un dato fondamentale il livello di integrazione della L2...se ipotizziamo il 70%, come Polaris, sono 250mmq.

Originariamente inviato da cdimauro

Se con una uop riesci a impegnare sia un'ALU sia un'AGU, allora sì: con 8 uop riesci a usare tutte le porte.

in teoria da un MOP possono uscire fino a 3uop...tuttavia è raro che questo avvenga.


Vi presento ZEN:

scherzo.

Originariamente inviato da cdimauro

La realtà è che le porte vengono selezionate dinamicamente in base al codice eseguito, e se una porta è impegnata per un'operazione, non si ferma tutta la macchina: se ne possono sfruttare altre nel frattempo. Quando sarà libera, verrà utilizzata dall'istruzione in attesa. E così via.

Potenza dell'esecuzione OoO.

ecco che il limite delle 2 ALU in XV non sembra così opprimente

[Ren]

Originariamente inviato da tuttodigitale

Vi presento ZEN:

scherzo.

Secondo le teorie Desdenboy aggiungerei

Cyclone la clonazione.

[bjt2]

Originariamente inviato da cdimauro

Sì, lo so: ne abbiamo già parlato. Ma già ci sono parecchi dubbi sull'uso dell'FPU Neon, e qui IMO è ancora peggio, visto che quel sistema ha un'FPU molto più semplice perfino di Neon.

Beh, semplice o no, se raddoppiamo la mia stima, abbiamo il consumo di 4 pipeline a 128 bit che è il caso peggiore che potrebbe mai incontrare la FPU Zen (powerhog virus di 4 FMAC)

Originariamente inviato da cdimauro

Beh, i transistor sono utilizzati in maniera diversa. E' vero che XV ha una cache L2 molto più grandi e 4+4 decoder, però Zen ha pure 4 porte per operazioni FP a 128 bit, mentre XV ne ha solo 2 di questo tipo.

Se non mi sbaglio le altre 2 porte della FPU di BD/XV possono fare le istruzioni SSE intere, che comprendono comunque moltiplicazione e divisione... Quindi non è che le altre 2 pipeline occupino poi molto meno spazio...

Originariamente inviato da cdimauro

Quanto alle dimensioni, dovrebbe essere possibile ricavare l'area di un modulo XV e quella di un core Zen e fare le dovute proporzioni. In genere lo fanno siti come Chip Architect.

E lo hanno fatto... I numeri che ho dato sono così vaghi perchè non ci sono notizie su quanto possa occupare la L3 e quindi fare le proporzioni...

Originariamente inviato da cdimauro

Se con una uop riesci a impegnare sia un'ALU sia un'AGU, allora sì: con 8 uop riesci a usare tutte le porte.

Potenza delle MOP AMD... Una MOP AMD può contenere fino a 3 uops!
ALU+AGU+MEM (!!!) Infatti molte istruzioni, anche reg+mem/reg sono implementate con una MOP e sono fastpath single... I decoder AMD sono di una VIULEEEENZA impressionante...

Originariamente inviato da cdimauro

Sì, questo mi era chiaro. Il punto è che senza conoscere la latenza dell'offloading, non puoi sapere se sia conveniente o meno smistare un'operazione alla GPU o fargli fare il lavoro alla CPU.

Beh, immagino che qualunque scomposizione in thread debba tenere conto della granularità del parallelismo e della latenza di creazione thread... Sappiamo che su windows, rispetto a linux creare processi è una tragedia greca! Meglio i thread... Eppure a occhio sembra che Windows 10 è migliorato: quando avevo windows 7 e ricaricavo 40 schede su chrome, con una estensione che si chama "reload all", il PC (mouse compreso) scattava e quasi si impiantava per qualche secondo mentre i 40 processi venivano creati... Ora con windows 10 la situazione è molto migliorata...

Originariamente inviato da cdimauro

Io credo che se ne possa fare a meno.

Preciso che, però, non so come Intel abbia implementato il tutto nei suoi processori.

Immagino... Ah, quanto vorrei aver fatto architettura dei sistemi integrati all'università... Ma non era nel mio piano statutario tra gli esami ammissibili senza doversi far approvare il piano...

Originariamente inviato da cdimauro

Non vedo perché: alla fine è compito dello scheduler smistare opportunamente le operazioni alle giuste porte, tenendo conto delle priorità che ho esposto prima.

Hai ragione: a parità di porte la soluzione di INTEL è meglio, ma ovviamente su INTEL sono 4 totali, contro 4+4, quindi, a meno di disastri di AMD nello scheduler, l'efficienza dell'SMT dovrebbe essere superiore...

Originariamente inviato da cdimauro

Tu stesso hai riportato prima un IPC di 2,4 nell'uso di codice floating point intensivo. Non di sole FADD/FMUL/FMAC/FMA vive l'FPU, ma anche di FMOV, FLOAD, FSTORE, ecc... e persino istruzioni "intere".

Detto in altri termini, è difficile impegnare tutte e 4 le porte FP a 128 bit allo stesso momento.

Non con 2 thread... Immagina un processo FP intensive con un IPC spec fp-like (non ho idea di quale sia l'IPC di cinebench ad esempio) e con multithreading spinto... Due processi con IPC 2.4 sicuramente con le porte di INTEL ci vanno stretti... Sulle porte AMD ci vanno larghi... Anche se le unità INTEL sono a 256 bit, quindi in caso di AVX2 si potrebbe pareggiare...

Originariamente inviato da cdimauro

Anche i precedenti processori Intel facevano lo stesso, ma facendo uso dell'LSD (non quello che pensi ).

Mi sembrano numeri troppo elevati, e poi funzionerebbe soltanto nei cicli, per l'appunto.

Non so se erano 2, ma il P4 non aveva alcuna cache codice L1: tutte le istruzioni venivano decodificate e memorizzate nella trace cache (tipo cache L0), ed è stato proprio questa la causa dei suoi problemi di prestazioni (oltre alla microscopica cache L1 dati).

Si, ricordo... Sono appassionato di microarchitetture, ed ho studiato per fatti miei tutte le architetture dal PIII in poi...

Originariamente inviato da cdimauro

Sulla carta. Però ricorda sempre che stiamo parlando di processori out-of-order, ed è per questo che in un altro commento dicevo che un processore con meno porte potrebbe benissimo avere prestazioni simili a uno che ne ha di più.

La realtà è che le porte vengono selezionate dinamicamente in base al codice eseguito, e se una porta è impegnata per un'operazione, non si ferma tutta la macchina: se ne possono sfruttare altre nel frattempo. Quando sarà libera, verrà utilizzata dall'istruzione in attesa. E così via.

Potenza dell'esecuzione OoO.

Certo...

[bjt2]

Originariamente inviato da tuttodigitale

in teoria da un MOP possono uscire fino a 3uop...tuttavia è raro che questo avvenga.

Mica tanto raro... Praticamente tutte le istruzioni INT semplici con indirizzamento non troppo complesso sono una fastpath single con 3 MOP. E rimane fastpath single anche se la istruzione memoria è una read/modify/write!!!

[tuttodigitale]

Originariamente inviato da Ren

Secondo le teorie Desdenboy aggiungerei

Cyclone la clonazione.

diciamo che visto i precedenti in casa AMD (bulldozer) e di Keller, una soluzione con scheduler unico, che richiederebbe probabilmente qualche ciclo aggiuntivo a parità di FO4, sarebbe alquanto improbabile.
Poi che le ALU siano 4 e le AGU siano 2 lo dice la patch non dresdenboy.

[bjt2]

Originariamente inviato da tuttodigitale

diciamo che visto i precedenti in casa AMD (bulldozer) e di Keller, una soluzione con scheduler unico, che richiederebbe probabilmente qualche ciclo aggiuntivo a parità di FO4, sarebbe alquanto improbabile.
Poi che le ALU siano 4 e le AGU siano 2 lo dice la patch non dresdenboy.

Le mazzate che si sono date lui e juanrga su semiaccurate sul miglior rapporto ALU/AGU...

[tuttodigitale]

riguardo il checkpoint. questa unità, è presente anche nelle CPU IBM: In sostanza questa unità determina se si sono verificati errori. L'unità genera ECC Quando questo si verifica, la matrice del checkpoint viene utilizzato per riavviare l'esecuzione, che quindi è in grado di risolvere problemi transitori, fino al cambio, credo inevitabile di CPU. In sostanza è un meccanismo di ridondanza orientata al mercato data-center.

[paolo.oliva2]

Ma il 14nm FinFet Intel supporta sino a 1,35V, perché il 14nm FinFet GF dovrebbe fermarsi a 1,1V? Chiaro che non parlo di efficienza ma di OC. Se con un FO4 più basso e potrebbe arrivare >3,5GHz con, 1,1V, anche se il 14nm GF supportasse un Vcore inferiore rispetto a quello Intel, non vorrebbe dire comunque frequenze inferiori, anche perché il turbo di BD sul 28nmBulk è 4,3GHz che di fatto è +100MHz rispetto al max di Intel sul 14nm (4,2GHz 6700k)

[digieffe]

... qualche novità qui ?

[cdimauro]

Originariamente inviato da tuttodigitale

lo abbiamo fatto su questo sito...purtroppo ci manca un dato fondamentale il livello di integrazione della L2...se ipotizziamo il 70%, come Polaris, sono 250mmq.

Anche Polaris ha cache L1 e L2. Supponendo che siano simili a quelle di Zen, si potrebbe prendere una di queste per cercare di effettuare una misura più precisa.

in teoria da un MOP possono uscire fino a 3uop...tuttavia è raro che questo avvenga.

Dovrebbe essere per istruzioni con modalità d'indirizzamento della memoria a 3 operandi.

Comunque il meccanismo delle MOP -> più uop è simile a quello che c'è nelle CPU Intel.

Vi presento ZEN:

scherzo.

E' sicuramente l'ARM più performante, per lo meno in single core/thread, ma è anche il motivo per cui non c'è da spaventarsi da quest'architettura:

Tested: Why the iPad Pro really isn't as fast a laptop

ecco che il limite delle 2 ALU in XV non sembra così opprimente

Non è così semplice il discorso. Se l'OoO bastasse a risolvere tutti i problemi di dipendenze & schedulazione, sarebbe sufficiente un decoder a 1 via e un backend OoO.

Ovviamente tutto dipende molto dalla tipologia di codice eseguito.

Nel caso di codice che sfrutta molto le unità FP, c'è da dire che è abbastanza lineare per cui si possono sfruttare abbastanza bene tali unità, sebbene ci siano degli ostacoli con le SSE. Il punto è che queste istruzioni usano per lo più istruzioni 2 operandi con la destinazione usata anche come sorgente (si parla di operazioni distruttive). Questo costringe a fare uso frequente di istruzioni FMOV, che dunque vanno eseguite assieme a FADD,FSUB,FMUL, ecc.. Aggiungiamoci il fatto che servono anche delle operazioni "intere" per gestire indici e/o puntatori, nonché loop, e vedi tu stesso impiegare stabilmente 4 unità FP a 128 bit sia tutt'altro che semplice.

Con AVX, che supportano 3 operandi (non distruttivi) le cose si semplificano notevolmente, e col vantaggio che sono pure a 256 bit.

Se passiamo al codice non FP, allora cominciano i guai, perché non è più così semplice e lineare, e diverse volte sei pure costretto a ripopolare la pipeline. Qui anche la latenza troppo elevata di certe istruzioni crea non pochi problemi, perché impegna per troppo tempo le unità d'esecuzione, e l'unità di retire è lì che aspetta bloccando risorse che devono essere liberate per altre istruzioni.

Originariamente inviato da tuttodigitale

riguardo il checkpoint. questa unità, è presente anche nelle CPU IBM: In sostanza questa unità determina se si sono verificati errori. L'unità genera ECC Quando questo si verifica, la matrice del checkpoint viene utilizzato per riavviare l'esecuzione, che quindi è in grado di risolvere problemi transitori, fino al cambio, credo inevitabile di CPU. In sostanza è un meccanismo di ridondanza orientata al mercato data-center.

Allora non porta alcun contributo a livello puramente prestazionale.

[cdimauro]

Originariamente inviato da bjt2

Beh, semplice o no, se raddoppiamo la mia stima, abbiamo il consumo di 4 pipeline a 128 bit che è il caso peggiore che potrebbe mai incontrare la FPU Zen (powerhog virus di 4 FMAC)

Io ormai aspetto qualche mese e mi levo ogni dubbio.

Se non mi sbaglio le altre 2 porte della FPU di BD/XV possono fare le istruzioni SSE intere, che comprendono comunque moltiplicazione e divisione... Quindi non è che le altre 2 pipeline occupino poi molto meno spazio...

Mi pare che quelle 2 porte siano relegate a codice legacy: MMX e x87.

E lo hanno fatto... I numeri che ho dato sono così vaghi perchè non ci sono notizie su quanto possa occupare la L3 e quindi fare le proporzioni...

Vedi sopra: e usare la L1 o la L2?

Potenza delle MOP AMD... Una MOP AMD può contenere fino a 3 uops!
ALU+AGU+MEM (!!!) Infatti molte istruzioni, anche reg+mem/reg sono implementate con una MOP e sono fastpath single... I decoder AMD sono di una VIULEEEENZA impressionante...

Beh, anche quelli Intel operano similmente. Lì non si parla di MOP, ma di uop "fused", che in fase di esecuzione vengono suddivise in 2 (non mi pare che si arrivi a 3, ma adesso non ho tempo per controllare) uop più semplice da dare in pasto alle rispettive porte.

A parte questo, poi bisogna anche vedere il throughput e la latenza. Ad esempio, se vai a vedere la singola MOP di AMD per il caso ISTRUZIONE Mem,Reg oppure Mem,Imm, hai una latenza molto elevata e un throughput che si riduce a 1 (da 0.5).

Esempio: 4 e 1 per la MOV, e ben 7 e 1 per la ADD.

Beh, immagino che qualunque scomposizione in thread debba tenere conto della granularità del parallelismo e della latenza di creazione thread... Sappiamo che su windows, rispetto a linux creare processi è una tragedia greca! Meglio i thread... Eppure a occhio sembra che Windows 10 è migliorato: quando avevo windows 7 e ricaricavo 40 schede su chrome, con una estensione che si chama "reload all", il PC (mouse compreso) scattava e quasi si impiantava per qualche secondo mentre i 40 processi venivano creati... Ora con windows 10 la situazione è molto migliorata...

Quindi l'offloading ha senso se il working set ha una certa dimensione.

Hai ragione: a parità di porte la soluzione di INTEL è meglio, ma ovviamente su INTEL sono 4 totali, contro 4+4, quindi, a meno di disastri di AMD nello scheduler, l'efficienza dell'SMT dovrebbe essere superiore...

Dipende da quante uop (e non MOP o fused-uop) si possono inviare alle porte.

Non con 2 thread... Immagina un processo FP intensive con un IPC spec fp-like (non ho idea di quale sia l'IPC di cinebench ad esempio) e con multithreading spinto... Due processi con IPC 2.4 sicuramente con le porte di INTEL ci vanno stretti... Sulle porte AMD ci vanno larghi... Anche se le unità INTEL sono a 256 bit, quindi in caso di AVX2 si potrebbe pareggiare...

Vedi sopra la mia risposta a tuttodigitale.

Inoltre con AVX2 c'è il vantaggio che anche in single core/thread puoi spremere per benino le unità FP, lasciando pure un po' spazio all'esecuzione di istruzioni intere.

[bjt2]

Originariamente inviato da digieffe

... qualche novità qui ?

http://forums.anandtech.com/showpost...postcount=2166

Il grafico in quel post fa ben sperare... Sempre se il FO4 di Zen non è troppo alto...

[bjt2]

Originariamente inviato da cdimauro

Beh, anche quelli Intel operano similmente. Lì non si parla di MOP, ma di uop "fused", che in fase di esecuzione vengono suddivise in 2 (non mi pare che si arrivi a 3, ma adesso non ho tempo per controllare) uop più semplice da dare in pasto alle rispettive porte.

A parte questo, poi bisogna anche vedere il throughput e la latenza. Ad esempio, se vai a vedere la singola MOP di AMD per il caso ISTRUZIONE Mem,Reg oppure Mem,Imm, hai una latenza molto elevata e un throughput che si riduce a 1 (da 0.5).

Esempio: 4 e 1 per la MOV, e ben 7 e 1 per la ADD.

Dipende da quante uop (e non MOP o fused-uop) si possono inviare alle porte.

Per l'alta latenza non ci avevo fatto caso... Se ti riferisci a BD, potrebbe anche essere dovuta al fatto che ha un FO4 basso e quindi molti stadi...
Per quanto riguarda le uops "issuabili": a quanto ho capito in AMD le AGU sono attaccate alle unità di L/S, quindi una MOP viene al più splittata in 2 pezzi: ALU e AGU+MEM. Ovviamente se il dato deve essere letto da memoria, l'operazione non può partire subito, viceversa se il dato deve essere scritto, l'operazione ALU può partire e viene ritirata quando il dato è stato calcolato e scritto... E una uop mem può anche essere Read/Modify/Write...

Comunque l'alta latenza non è poi tanto disastrosa. Quello che conta è il numero di decoder occupati, perchè spesso si è limitati da questo... AMD da tempo fa il fetch di 32 bytes alla volta e INTEL fino a qualche generazioni fa era a 16. ora hanno recuperato... Quindi il collo di bottiglia era il decoding. Per INTEL non era tanto grave, perchè tanto con codice non ottimizzato, spesso non si raggiungeva il limite teorico delle 4-1-1-1 uop in decodifica, quindi i 16 bytes/ciclo non erano quasi mai un problema, ma con la uop fusion e altri miglioramenti, immagino che quella iniziava a essere una limitazione pesante... Ad ogni modo AMD con le sue MOP molto potenti, può spesso decodificare 4 istruzioni per ciclo... O anche 2, vista la genialata delle fastpath double... Invece, almeno fino a qualche generazione fa, INTEL appena incontrava una istruzione con più di 1 uop, doveva passare al microcodice, scendendo a una istruzione/ciclo in decodifica, contro le 2 di AMD...

[cdimauro]

Originariamente inviato da bjt2

Per l'alta latenza non ci avevo fatto caso... Se ti riferisci a BD, potrebbe anche essere dovuta al fatto che ha un FO4 basso e quindi molti stadi...

No, finora ho confrontato Steamroller (perché di Excavator non ho informazioni, ma comunque è sostanzialmente identico per i discorsi che stiamo facendo) e Haswell (ma Broadwell funziona all'incirca allo stesso modo).

Per quanto riguarda le uops "issuabili": a quanto ho capito in AMD le AGU sono attaccate alle unità di L/S, quindi una MOP viene al più splittata in 2 pezzi: ALU e AGU+MEM.

Confermo. Lo scheduler (per gli interi) può accettare al massimo 2 MOP, e una MOP viene divisa in 1 o 2 uop. Non esiste nessuna MOP che venga divisa in 3 uop (anche per l'FPU).

Quindi è simile ad Intel (1 fused-uop = 2 uop).

Ovviamente se il dato deve essere letto da memoria, l'operazione non può partire subito, viceversa se il dato deve essere scritto, l'operazione ALU può partire e viene ritirata quando il dato è stato calcolato e scritto... E una uop mem può anche essere Read/Modify/Write...

Sì, ed è in quest'ultimo caso che la latenza risulta elevata. Finché dalla memoria si legge non ci sono problemi, ma non appena diventa sorgente e destinazione, si aggiungono almeno 6 cicli di clock.

Comunque l'alta latenza non è poi tanto disastrosa. Quello che conta è il numero di decoder occupati, perchè spesso si è limitati da questo... AMD da tempo fa il fetch di 32 bytes alla volta e INTEL fino a qualche generazioni fa era a 16. ora hanno recuperato... Quindi il collo di bottiglia era il decoding. Per INTEL non era tanto grave, perchè tanto con codice non ottimizzato, spesso non si raggiungeva il limite teorico delle 4-1-1-1 uop in decodifica, quindi i 16 bytes/ciclo non erano quasi mai un problema, ma con la uop fusion e altri miglioramenti, immagino che quella iniziava a essere una limitazione pesante...

In realtà ho visto che perfino Skylake continua ad avere il limite di 16 byte/ciclo per il fetch, e il decoder può decodificare al massimo 4 istruzioni per ciclo (e non 6 come pensavo). Come le precedenti microarchitetture, insomma. Le modifiche introdotte in Skylake riguardano altre cose.

E' soltanto AMD che ha avuto il bisogno di eseguire il fetch di 32 byte/ciclo, divisi in 16 byte/ciclo per ogni thread hardware.

Ad ogni modo AMD con le sue MOP molto potenti, può spesso decodificare 4 istruzioni per ciclo... O anche 2, vista la genialata delle fastpath double...

Il fastpath double è necessario perché le istruzioni vettoriali a 256 bit vengono suddivise in 2 MOP per poter essere eseguite.

fastpath double per altre istruzioni penso ci saranno anche, ma non ho nessuna tabella che le riporta, purtroppo.

La stragrande maggioranza è rappresentata da quelle fastpath single, usate anche nel caso di istruzioni RMW.

E' in quest'ultimo caso che c'è un vantaggio rispetto ai processori Intel, perché questi ultimi richiedono 2 fused-uop (e quindi generano 2+2 uop; mentre AMD soltanto 2), ma al prezzo di una maggiore latenza (almeno 1 ciclo di clock).

Invece, almeno fino a qualche generazione fa, INTEL appena incontrava una istruzione con più di 1 uop, doveva passare al microcodice, scendendo a una istruzione/ciclo in decodifica, contro le 2 di AMD...

Questo non mi risulta. Sono andato a controllare, e a partire dal PentiumPro è presente il classico schema 4-1-1, mentre a partire dal Core2 c'è il nuovo 4-1-1-1.

Forse ti riferivi al Pentium 4, che poteva decodificare al massimo un'istruzione per ciclo di clock, ma generava comunque da 1 a 4 uop per la maggior parte delle istruzioni, mentre quelle più complicate richiedevano più di un ciclo di clock per essere decodificate.

[bjt2]

Originariamente inviato da cdimauro

No, finora ho confrontato Steamroller (perché di Excavator non ho informazioni, ma comunque è sostanzialmente identico per i discorsi che stiamo facendo) e Haswell (ma Broadwell funziona all'incirca allo stesso modo).

Confermo. Lo scheduler (per gli interi) può accettare al massimo 2 MOP, e una MOP viene divisa in 1 o 2 uop. Non esiste nessuna MOP che venga divisa in 3 uop (anche per l'FPU).

Quindi è simile ad Intel (1 fused-uop = 2 uop).

Sì, ed è in quest'ultimo caso che la latenza risulta elevata. Finché dalla memoria si legge non ci sono problemi, ma non appena diventa sorgente e destinazione, si aggiungono almeno 6 cicli di clock.

In realtà ho visto che perfino Skylake continua ad avere il limite di 16 byte/ciclo per il fetch, e il decoder può decodificare al massimo 4 istruzioni per ciclo (e non 6 come pensavo). Come le precedenti microarchitetture, insomma. Le modifiche introdotte in Skylake riguardano altre cose.

E' soltanto AMD che ha avuto il bisogno di eseguire il fetch di 32 byte/ciclo, divisi in 16 byte/ciclo per ogni thread hardware.

Il fastpath double è necessario perché le istruzioni vettoriali a 256 bit vengono suddivise in 2 MOP per poter essere eseguite.

fastpath double per altre istruzioni penso ci saranno anche, ma non ho nessuna tabella che le riporta, purtroppo.

La stragrande maggioranza è rappresentata da quelle fastpath single, usate anche nel caso di istruzioni RMW.

E' in quest'ultimo caso che c'è un vantaggio rispetto ai processori Intel, perché questi ultimi richiedono 2 fused-uop (e quindi generano 2+2 uop; mentre AMD soltanto 2), ma al prezzo di una maggiore latenza (almeno 1 ciclo di clock).

Questo non mi risulta. Sono andato a controllare, e a partire dal PentiumPro è presente il classico schema 4-1-1, mentre a partire dal Core2 c'è il nuovo 4-1-1-1.

Forse ti riferivi al Pentium 4, che poteva decodificare al massimo un'istruzione per ciclo di clock, ma generava comunque da 1 a 4 uop per la maggior parte delle istruzioni, mentre quelle più complicate richiedevano più di un ciclo di clock per essere decodificate.

Il fetch di 32 bytes ciclo c'era anche prima di BD, mi pare addirittura sul K7...

il fastpath double è necessario per le istruzioni splittate (128 bit su bobcat e 256 su BD/jaguar), ma è sfruttato anche per altre istruzioni più semplici, con il vantaggio di non fermare il decoder in modalità single istruction per ciclo solo per una istruzione un attimo più complessa... Anche se le fastpath single sono molto di più di quelle INTEL. E mi pare che solo di recente INTEL ha risolto il problema di uop con non più di 3 operandi (da cui il FMA3 a favore dell'FMA4 spinto da AMD che era supportato a basso livello), o forse no...

Per quanto riguarda il bursti INTEL 4-1-1-1, mi ricordo che Agner Fog ha fatto delle analisi in proposito: non appena si esce fuori dallo schema 4-1-1-1, e cioè se dopo l'istruzione microcodificata con 4 uops non ci sono 3 istruzioni semplici, il sistema si "inceppa" e si procede ad al più una istruzione per ciclo (sempre se inferiori o uguali a 4 uop), fin quando non si ri-incontra di nuovo un bundle del genere, o al più un 4-1 o 4-1-1... Ovviamente sono supportati anche 3-1-1-1, 2-1-1-1 e 1-1-1-1... Per inceppato, intendo che un 4-1-4-1 è fatto in 2 cicli e non 1... Ossia i 4 decoder non sono complessi...