[Thread Ufficiale] Aspettando ZEN

[cdimauro]

Originariamente inviato da bjt2

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

Dal K10, secondo Agner Fog.

il fastpath double è necessario per le istruzioni splittate (128 bit su bobcat e 256 su BD/jaguar),

Sì, l'avevo riportato.

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.

Certamente, ma ci sono anche casi opposti: istruzioni che su Intel sono semplici uop, oppure fused-uop, che nei processori AMD sono microcodificate.

Questo per dire che se andiamo ad analizzare le differenze istruzione per istruzione, ce ne sono tante a favore di AMD, come pure tante a favore di 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...

A partire da Haswell, se non ricordo male.

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...

OK, ma è ovvio che sia così: non sarebbero decoder 4-1-1-1 altrimenti.

Comunque bisogna vedere nella realtà quale mix di istruzioni viene macinato dalla processore, e IMO è probabile che la stragrande maggioranza delle istruzioni sia di tipo semplice.

[tuttodigitale]

Originariamente inviato da cdimauro

Allora non porta alcun contributo a livello puramente prestazionale.

non porterebbe alcun contributo. Il fatto che oltre checkpoint, non sappiamo altro. Potresti aver ragione.

Originariamente inviato da cdimauro

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

articolo interessante, ma una domanda altrettanto interessante quali prestazioni un i7 6600u avrebbe dentro uno smartphone?

A livello di ipc il piccoletto è abbastanza impressionante. Ma k12 sarà tutt'altra cosa a livello di throughput per core, anche se l'ipc potrebbe anche essere peggiore.

[tuttodigitale]

Originariamente inviato da bjt2

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

il fetch di 32 byte in BD, è condiviso tra i 2 core..

c'è stata una regressione da questo punto di vista da k10.

Originariamente inviato da cdimauro

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.

da skylake c'è il 4-1-1-1-1

Originariamente inviato da cdimauro

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).

5 istruzioni per ciclo

http://www.intel.com/content/www/us/...on-manual.html
pagina 32

[Ren]

32byte fetch in Bobcat

http://image.slidesharecdn.com/bobca...?cb=1306859804

Decoder e micro-op

http://image.slidesharecdn.com/bobca...?cb=1306859804

[tuttodigitale]

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

dresdenboy copia le mie teorie......su quanto sia vantaggioso ridurre il fo4 con i finfet.
tuttavia, nel caso in questione, non ne farei una questione di efficienza, sarebbe a dir poco miracolo che nvidia con un +40% di clock, rispetto alle sue vecchie GPU e su Polaris, avesse creato un ulteriore gap in efficienza...

D'altra parte basta vedere l'andamento dell'assorbimento, per rendersi conto che in Polaris mancano le ottimizzazioni viste in Fiji. AMD è partita semplicemente dal progetto più snello per fare quello complicato. solo il tempo (la disponibilità effettiva della gtx1060) ci dirà se AMD ha fatto la scelta giusta.

[cdimauro]

Originariamente inviato da tuttodigitale

non porterebbe alcun contributo. Il fatto che oltre checkpoint, non sappiamo altro. Potresti aver ragione.

In base a quello che hai riportato tu, dovrebbe trattarsi di una caratteristica di tipo RAS, e dunque non impattare sulle prestazioni (anzi, in questi casi avviene il contrario, in genere).

articolo interessante, ma una domanda altrettanto interessante quali prestazioni un i7 6600u avrebbe dentro uno smartphone?

Inferiori, per contenere ulteriormente i consumi, visto che quel processore viene usato per ben altro (notebook high-end).

D'altra parte è l'A9 che equipaggia l'iPhone, mentre nell'articolo in questione si parla dell'A9X, che non troviamo in un notebook, ma in un tablet.


In quest'ultimo caso sarebbe meglio prendere uno Skylake Core-M come riferimento.

A livello di ipc il piccoletto è abbastanza impressionante. Ma k12 sarà tutt'altra cosa a livello di throughput per core, anche se l'ipc potrebbe anche essere peggiore.

Dubito che AMD scelga di seguire la strada di Apple con un processore 6-wide, che è molto diverso da tutte le altre implementazione di ARMv8, molto più complicato (basti vedere le dimensioni) e orientato al single core/thread.

Apple ha investito vagonate di soldi per questo design proprietario che si distingue nettamente da tutti gli altri, mentre AMD, come sappiamo, non naviga in buone acque da tempo.

Originariamente inviato da tuttodigitale

da skylake c'è il 4-1-1-1-1

5 istruzioni per ciclo

http://www.intel.com/content/www/us/...on-manual.html
pagina 32

Visto. Quindi Agner Fog ha riportato dei dati sbagliati nel suo manuale, per questo dato, mentre i 16 byte/ciclo per il fetch sono corretti.

Originariamente inviato da Ren

32byte fetch in Bobcat

http://image.slidesharecdn.com/bobca...?cb=1306859804

Decoder e micro-op

http://image.slidesharecdn.com/bobca...?cb=1306859804

Molto utile quest'ultima slide, perché dà dei numeri precisi sull'uso di MOP single, double, e microcodice.

Solo che mi pare che, a occhio, i dati si discostino molto dalla tabella all'appendice B del manuale 47414 - "Software Optimization Guide for AMD Family 15h Processors", che parte da pagina 244, e per la quale vedo sostanzialmente lo stesso numero di istruzioni fastpath double e microcodificate, per lo meno per Bulldozer.

A occhio, come ho detto, per cui non sono dati precisi, ma scorrendo l'impressione è quella. E dunque sono ben meno dell'1%. D'altra parte ci sono microcodificate pure nuove e utili istruzioni (per i campi di bit, ad esempio).

[bjt2]

Originariamente inviato da cdimauro

OK, ma è ovvio che sia così: non sarebbero decoder 4-1-1-1 altrimenti.

Comunque bisogna vedere nella realtà quale mix di istruzioni viene macinato dalla processore, e IMO è probabile che la stragrande maggioranza delle istruzioni sia di tipo semplice.

SI... Volevo dire che se INTEL ha 2 istruzioni a 2 uop consecutive, le decodifica in 2 cicli separati, invece AMD se ha 2 istruzioni consecutive con 2 MOP, le decodifica assieme in un ciclo...

Originariamente inviato da cdimauro

A occhio, come ho detto, per cui non sono dati precisi, ma scorrendo l'impressione è quella. E dunque sono ben meno dell'1%. D'altra parte ci sono microcodificate pure nuove e utili istruzioni (per i campi di bit, ad esempio).

Alcune istruzioni in AMD possono essere microcodificate perchè non previste quando fu fatto il core RISC, quindi non esistono uop per implementarle efficientemente... BD è un progetto vecchio... Piuttosto che non implementarle, le faccio microcodificate...

[tuttodigitale]

su k12, l'ha detto il capo-progettista che k12 ha un motore più grande di ZEN, con questo penso che alludeva proprio al numero di decoder.

Apple è partita con un know how striminzito rispetto AMD...la quale ha profonde conoscenze anche sul SMT


fonte: Intel

[tuttodigitale]

sui bench in questione ho non poco perplessità...
la navigazione internet, secondo anandtech, scala fino a 8 thread. E in quel test Bapco , non c'è differenza tra una dual core a8 e un tri-core a8x...la verità credo che sia nel mezzo...con un core M migliore, ma senza esagerare.

[Roland74Fun]

Scuate l'ingenuità.
Perché tanto riserbo sulla nuova piattaforma? Pensano che la concorrenza potrebbe copiarli?

[paolo.oliva2]

A livello teorico...

Oggigiorno un notevole incremento di potenza del core sarebbe possibile unicamente abbandonando la zavorra compatibilità X86.... ma visto che questo non è possibile, a me sembra che incrementi tangibili di IPC ci sono solamente in occasione di implementazione di nuovi set di istruzioni (es AVX vs core senza AVX, AVX2 ecc...).

Leggendo i post, tipo le differenze su Intel/AMD, tipo quanti istruzioni possono essere risolte a ciclo o su n cicli, il dubbio che mi viene è quanto poi effettivamente questo si traduca nella realtà, perchè se poi la sequenza elaborativa dipende da più risultati da concatenare assieme, anche una velocità doppia di una parte alla fine potrebbe significare incrementi quasi nulli nell'insieme.

Anche poi l'SMT, visto come SMT2, 4 8, ecc., ha un limite ben definito (100% del core) e quindi alla complessità di un core + SMT8 sarebbe preferibile quella di 2 core con SMT "normale".

Ma sti cacchi di proci con 1000 core della grandezza di un X6 + SMT normale... come funziano? Perchè a me sembra che la corrente sia quella di realizzare un core prestazionalmente inferiore (ma anche notevolmente più piccolo) ma poggiando su una miriade di sti core, è come se si avesse un SMT a n vie ma in realtà, al posto di avere una parte che "tiene" i dati per farli elaborare nella stessa parte logica di quel core, avrebbe a disposizione un core "tutto suo".

[capitan_crasy]

Originariamente inviato da Roland74Fun

Scuate l'ingenuità.
Perché tanto riserbo sulla nuova piattaforma? Pensano che la concorrenza potrebbe copiarli?

Seguo AMD da prima dei K8 e c'è sempre stato il riserbo su piattaforme/CPU in fase di sviluppo, ma questo è una cosa normale anche per le altre aziende...

[cdimauro]

Originariamente inviato da bjt2

SI... Volevo dire che se INTEL ha 2 istruzioni a 2 uop consecutive, le decodifica in 2 cicli separati, invece AMD se ha 2 istruzioni consecutive con 2 MOP, le decodifica assieme in un ciclo...

Vero: i decoder sono più flessibili. Ma è realmente importante? Se guardi il grafico che ha postato tuttodigitale, direi no.

Ed è sicuramente il motivo per cui Intel è passata dal primo decoder 4-1-1 all'ultimissimo 4-1-1-1-1 di Skylake: evidentemente il codice fa uso di configurazioni che sono digeribilissime da questo tipo di decoder.

Non potrebbe essere altrimenti, visto che ormai da tantissimi anni il codice è generato da compilatori che ottimizzano tenendo conto di parecchie variabili, fra cui questa.

Tutte cose che incidono in tutti i sensi (complessità del progetto, transistor impiegati, consumi, prestazioni) sulla realizzazione della microarchitettura, e che emergono da uno studio più approfondito. Infatti certe scelte che a primo acchito sembrerebbero strane, diventano lampanti e oserei direi, riflettendo su tutte queste cose.

Com'è anche chiaro che, pur avendo fini comuni e usando tante volte soluzioni simili, gli ingegneri di AMD e Intel hanno, in generale, filosofie estremamente diverse nella realizzazione dei rispettivi progetti.

Ed è anche un bene che sia così: è la diversità che porta al progresso, sperimentando soluzioni innovative. Anche quando queste portano a fallimenti, c'è sempre qualcosa da imparare per fare poi meglio.

Alcune istruzioni in AMD possono essere microcodificate perchè non previste quando fu fatto il core RISC, quindi non esistono uop per implementarle efficientemente... BD è un progetto vecchio... Piuttosto che non implementarle, le faccio microcodificate...

Certo, è normale che sia così.

Comunque BD ha radici profonde nei precedenti progetti, e sicuramente fin dai vecchi Athlon, tant'è che nel manuale per le ottimizzazioni AMD s'è lasciata sfuggire parecchie volte i termini DirectPath e VectorPath, che ormai sono stati sostituiti da fastpath single/double e microcode.

Inoltre anche se BD è un progetto vecchio (ma nemmeno tanto, alla fine), non vuol dire che sia tutto da buttare. Infatti non penso proprio che la codifica di MOP & uop, nonché la loro esecuzione, sia radicalmente cambiata coi suoi successori. Tutt'altro. E penso che anche Zen continuare a portarsi dietro buona parte di BD e predecessori. Semplicemente certe cose non ha alcun senso buttarle vie, a meno che non decidi di tentare una strada completamente diversa, riscrivendoti tutto; ma i costi sarebbero troppo elevati, e l'azzardo potrebbe non pagare.

Originariamente inviato da tuttodigitale

su k12, l'ha detto il capo-progettista che k12 ha un motore più grande di ZEN, con questo penso che alludeva proprio al numero di decoder.

Considerato il target, propendo per una maggior integrazione di porte di esecuzione e/o maggiori cache e/o BTC, ecc. ecc.

Apple è partita con un know how striminzito rispetto AMD...la quale ha profonde conoscenze anche sul SMT

Non te lo lascerei dire. Anni fa Apple acquisì PASemi e Intrinsity, che non erano certo formate da sprovveduti, soprattutto per la prima azienda.

Per non parlare di Keller, che è stato lì per parecchi anni.

fonte: Intel

Ottimo. Questo conferma il perché Intel si "ostini" a proseguire sulla strada dei decoder 4-1-1*: perché le conviene così, grazie al tipo di codice che usualmente si macina.

Tanti bei transistor risparmiati, e consumi ridotti.

Originariamente inviato da tuttodigitale

sui bench in questione ho non poco perplessità...
la navigazione internet, secondo anandtech, scala fino a 8 thread. E in quel test Bapco , non c'è differenza tra una dual core a8 e un tri-core a8x...la verità credo che sia nel mezzo...con un core M migliore, ma senza esagerare.

Alla fine sono sempre benchmark, ma almeno non sintetici come Geekbench, che non serve a nulla.

Comunque non so cosa intendesse AnandTech, ma il parsing delle pagine web è un processo single core/thread. E' il rendering che può essere scaricato dalla CPU alla GPU, ma in questo caso si stressa la GPU, per l'appunto. Ma la cosa più importante è che ormai Javascript domina nel web, e la sua VM è rigorosamente single core/thread. Sono state proposte delle estensioni per i cosiddetti "worker", e dunque introducendo finalmente un minimo di multithreading/processing, ma non mi pare siano state ratificate nello standard. Soprattutto, e ben più importante, richiederanno la scrittura di apposito codice per poter essere sfruttate, con tutte le implicazioni che ne derivano (ogni riferimento alla parallelizzazione del codice non è affatto casuale ).

Dunque ho anch'io i miei (forti) dubbi, ma sulle affermazioni di AnandTech.

Originariamente inviato da paolo.oliva2

A livello teorico...

Oggigiorno un notevole incremento di potenza del core sarebbe possibile unicamente abbandonando la zavorra compatibilità X86....

No. L'aspetto cosiddetto "legacy" è trascurabile, specialmente con miliardi di transistor ormai integrati nei chip.

ma visto che questo non è possibile,

In ogni caso non si potrebbe buttare tutto il codice già esistente.

a me sembra che incrementi tangibili di IPC ci sono solamente in occasione di implementazione di nuovi set di istruzioni (es AVX vs core senza AVX, AVX2 ecc...).

Vero: e meno male che è rimasto questo!

Ma anche qui sorge il problema di cui parlavo prima: la parallelizzazione / vettorizzazione del codice, che non è affatto banale, QUANDO ciò è possibile, e con un certo costo.

Detto in altri termini, se il compilatore ha buone abilità di autorizzazione, allora va bene. Altrimenti la strada è tutta in (ripida) salita.

Leggendo i post, tipo le differenze su Intel/AMD, tipo quanti istruzioni possono essere risolte a ciclo o su n cicli, il dubbio che mi viene è quanto poi effettivamente questo si traduca nella realtà, perchè se poi la sequenza elaborativa dipende da più risultati da concatenare assieme, anche una velocità doppia di una parte alla fine potrebbe significare incrementi quasi nulli nell'insieme.

Non so cosa intendi con quest'ultima parte. Non mi è chiaro. Potresti fare un esempio?

Anche poi l'SMT, visto come SMT2, 4 8, ecc., ha un limite ben definito (100% del core) e quindi alla complessità di un core + SMT8 sarebbe preferibile quella di 2 core con SMT "normale".

L'adozione di modelli SMT > 2 ha senso in ambito server / HPC, dove ti puoi permettere di "diluire" i calcoli spalmandoli su più core / thread hardware, e alla fine raccogliere i risultati.

In quello consumer no, perché la latenza / tempo di risposta è molto importante.

Ma sti cacchi di proci con 1000 core della grandezza di un X6 + SMT normale... come funziano? Perchè a me sembra che la corrente sia quella di realizzare un core prestazionalmente inferiore (ma anche notevolmente più piccolo) ma poggiando su una miriade di sti core, è come se si avesse un SMT a n vie ma in realtà, al posto di avere una parte che "tiene" i dati per farli elaborare nella stessa parte logica di quel core, avrebbe a disposizione un core "tutto suo".

Funzionano che vanno bene per server & HPC, mentre in ambito consumer sarebbero sfruttati sempre pochissimi core.

[Ren]

Originariamente inviato da cdimauro

Non te lo lascerei dire. Anni fa Apple acquisì PASemi e Intrinsity, che non erano certo formate da sprovveduti, soprattutto per la prima azienda.

Per non parlare di Keller, che è stato lì per parecchi anni.

Quando vedi i miglioramenti del twister A9 (+35% ipc) c'è solo da togliersi il cappello.

http://www.anandtech.com/show/9686/t...-plus-review/4

Apple fa paura con i suoi miliardi...

[cdimauro]

Se parti da frequenze basse, e col nuovo processo produttivo hai un notevole boost, non è nulla di eccezionale.

Fermo restando che per il gran lavoro svolto già con l'A8 è normale che poi Apple stia capitalizzando i frutti del buon design.

[Ren]

Originariamente inviato da cdimauro

Se parti da frequenze basse, e col nuovo processo produttivo hai un notevole boost, non è nulla di eccezionale.

Fermo restando che per il gran lavoro svolto già con l'A8 è normale che poi Apple stia capitalizzando i frutti del buon design.

Hai visto di quanto è sceso il branch misspredict (9stadi ) ?

Più 35%(specint) di media di solo IPC, senza considerare il clock.

[cdimauro]

Visto adesso. Oltre alla pipeline più corta, hanno aumentato le unità d'esecuzione e triplicato la L2.

Notevole.

EDIT: la L3 è stata rimossa solo su l'A9X.

[tuttodigitale]

Originariamente inviato da cdimauro

Non te lo lascerei dire. Anni fa Apple acquisì PASemi e Intrinsity, che non erano certo formate da sprovveduti, soprattutto per la prima azienda.

l'acquisizione per soli 300 milioni di euro dovrebbe far riflettere sul differente know-how tra PASemi ed AMD.
Di certo in pochi anni hanno fatto un ottimo lavoro . Ma la domanda era perchè AMD non sarebbe in grado di fare una CPU ARM 6-wide. con ben 4 anni di sviluppo all'attivo? Paura?
Per quanto mi sforzi mi pare un poco improbabile che AMD non sia in grado di fare molto meglio di Apple

Sui sintetici di quel tipo, ho sempre espresso le mie perplessità...finchè non si capisce bene cosa faccia sembrano davvero inutili, e fuorvianti...comunque non devi dirmelo tu che un core m, fa piazza pulita di ogni altra CPU...invero anche il semplice Atom per molte architetture ARM (tutte le altre) fa paura, anche se molti fanno finta di non vedere (c'è di mezzo anche il fatto che 9 volte su 10, non vengono customizzate)

[tuttodigitale]

Originariamente inviato da cdimauro

Per non parlare di Keller, che è stato lì per parecchi anni.

jim keller era il vice presidente del PASemi, ed è stato per 4 anni...in AMD è arrivato nel Agosto 2012- e ha finito nel Novembre 2015....direi che basta e avanza (ricordo che è stato Chef Architect per un solo anno in AMD, si vede che XV ha necessitato di ben più cure di k7 ).
il fatto che AMD abbia pensato addirittura di posticipare ZEN per k12, mi fa pensare che k12 sia una cpu degna di nota (come se non bastasse il ritorno alla lettera K nel nome in codice...)

[paolo.oliva2]

@Ren

Quello che intendevo con più istruzioni elaborate a ciclo è che se prendiamo come dato 2 elaborazioni a ciclo vs 1 elaborazione a ciclo, il risultato sarebbe +100%, ma su un arco di 10 cicli un +100% solo in un ciclo e gli altri 9 uguale, l'incremento sarebbe solamente di 11 istruzioni vs 10, se poi ci aggiungessimo un discorso di elaborazione parallela su più core dove si dovrebbe aspettare il risultato di un core, l'impatto alla fine sarebbe di un guadagno ancora inferiore...

Chiaro che meno cicli per risolvere un'istruzione è meglio, ma bisogna vedere tutto il complesso. Per fare un altro esempio, PD non risolve le AVX2 nativamente, in quanto supporta solamente le AVX, quindi facendo una comparazione PD vs XV solamente su velocità sulle AVX2, XV risulterebbe avere un'IPC mostruoso, probabilmente del 50-60% superiore a PD, mentre se specificatamente solamente AVX risulterebbe avere incrementi marginali. Poi è chiaro che in media avrebbe 15-20% in più XV su PD per tutte le altre migliorie.

Comunque Zen per andare quanto 2 8350 in combinata ad un incremento di IPC ~+65% (valutando +40% o >+40% su XV come dichiarato da AMD), il clock dovrebbe essere ~=>3,7GHz. Ma nel caso di un SMT >+30%, è ovvio che basterebbe una frequenza inferiore. Zen con un margine di +40% su XV, comunque in ST necessiterebbe di una frequenza ridicola turbo per pareggiare XV... perchè 100 +40% = 140, già con Zen con -29,5% di frequenza rispetto a XV, riuscirebbe ad ottenere la stessa potenza ST, e e 4,3GHz XV -30% = 3GHz... se il 14nm GF non riuscirebbe manco ad arrivare a 3GHz in turbo....

Non è che faccio un discorso di bandiera... cerco solamente di capire quali siano le possibilità dell'architettura Zen per ottenere quanto AMD dichiarato ufficialmente da AMD con PP silicio differenti e differenti possibilità architetturali.