[Thread Ufficiale] Aspettando ZEN

[Piedone1113]

Originariamente inviato da LMCH

Aveva puntato tutto su Itanium (in origine un progetto HP) perchè pensava di avere il dominio incontrastato nel settore degli x86 e di continuare ad averlo con i P4 che sarebbero arrivati di li a poco.
Quindi pensava di poter gestire la transizione da x86 ad Itanium secondo i suoi termini
(prima la fascia alta dei server e poi piano piano quelle inferiori).
Solo che AMD arrivò prima con K7 e poi con Opteron/Athlon a rompere gli equilibri.

Il fatto che poi in troppi avessero voluto saltare anticipatamente sul carro del vincitore
e "lasciare la loro impronta" nel progetto di Itanium ha peggiorato le cose in modo orribile
(set di registri "enorme" con latenze di accesso di una cache L1, un intero core 486 "per la retrocompatibilità", ecc. ecc.)
per quello che in origine doveva essere un semplice processore VLIW "con set d'istruzioni compresso".
Se non ci fosse stato il contratto ferreo stipulato con HP, probabilmente Itanium sarebbe stato abbandonato alla prima generazione.

Aggiungerei anche che all'epoca c'erano molte cpu server (digital, sun, compaq, ibm ecc) che segmentavano ulteriormente il mercato aumentando l'inerzia per passare ad una nuova architettura)

[cdimauro]

Le altre architetture server sono andate morendo, lasciando la strada a Itanium e x64. Solo alcune sono rimaste, e ancora oggi attive: POWER e SPARC.

Originariamente inviato da LMCH

Aveva puntato tutto su Itanium (in origine un progetto HP) perchè pensava di avere il dominio incontrastato nel settore degli x86 e di continuare ad averlo con i P4 che sarebbero arrivati di li a poco.
Quindi pensava di poter gestire la transizione da x86 ad Itanium secondo i suoi termini (prima la fascia alta dei server e poi piano piano quelle inferiori).
Solo che AMD arrivò prima con K7 e poi con Opteron/Athlon a rompere gli equilibri.

E' stato Opteron/x64 a compromettere il futuro di Itanium, e la transizione da IA-32 a IA-64 per tutto il software, come pianificato da Intel.

I soli P4 e Athlon non avrebbero potuto bloccare questo piano, perché a 32 bit, quando il futuro sarebbe stato certamente a 64 bit.

Il fatto che poi in troppi avessero voluto saltare anticipatamente sul carro del vincitore e "lasciare la loro impronta" nel progetto di Itanium ha peggiorato le cose in modo orribile (set di registri "enorme" con latenze di accesso di una cache L1, un intero core 486 "per la retrocompatibilità", ecc. ecc.) per quello che in origine doveva essere un semplice processore VLIW "con set d'istruzioni compresso".
Se non ci fosse stato il contratto ferreo stipulato con HP, probabilmente Itanium sarebbe stato abbandonato alla prima generazione.

Non c'era un intero 486 on chip, ma la compatibilità IA-32 veniva garantita tramite una traduzione delle istruzioni IA-32 in apposite istruzioni EPIC, che però non era affatto efficiente. Infatti questa parte del chip fu successivamente rimossa, in favore di una soluzione interamente software (con compilatore JIT, ovviamente), che ebbe prestazioni nettamente superiori.

Ciò precisato, concordo che il progetto fosse troppo complesso. Oggi il discorso sarebbe stato diverso, visto che possiamo impaccare miliardi di transistor su un singolo chip, e implementare micro-architetture molte più efficienti, ma 15 anni fa fu un vero e proprio bagno di sangue per Intel/HP.

P.S. Non ho mai avuto modo di studiare l'architettura EPIC, per cui non posso giudicare se fosse una buona ISA, ma l'idea di spostare la complessità del chip sul compilatore non m'è mai piaciuta.

[bjt2]

Originariamente inviato da digieffe

@bjt2

con che tipi di transistor è fatto zen? ovvero a quale linea del grafico bisogna far riferimento?
le 2 migliori s'impennano appena dopo i 4ghz... 4.1 e 4.3

Bisogna guardare le curve rosse (LVT).
Questo grafico è di due anni fa e si parlava già di transisotrs sLVT che sono ancora più a destra, ma supponiamo che non esistano.

9T è la libreria HDL ad alta densità (che sale meno di clock, come per Excavator)
12T è la libreria HPL ad alte prestazioni e meno densa, che sale di più.

Successivamente è stato detto che le librerie 12T non sarebbero state consentite, ma che sarebbero esistite solo le 9T e una versione intermedia, la 10,5T. Quindi immaginiamo una curva rossa, 10.5T a metà strada tra la 9T e la 12T.

Ora c'è da fare qualche considerazione.
Queste curve di consumo sono calcolate con il +10% di margine sul Vcore e con Tjunction pari a 125 gradi. Ossia il caso peggiore. Ma AMD ha le tecnologie DVFS e AVFS (non ricordo mai quale delle due è) che consente di azzerare il 10% di margine di Vcore (e quindi ridurre del 20% i consumi) e in più ha l'XFR che alza ulteriormente il clock se c'è margine. E quando c'è? Se la tj è minore di 125 gradi, cioè sempre. Quindi più la CPU è fredda e più ulteriormente sale di clock.
Poi c'è da dire che questo grafico vale per la FPU NEON, che fa parte di una CPU ASIC e non sintetizzata, con FO4 almeno di 30. Quindi questo grafico va ulteriormente abbassato.

In sintesi:

Tracciare una linea rossa 10.5T intermedia tra le 2 rosse.
Tracciare una linea verticale alla frequenza base (attualmente 3.6)
Vedere a che altezza sta (circa 4 o 5)
Moltiplicare per 2
Vedere a che frequenza corrisponde
Quella frequenza potrebbe essere la massima di turbo

MA

1) AVFS o DVFS riducono la potenza del 20%, quindi il grafico si sposta un po' verso destra, facendo guadagnare almeno 100MHz (3%)
2) La Tj non è certo 125 gradi, quindi XFR farà guadagnare almeno altri 100MHz
3) Il FO4 non è 30 ma inferiore, aggiungiamo altri 100MHz

Quindi in sostanza se tutto va bene il turbo max dovrebbe essere almeno 4.3GHz che diventano 4.4Ghz con l'XFR. Ma io penso che la mia previsione di 4.5GHz di turbo (senza XFR perchè a quel tempo non si sapeva che ci fosse) sia ancora possibile per i motivi che ho scritto...

[Cloud76]

Secondo voi c'è la possibilità verosimile di vedere le schede AM4 in vendita e disponibili entro un paio di settimane? Tralasciando Zen che ovviamente arriverà più avanti, le schede AM4 dovrebbero essere ormai già fatte e finite (è da settembre che girano le prime foto e altre sono state presentate al CES) e teoricamente dovrebbero uscire prima di Zen in abbinamento alle APU bristol ridge. Auspicabile vedere qualcosa nella fascia medio bassa?

[bjt2]

Originariamente inviato da cdimauro

P.S. Non ho mai avuto modo di studiare l'architettura EPIC, per cui non posso giudicare se fosse una buona ISA, ma l'idea di spostare la complessità del chip sul compilatore non m'è mai piaciuta.

Alla fine se ne sono accorti anche alla INTEL. Se la prima versione di itanium eseguiva un solo bundle alla volta, le versioni successive ne eseguivano di più, OOO e speculativamente. Siccome le istruzioni all'interno del bundle erano garantite indipendenti, lo scheduler poteva trattare i bundle come se fossero una singola istruzione (complessa), che però usa un bordello di registri, ma l'algoritmo classico dello scoreboarding va bene lo stesso: ci sono solo più "crocette" di risorse occupate per ogni riga, quindi magari il FO4 era un po' più alto (infatti i clock erano bassi) ma era teoricamente fattibile con logica semplice dal punto di vista logico, il classico scoreboarding, e quindi duplicando le pipeline ecc...

[cdimauro]

Esattamente. Se alla fine sei costretto ugualmente a implementare una logica OoO, hai fallito completamente l'obiettivo di EPIC, e di un'architettura VLIW in generale, generando un mostro ibrido.

Anche perché, è vero che nei bundle puoi mettere istruzioni indipendenti (e quindi eseguibili "one-shot", senza controlli: modello VLIW, appunto), ma è anche vero che hai pur sempre un'architettura RISC, e dunque per eseguire certi compiti sono richieste più istruzioni.

Inoltre non sempre è possibile riempire completamente il bundle con 3 istruzioni indipendenti, per cui sei costretto a infilarci una o addirittura due NOP, vanificando i vantaggi del bundle. E, soprattutto, diminuendo enormemente la densità del codice (visto che un bundle era da 128 bit: ben 16 byte), da cui la necessità di avere cache molto più grandi.

In una parola: Itanic...

[Gioz]

Originariamente inviato da paolo.oliva2

Ma infatti io non è che ho detto che...

ok, semplicemente non ho capito un'acca di tutto il tuo discorso, ora mi è chiaro.

[devil_mcry]

Secondo voi per febbraio marzo sarà possibile vederli quanto meno recensiti?

[Ryddyck]

Per i malati di architettura zen http://pc.watch.impress.co.jp/docs/c...i/1037983.html

Per chi non può aspettare http://www.pcworld.com/article/31551...our-years.html

Jim Anderson, senior vice president and general manager of AMD’s Computing and Graphics business, told PCWorld that Ryzen chips will be available from day one. “We’re not going to do a paper launch,” he said, referring to a “launch” where customers have to wait weeks or months for the products to actually arrive. “We’ve done that before. We’re not going to mess with it.”

Due calcoli approssimativi tra uscita delle mobo e presentazione/lancio di ryzen direi che si potrebbe vedere al gdc 2017...
Ma si dice anche che durerà abbastanza

Papermaster confirmed the four-year lifespan and tapped the table in front of him: “We’re not going tick-tock,” he said. “Zen is going to be tock, tock, tock.”

Per chi si fosse perso Raja https://www.youtube.com/watch?v=FwcUMZLvjYw (il brutto, il bello e l'abbronzato ahahahahhaha)

[digieffe]

Originariamente inviato da bjt2

Bisogna guardare le curve rosse (LVT).
Questo grafico è di due anni fa e si parlava già di transisotrs sLVT che sono ancora più a destra, ma supponiamo che non esistano.

9T è la libreria HDL ad alta densità (che sale meno di clock, come per Excavator)
12T è la libreria HPL ad alte prestazioni e meno densa, che sale di più.

Successivamente è stato detto che le librerie 12T non sarebbero state consentite, ma che sarebbero esistite solo le 9T e una versione intermedia, la 10,5T. Quindi immaginiamo una curva rossa, 10.5T a metà strada tra la 9T e la 12T.

Ora c'è da fare qualche considerazione.
Queste curve di consumo sono calcolate con il +10% di margine sul Vcore e con Tjunction pari a 125 gradi. Ossia il caso peggiore. Ma AMD ha le tecnologie DVFS e AVFS (non ricordo mai quale delle due è) che consente di azzerare il 10% di margine di Vcore (e quindi ridurre del 20% i consumi) e in più ha l'XFR che alza ulteriormente il clock se c'è margine. E quando c'è? Se la tj è minore di 125 gradi, cioè sempre. Quindi più la CPU è fredda e più ulteriormente sale di clock.
Poi c'è da dire che questo grafico vale per la FPU NEON, che fa parte di una CPU ASIC e non sintetizzata, con FO4 almeno di 30. Quindi questo grafico va ulteriormente abbassato.

In sintesi:

Tracciare una linea rossa 10.5T intermedia tra le 2 rosse.
Tracciare una linea verticale alla frequenza base (attualmente 3.6)
Vedere a che altezza sta (circa 4 o 5)
Moltiplicare per 2
Vedere a che frequenza corrisponde
Quella frequenza potrebbe essere la massima di turbo

MA

1) AVFS o DVFS riducono la potenza del 20%, quindi il grafico si sposta un po' verso destra, facendo guadagnare almeno 100MHz (3%)
2) La Tj non è certo 125 gradi, quindi XFR farà guadagnare almeno altri 100MHz
3) Il FO4 non è 30 ma inferiore, aggiungiamo altri 100MHz

Quindi in sostanza se tutto va bene il turbo max dovrebbe essere almeno 4.3GHz che diventano 4.4Ghz con l'XFR. Ma io penso che la mia previsione di 4.5GHz di turbo (senza XFR perchè a quel tempo non si sapeva che ci fosse) sia ancora possibile per i motivi che ho scritto...

praticamente stai dicendo che è abbastanza ragionevole che Zen possa essere 3.6 base, 4.2 turbo max (prima che la linea del consumo s'impenni) ed una freq OC max di 4.6 con un consumo di ~180w

[bjt2]

Originariamente inviato da Ryddyck

Per i malati di architettura zen [url]http://pc.watch.impress.co.jp/docs/column/kaigai/1037983.html[/url

Letto su anand: qui il link con traduzione in inglese (selezionate italiano se volete, ma io sono più a mio agio con l'inglese) https://translate.google.com/transla...tml&edit-text=

Il link mio punta alla sezione sul decoder. Dopo vedo se il link tuo punta a una serie più ampia di pagine.

La cosa bella è il decoding di Zen. Messo a confronto con quello di SKL.

1) In SKL la uop cache e la L1I sono legate e bisogna interrogarle entrambe. InZen sono indipendenti e si può interrogarle in parallelo. Ossia una istruzione può essere nella L1I o nella uop cache o in entrambi.

2) Le uop di Zen sono molto dense. Praticamente è 1 a 1 e il decoding effettivo è fatto più tardi (vedi dopo). Confermata la mia intuizione di decoding delle istruzioni microcodificate con un puntatore alla microcode rom. La uop cache e la microop queue contengono una sorta di macro-op densissime e quindi si può memorizzare molte più istruzioni a parità di spazio rispetto ad intel.

3) COme avevo pensato io solo al livello di dispatch è fatta l'espansione delle istruzioni microcodificate. Ma la cosa nuova è che anche le istruzioni a 2 uop (come le 256 bit) occupano un solo slot fino and ora e vengono espanse solo a livello di dispatch.
In sostanza a livello di dispatch è fatto:
a) Espansione delle istruzioni microcodificate: da uno slot a n uops
b) Espansione delle istruzioni complesse (es:256bit): da uno slot a 2 uops
c) eliminazione delle istruzioni stack/memoria: stack engine: da uno slot a zero uops
d) branch e instruction fusion (cmp/jp e load/op presumo): da 2 slot a una uop

Resta da vedere il throughput. Il tizio suppone che le operazioni microcodificate siano complesse come le double path e che quindi occupino uno slot e un decoder doppio, ma sono sue supposizioni. Ammesso che esista ancora il limite delle MOP doppie in decoding, non è detto che le microcodificate occupino lo spazio doppio.

In breve: il decoding di Zen è fatto in due step (e questo potrebbe anche indicare bassissimo FO4): da x86/64 a un formato intermedio ancora CISC, ma a lunghezza fissa e quindi più facile da decodificare dopo.
Queste istruzioni complesse rimangono così per tutta la parte in order (e nella uop cache e uop queue, consumando pochissimo spazio) sono espanse/fuse/elimiate SOLO alla fase di dispatch, dove sono trasformate in uops puramente RISC. Quindi il dispatch di 6 uops/ciclo può anche essere di istruzioni fuse e quindi doppie...

Infine confronta la uop cache tra INTEL e Zen: mentre su INTEL c'è una stretta correlazione tra linee della uop cache e L1I, e quindi alcune sequenze di istruzioni non possono andare nella uop cache (sequenze troppo lunghe, quindi spesso per istruzioni microcodificate), in Zen non c'è questo vincolo e quindi la cache può essere riempita di più.

[bjt2]

Originariamente inviato da digieffe

praticamente stai dicendo che è abbastanza ragionevole che Zen possa essere 3.6 base, 4.2 turbo max (prima che la linea del consumo s'impenni) ed una freq OC max di 4.6 con un consumo di ~180w

Beh io spero che sia qualcosa di più... Sopratutto se la 3.6 base è calcolata nel caso peggiore (Tj=125C, Vcore alto e 95W) e l'XFR nei casi reali praticamente non fa mai andare la CPU a 3.6 ma di più, perchè la Tj è più bassa (50-80) e il Vcore è giusto...

Addirittura può succedere che, con XFR attivato, facendo un leggero undervolt la frequenza media raggiunta si alzi, perchè il chip scalda meno...

[cdimauro]

Originariamente inviato da bjt2

Letto su anand: qui il link con traduzione in inglese (selezionate italiano se volete, ma io sono più a mio agio con l'inglese) https://translate.google.com/transla...tml&edit-text=

Il link mio punta alla sezione sul decoder. Dopo vedo se il link tuo punta a una serie più ampia di pagine.

La cosa bella è il decoding di Zen. Messo a confronto con quello di SKL.

1) In SKL la uop cache e la L1I sono legate e bisogna interrogarle entrambe. InZen sono indipendenti e si può interrogarle in parallelo. Ossia una istruzione può essere nella L1I o nella uop cache o in entrambi.

Non è così per Skylake. A pag. 32 del manuale delle ottimizzazioni Intel c'è lo schema, e si può vedere che la DSB (Decoded Icache. La cache uop) è indipendente dalla L1I. Al più, com'è ovvio che sia, riceve le uop dai decoder, che ovviamente sono collegati alla L1I.

Ma in generale la IDQ (Instruction Decode Queue aka micro-op cache) riceve indipendentemente le uop da: MSROM (uop-ROM. max 4uop/ciclo), IDQ (uop-cache. max 6 uop/ciclo), e decoder (max 5 uop/ciclo). Quindi in totale può (molto) teoricamente ricevere max 15 uop/ciclo.

Per cui lo schema riportato dal sito giapponese risulta sbagliato.

2) Le uop di Zen sono molto dense. Praticamente è 1 a 1 e il decoding effettivo è fatto più tardi (vedi dopo). Confermata la mia intuizione di decoding delle istruzioni microcodificate con un puntatore alla microcode rom. La uop cache e la microop queue contengono una sorta di macro-op densissime e quindi si può memorizzare molte più istruzioni a parità di spazio rispetto ad intel.

Questo è opinabile. Il fatto che siano molto dense, vuol dire anche che sono molto lunghe, perché le istruzioni x86 sono lunghe fino a 15 byte, nella mia esperienza (nonché statistiche raccolte. Vedi sotto) non è difficile incontrare istruzioni particolarmente lunghe.

Dal binario della beta pubblica di Photoshop CS6. x86/32 bit:

Instructions: 1631136    Size: 5268115
Sizes:
  Size      Count
     3     389004
     2     387011
     1     298078
     5     190084
     6     140620
     4     123149
     7      95177
    10       4660
     8       2407
    11        829
     9        117

e x64/64 bit:

Instructions: 1638505    Size: 7056925
Sizes:
  Size      Count
     3     352175
     5     330286
     4     252766
     2     237364
     8     165612
     7     122134
     1      91535
     6      68408
     9       9209
    10       3480
    11       3257
    12       1997
    13        126
    14         89
    15         67

Punterei l'attenzione sul codice a 64 bit, che ormai è il più diffuso a livello mainstream.

Come si può vedere, non sono affatto rare istruzioni che occupino anche 8 byte, e dunque la macro-op dovrà necessariamente avere abbastanza spazio per contenere tutte le informazioni. Ma se la mappatura è 1:1 con un'istruzione x86/x64, allora immagino che le macro-op siano costituite da 15-16 byte, che è davvero tanto.

Per cui bisogna vedere quante di queste macro-op possano essere contenute nell'apposita cache.

3) COme avevo pensato io solo al livello di dispatch è fatta l'espansione delle istruzioni microcodificate. Ma la cosa nuova è che anche le istruzioni a 2 uop (come le 256 bit) occupano un solo slot fino and ora e vengono espanse solo a livello di dispatch.

Beh, questa non è certo una cosa nuova: ne avevo/amo parlato proprio su AnandTech.

Però vedi sotto.

In sostanza a livello di dispatch è fatto:
a) Espansione delle istruzioni microcodificate: da uno slot a n uops

Su Intel queste istruzioni non occupano spazio nella uop-cache, ma soltanto nella uop-queue.

b) Espansione delle istruzioni complesse (es:256bit): da uno slot a 2 uops

Questo in genere non avviene nelle uop-cache Intel, a parte per alcune precise istruzioni (non ricordo quali adesso) che hanno bisogno di essere divise in 2 uop.

c) eliminazione delle istruzioni stack/memoria: stack engine: da uno slot a zero uops

Questo avviene nella fase di register-rename sugli Intel, se c'è un rename per l'appunto.

Ma non mi è chiaro come possano essere eliminate le uop su Zen. Anche perché nello schema si vede che la micro-op queue (e dunque non la uop-cache) passa il controllo allo stack engine e/o (ma suppongo sia soltanto "o") alla ROM del microcodice, per poi riconvogliare il flusso da queste/a unità direttamente al dispatcher.

d) branch e instruction fusion (cmp/jp e load/op presumo): da 2 slot a una uop

Nei processori Intel le istruzioni fused occupano già 1 solo slot, perché arrivano così direttamente dal decoder (max 2 istruzioni fused per ciclo di clock).

Resta da vedere il throughput. Il tizio suppone che le operazioni microcodificate siano complesse come le double path e che quindi occupino uno slot e un decoder doppio, ma sono sue supposizioni. Ammesso che esista ancora il limite delle MOP doppie in decoding, non è detto che le microcodificate occupino lo spazio doppio.

Per quelle microcodificate, e in accordo con quanto abbiamo già discusso anche qui, mi aspetto che occupino un solo slot / macro-op, e che la uop-queue si occupi poi di generare al volo le uop da eseguire, dandole in pasto al dispatcher (vedi sopra per maggiori dettagli, quando ho parlato dello stack engine).

In breve: il decoding di Zen è fatto in due step (e questo potrebbe anche indicare bassissimo FO4): da x86/64 a un formato intermedio ancora CISC, ma a lunghezza fissa e quindi più facile da decodificare dopo.

Purtroppo il collo di bottiglia è già rappresentato dal solo fatto che devi decodificare le istruzioni x86/x64 a lunghezza variabile, che occupa una notevole porzione del decoder.

Queste istruzioni complesse rimangono così per tutta la parte in order (e nella uop cache e uop queue, consumando pochissimo spazio) sono espanse/fuse/elimiate SOLO alla fase di dispatch, dove sono trasformate in uops puramente RISC. Quindi il dispatch di 6 uops/ciclo può anche essere di istruzioni fuse e quindi doppie...

Purtroppo c'è non poca confusione in merito, a causa delle macro-op e micro-op.

La cache dovrebbe essere relativa alla macro-op, conservando quindi i benefici che ne derivano (maggior densità, visto che una macro-op può contenere fino a 2 uop, oppure una uop che punta alla uop ROM).

La coda, invece, dovrebbe essere relativa alle micro-op (come viene etichettata negli schemi), e dunque le macro-op a questo punto sarebbero già state espanse.

Siccome la uop-queue è PRIMA del dispatcher, vuol dire che il dispatcher NON si occupa dell'espansione delle macro-op in micro-op. Come peraltro sembra trasparire dallo schema.

Infine confronta la uop cache tra INTEL e Zen: mentre su INTEL c'è una stretta correlazione tra linee della uop cache e L1I, e quindi alcune sequenze di istruzioni non possono andare nella uop cache (sequenze troppo lunghe, quindi spesso per istruzioni microcodificate), in Zen non c'è questo vincolo e quindi la cache può essere riempita di più.

Vorrei capire dove starebbe questa correlazione di cui parli.

Per il resto le uop di Intel sono effettivamente molto più piccole. Infatti le istruzioni più complesse fanno uso di almeno un paio di uop, all'interno della cache, che fanno entrambe parte della stessa istruzione.

A questo punto le cose importanti da chiarire sono due: quante entry ci sono nelle cache (macro-op per Zen, e uop per Intel). E quante entry ci sono nella coda (DOVREBBERO essere uop per entrambi qui. Vedi sopra).

[paolo.oliva2]

Originariamente inviato da digieffe

praticamente stai dicendo che è abbastanza ragionevole che Zen possa essere 3.6 base, 4.2 turbo max (prima che la linea del consumo s'impenni) ed una freq OC max di 4.6 con un consumo di ~180w

Originariamente inviato da bjt2

Beh io spero che sia qualcosa di più... Sopratutto se la 3.6 base è calcolata nel caso peggiore (Tj=125C, Vcore alto e 95W) e l'XFR nei casi reali praticamente non fa mai andare la CPU a 3.6 ma di più, perchè la Tj è più bassa (50-80) e il Vcore è giusto...

Addirittura può succedere che, con XFR attivato, facendo un leggero undervolt la frequenza media raggiunta si alzi, perchè il chip scalda meno...

Non c'è un grafico simile sul 14nm Intel?
Vorrei capirci meglio. Mi spiegate alcuni punti? Perchè cerco di fare un confronto con i proci Intel di equiparazione efficienza/frequenza.

@digieffe
che Zen possa essere 3.6 base, 4.2 turbo max (prima che la linea del consumo s'impenni)

Questo rapprresenterebbe per te la situazione di massima frequenza nell'efficienza di contenere un Zen X8+8 sui 95W, sbaglio?

Facendo una correlazione con Intel, sarebbe come il 6900K con le frequenze def e un TDP inferiore del def perdendo la features dell'FP 256bit, cioè 3,2GHz base e 3,7GHz turbo max.

Però se ribaltassimo il confronto unicamente sulla frequenza massima commerciabile, come sarebbe la considerazione su Zen?

Un 7700K che consuma quanto un 6900K per +1GHz ma -50% di core, la curva di efficienza silicio/frequenza l'ha lasciata molti MHz prima...

I 180W sui 4,6GHz, come li consideri? Su X8+8? Perchè se Zen spegnesse il 2° CCX, nella condizione massima frequenza su un funzionamento core simile al 7700K, riuscirebbe ad ottenere i 4,6GHz come X4+4 sui 90W (180W / 2) con un discreto margine sui 95W def.

Cioè... se partiamo con 3,6GHz X8+8 95W e 4,6GHz X8+8 180W, si avrebbe pure una posizione intermedia di Zen X8+8 ~4,1GHz nei 140W (visto che saremmo sempre QUASI in una retta), e questo tornerebbe al discorso che feci tempo fa... cioè Zen 95W confronto 6900K 95W alle stesse frequenze possibile se il 6900K non utilizza la FP 256bit.
Nel momento che il 6900K utilizzerebbe la FP 256bit, aumenterebbe le prestazioni, ma aumenterebbe pure il TDP (non più 95W come nel confronto vs Zen, ma utilizzerebbe tutto il TDP def, cioè 140W), e quindi equiparando un Zen allo stesso TDP (140W), non avrebbe più 3,6GHz (95W) ma 4,1GHz (140W)... e se una FP a 256bit risultasse +15% prestante (ovviamente nei 360° di utilizzo), ma Zen a parità di TDP aumenterebbe del 15% la frequenza, non ci sarebbe alcun svantaggio per Zen.
Zen TOP dovrebbe avere un TDP configurabile su cui l'XFR dovrebbe "adeguarsi", porterebbe Zen a funzionare a frequenze diverse proporzionato al TDP configurato.

[bjt2]

Originariamente inviato da cdimauro

Non è così per Skylake. A pag. 32 del manuale delle ottimizzazioni Intel c'è lo schema, e si può vedere che la DSB (Decoded Icache. La cache uop) è indipendente dalla L1I. Al più, com'è ovvio che sia, riceve le uop dai decoder, che ovviamente sono collegati alla L1I.

Ma in generale la IDQ (Instruction Decode Queue aka micro-op cache) riceve indipendentemente le uop da: MSROM (uop-ROM. max 4uop/ciclo), IDQ (uop-cache. max 6 uop/ciclo), e decoder (max 5 uop/ciclo). Quindi in totale può (molto) teoricamente ricevere max 15 uop/ciclo.

Per cui lo schema riportato dal sito giapponese risulta sbagliato.

Questo è opinabile. Il fatto che siano molto dense, vuol dire anche che sono molto lunghe, perché le istruzioni x86 sono lunghe fino a 15 byte, nella mia esperienza (nonché statistiche raccolte. Vedi sotto) non è difficile incontrare istruzioni particolarmente lunghe.

Dal binario della beta pubblica di Photoshop CS6. x86/32 bit:

Instructions: 1631136    Size: 5268115
Sizes:
  Size      Count
     3     389004
     2     387011
     1     298078
     5     190084
     6     140620
     4     123149
     7      95177
    10       4660
     8       2407
    11        829
     9        117

e x64/64 bit:

Instructions: 1638505    Size: 7056925
Sizes:
  Size      Count
     3     352175
     5     330286
     4     252766
     2     237364
     8     165612
     7     122134
     1      91535
     6      68408
     9       9209
    10       3480
    11       3257
    12       1997
    13        126
    14         89
    15         67

Punterei l'attenzione sul codice a 64 bit, che ormai è il più diffuso a livello mainstream.

Come si può vedere, non sono affatto rare istruzioni che occupino anche 8 byte, e dunque la macro-op dovrà necessariamente avere abbastanza spazio per contenere tutte le informazioni. Ma se la mappatura è 1:1 con un'istruzione x86/x64, allora immagino che le macro-op siano costituite da 15-16 byte, che è davvero tanto.

Per cui bisogna vedere quante di queste macro-op possano essere contenute nell'apposita cache.

Beh, questa non è certo una cosa nuova: ne avevo/amo parlato proprio su AnandTech.

Però vedi sotto.

Su Intel queste istruzioni non occupano spazio nella uop-cache, ma soltanto nella uop-queue.

Questo in genere non avviene nelle uop-cache Intel, a parte per alcune precise istruzioni (non ricordo quali adesso) che hanno bisogno di essere divise in 2 uop.

Questo avviene nella fase di register-rename sugli Intel, se c'è un rename per l'appunto.

Ma non mi è chiaro come possano essere eliminate le uop su Zen. Anche perché nello schema si vede che la micro-op queue (e dunque non la uop-cache) passa il controllo allo stack engine e/o (ma suppongo sia soltanto "o") alla ROM del microcodice, per poi riconvogliare il flusso da queste/a unità direttamente al dispatcher.

Nei processori Intel le istruzioni fused occupano già 1 solo slot, perché arrivano così direttamente dal decoder (max 2 istruzioni fused per ciclo di clock).

Per quelle microcodificate, e in accordo con quanto abbiamo già discusso anche qui, mi aspetto che occupino un solo slot / macro-op, e che la uop-queue si occupi poi di generare al volo le uop da eseguire, dandole in pasto al dispatcher (vedi sopra per maggiori dettagli, quando ho parlato dello stack engine).

Purtroppo il collo di bottiglia è già rappresentato dal solo fatto che devi decodificare le istruzioni x86/x64 a lunghezza variabile, che occupa una notevole porzione del decoder.

Purtroppo c'è non poca confusione in merito, a causa delle macro-op e micro-op.

La cache dovrebbe essere relativa alla macro-op, conservando quindi i benefici che ne derivano (maggior densità, visto che una macro-op può contenere fino a 2 uop, oppure una uop che punta alla uop ROM).

La coda, invece, dovrebbe essere relativa alle micro-op (come viene etichettata negli schemi), e dunque le macro-op a questo punto sarebbero già state espanse.

Siccome la uop-queue è PRIMA del dispatcher, vuol dire che il dispatcher NON si occupa dell'espansione delle macro-op in micro-op. Come peraltro sembra trasparire dallo schema.

Vorrei capire dove starebbe questa correlazione di cui parli.

Per il resto le uop di Intel sono effettivamente molto più piccole. Infatti le istruzioni più complesse fanno uso di almeno un paio di uop, all'interno della cache, che fanno entrambe parte della stessa istruzione.

A questo punto le cose importanti da chiarire sono due: quante entry ci sono nelle cache (macro-op per Zen, e uop per Intel). E quante entry ci sono nella coda (DOVREBBERO essere uop per entrambi qui. Vedi sopra).

Secondo il giapponese le uop dovrebbero essere 1to1 fino al dispatch escluso. Li dove è fatta l'espansione del microcodice e la cancellazione delle uop stack dovrebbero essere espanse anche le uop.

Per quanto riguarda la grandezza delle uop CISC è solo una questione di spazio occupato. Tanto la granulairà della cache sarà sempre 6 o 8 uops 8come o poco più di SKL) e quindi la logica sarà complessa quasi uguale.
Ma comunque i bit necessari a tutte le uop non penso siano molto più di 10-12 e un bit per dire se è un indirizzo nella microcode rom. Nel Tanembaum si faceva anche l'esempio di una microcode rom con i primi indirizzi occupati dalle prime uop di tutte le istruzioni così da usare pochi bit per specificare l'entry point e poi ogni uop nella microcode rom specifica esplicitamente la successiva così da poter fare salti ad ogni uop. Ma in ogni caso penso che 2048/4096 uop nella microcode rom dovrebbero bastare: sono poche le istruzioni che richiedono 200 e più uop... La maggior parte meno di 10-20...

[Ryddyck]

Qualche dettaglio in merito alle mobo am4 gigabyte https://www.youtube.com/watch?v=l9gmgOuxN8k
ed msi https://www.youtube.com/watch?v=5eLCpTNosmM
Ryzen builds https://www.youtube.com/watch?v=DNozsbA_X1w

[paolo.oliva2]

http://www.pcgameshardware.de/AMD-Ze...aunch-1217647/

Se non l'ha postato nessun'altro

è possibile overcloccare ogni processore Ryzen ma solo su mobo che lo permettono, cioè quelle su Chip-set X370 e X300, le altre no.

Il che si dovrebbe tradurre che non sia tanto esclusiva del chip-set, quanto invece la parte alimentazione della mobo è dimensionata al TDP def 95W e quindi....

Oggi internet sembra andare bene e quindi mi sono fatto una carellata di forum stranieri, soprattutto dell'est. Ammazza come si scannano... qua noi sembriamo la domenica in chiesa a confronto... ma su basi allucinanti che sono talmente idiote da nemmeno riportare.

[Ryddyck]

Da eliminare <-

[Ryddyck]

X370, x300 e b350

[OEidolon]

Originariamente inviato da paolo.oliva2

http://www.pcgameshardware.de/AMD-Ze...aunch-1217647/

Se non l'ha postato nessun'altro

è possibile overcloccare ogni processore Ryzen ma solo su mobo che lo permettono, cioè quelle su Chip-set X370 e X300, le altre no.

Il che si dovrebbe tradurre che non sia tanto esclusiva del chip-set, quanto invece la parte alimentazione della mobo è dimensionata al TDP def 95W e quindi....

invece mi sa che la prima discriminante sia proprio il chipset, per come hanno presentato le diverse versioni con le loro caratteristiche. La sezione di alimentazione a quel punto è una conseguenza.
se non fosse esclusiva del chipset non avrebbe senso indicare "overclocking" nella scheda dei chipset, vedi primo link qua sotto, e soprattutto nel secondo link alla voce overclocking c'è lo status "unlocked/Locked" che mi pare lasci intendere abbastanza bene le intenzioni (da notare anche il "Features enabled through our chipset" - "caratteristiche abilitate attraverso i nostri chipset").

http://core0.staticworld.net/images/...02363-orig.jpg

http://core0.staticworld.net/images/...02364-orig.jpg

leggendo QUA mi sono fatto l'idea che la discriminante del chipset orientato all'overclock sia dovuta più allo sfruttamento del famoso XFR oltre che ad una progettazione più accurata per la sezione di alimentazione.

Vedo che viene dato molto risalto alla connotazione dei vari chipset come concetto di "feature aggiuntive rispetto alla base data dalla CPU", quindi l'overclock (tramite XFR) come funzionalità non accessibile con i prodotti di fascia bassa (dove solitamente l'utente non si dedica a smanettamenti).

Cioè un concept di prodotto del tipo (mi permetto di semplificare molto, abbiate pazienza):
"mobo enthusiast" > "deve permettere OC" > "XFR" > x370/300/b350 > "alimentazione adeguata"
"mobo base" > "OC è inutile/non serve" > "no XFR" > a320/300 > "alimentazione base"

A questo punto il limite all'OC in fascia alta sarebbe dato dall'alimentazione, in fascia bassa il limite all'OC sarebbe dato dal mancato supporto allo stesso (anche se visto il target è un non-problema).