[Thread Ufficiale] Aspettando ZEN

[paolo.oliva2]

Originariamente inviato da bjt2

Il silicio non mura a X GHz... E' sempre l'architettura. Se facevi una architettura con FO 13 (<17) come la z di IBM, salivi di più, e infatti la z arriva a 5.5Ghz.

Io volevo dire (poi magari mi dici se è corretto ), che ogni PP silicio può avere frequenze differenti a parità di FO4, quindi il silicio A ipoteticamente 3,5GHz e il silicio B 4,5GHz.
Ad esempio, l'architettura Phenom II aveva un suo FO4 e sul 45nm arrivava a 3,7GHz. Llano non può aver cambiato FO4, in quanto stessa architettura, però sul 32nm ha perso frequenza rispetto al 45nm.
L'architettura BD, con FO4 17, ovviamente a parità di TDP ha ottenuto una frequenza superiore, ma non è arrivata alla frequenza come da aspettativa in quanto il PP 32nm permetteva una frequenza inferiore rispetto al 45nm.

Quindi secondo me il PP può pregiudicare la scelta (e il guadagno) della scelta di quale FO4 sia migliore su quel PP silicio.
Cioè se faccio una scelta di FO4 basso e poi mi ritrovo un PP scarso, perdo molto di più che un FO4 più alto a parità di TDP.

[fabius21]

Originariamente inviato da Bivvoz

Nessuno mi toglierà mai la convinzione che BD è nato per essere integrato con GCN, non solo nelle APU intese come CPU + iGPU ma come oggetto da utilizzare sempre unito nel calcolo eterogeneo, insomma il loro HSA.
Infatti dopo Vishera si sono concentrati solo sulle APU.

Ma poi HSA è più o meno andato alla deriva e hanno virato su Zen.
Io però spero che HSA sia solo stato messo in attesa di tempi miglior e che Zen, ma sopratutto Raven Ridge sarà ancora compatibile.

Anche io penso che sia così , la compatibilità è già abilitata da un pò di tempo, e anche zen se vogliamo ha quell'impronta, ora spetta al software , e i passi li stan facendo, ora non so a che punto siano però vanno avanti, ho in mente un piccolo progetto e sto studiando/testando su linux , di conseguenza si capita negli archivi delle mail-list e le si legge e si riesce a capire le news , che ci sono e ci saranno sperando che sia nel futuro prossimo.

[bjt2]

Originariamente inviato da tuttodigitale

usando il traduttore di google, in pratica spiega le slide...ma il nostro bjt2 ha già fatto il lavoro e non ho trovato nulla di nuovo, se non il fatto che ZEN esegue in maniera diretta le micro-op fusion...
Questo ovviamente prendetelo con il beneficio del dubbio.

passo la parla a bjt2

https://translate.google.it/translat...ml&prev=search

L'avevo già letta ieri (qualcuno su semi o anand l'aveva postato)... In inglese si capisce meglio.
Non ho scritto nulla perchè non c'è niente di nuovo o interessante. In sostanza dice quello che sapevamo già e fa il confronto con le architetture INTEL sopratutto sui salti. Zen ne può fare 2 per ciclo anche sullo stesso thread ed ha 6 pipeline separate dalle FP contro INTEL (ma questo già lo sapevamo). INTEL poteva fare un salto per ciclo fino a SKL/KBL esclusi. Ma siccome la porta era condivisa anche con istruzioni FP, hanno deciso in SKL/KBL di introdurre la porta 6 ad uso esclusivo di istruzioni intere semplici e salti. INTEL può fare 2 salti per ciclo solo se:
1) La porta 0 non serve per altre istruzioni intere (questo anche in zen succede) o FP (questo in zen non può succedere... )
2) uno dei due salti è non preso

Non si sa se su zen ci sono limitazioni di sorta, ma comunque anche SKL non può farne sempre due per ciclo.

Poi c'è una conferma interessante sul branch fusion: una volta fuse le due istruzioni (penso a livello di decoding?) occupano sempre un posto dappertutto (code, uop cache, esecuzione, retirement). Questo è interessante perchè non era detto che fosse così. Non so se intel fa altrettanto, ma anche se fosse, siamo alla pari con zen, perchè non si può fare di meglio.

Originariamente inviato da paolo.oliva2

Io volevo dire (poi magari mi dici e è corretto ), che ogni PP silicio può avere frequenze differenti a parità di FO4, quindi il silicio A ipoteticamente 3,5GHz e il silicio B 4,5GHz.
Ad esempio, l'architettura Phenom II aveva un suo FO4 e sul 45nm arrivava a 3,7GHz. Llano non può aver cambiato FO4, in quanto stessa architettura, però sul 32nm ha perso frequenza rispetto al 45nm.
L'architettura BD, con FO4 17, ovviamente a parità di TDP ha ottenuto una frequenza superiore, ma non è arrivata alla frequenza come da aspettativa in quanto il PP 32nm permetteva una frequenza inferiore rispetto al 45nm.

Quindi secondo me il PP può pregiudicare la scelta (e il guadagno) della scelta di quale FO4 sia migliore su quel PP silicio.
Cioè se faccio una scelta di FO4 basso e poi mi ritrovo un PP scarso, perdo molto di più che un FO4 più alto a parità di TDP.

Allora. Il FO4 che tu citi è quello relativo. Quello assoluto si ottiene moltiplicando per il FO4 assoluto di processo. AMD si aspettava un FO4 assoluto molto più basso per il 32nm. Un BD implementato sul 45nm sarebbe comunque andato più lento. Per salire di clock hanno sacrificato, troppo, l'IPC. Ma comunque con XV sono riusciti ad avere un IPC decente, segno che se ci si mettevano dall'inizio, potevano far uscire BD così sul 32nm. Avrebbe avuto maggiore IPC, consumato meno e sul 32nm probabilmente avrebbero potuto avere qualcosa in più di turbo... Invece di 4/4.3 a 125W avrebbero potuto avere 4.2/4.6 (+5% clock) con un ipc del +15% senza L3. Aggiungici la L3 (perchè BD ce l'ha) ed avevi un BD con un +25% in più di prestazioni rispetto ad adesso, che se la poteva giocare meglio, sopratutto in MT.

Se poi l'AVFS e DVFS funzionavano bene sul 32nm, poteva scapparci anche qualche MHZ in più...
Insomma... BD non era da buttare...

[mack.gar]

Originariamente inviato da tuttodigitale

aspetta il 40% ST è riferito con il confronto con XV, che da alcuni test sembrerebbe andare con carico ST circa il 15% più di PD...
ergo 40+15=61%...oltre il 50% su PD è in linea con le aspettative, non è superiore.

Poi dalla review di canard in verità non si può capire molto....se facessimo un analisi delle prestazioni senza tener conto dell'inevitabile peggioramento dello scaling a salire del numero di thread, un core+smt ZEN uscirebbe con le ossa nei confronti di un modulo XV, clock to clock...

prendiamo i numeri riferiti ai test sulla conversione video e rendering:

Zen 168
FX8350 105
a12-9800 57

a parità di frequenza nominale(3,15GHz per ZEN, 4 GHz Fx8350, e 3,8GHz a12-9800)
ZEN x8 356
FX8350 175
a12-9800 100

a parità di thread e frequenza
core ZEN+smt 89
modulo XV 100
modulo PD 88

da una analisi, per forza di cose superficiale, come questa le cose non stanno esattamente come dici...anzi direi che sia da escludere alquanto che un core ZEN+smt vada il 35% più di un intero modulo PD, a parità di frequenza.

Come ho già risposto a Paolo, ho sbagliato
Cmq nella preview di canard affermano esplicitamente (mi pare) che dalle loro prove è gli risulta circa il 35℅ in MT, almeno è quello che si ripete in giro. Poi, ovviamente, dovremo aspettare i test delle versioni retail per avere delle certezze. In ogni caso il famoso 40% sembra un "più di" che un "in media".

[cdimauro]

Originariamente inviato da tuttodigitale

sei fortemente incoerente.
hai detto più volte che Intel aveva presentato qualcosa di simile a BD con netburst, ma si è dovuta scontrare con l'impossibilità di raggiungere certe frequenze.

Penso di essere stato il primo in questo thread a sottolinearne le similitudini a livello micro-architetturale, nonché problematiche.

Ma vorrei sapere dove starebbe l'incoerenza di cui parli, visto che non ho mai negato che il Pentium 4 sia stato un flop da questo punto di vista (sebbene Northwood sia stato un buon processore di per sé), considerato che le speranze di Intel di arrivare entro il 2010 a 10Ghz con quest'architettura siano state del tutto disattese. E penso che difficilmente troverò qualcuno, anche qui, che possa sostenere qualcosa di diverso.

Dunque dovrei essere incoerente perché affermo che BD sia un flop, sostanzialmente sulle stesse basi? E in quale universo parallelo? Uno a logica negata?

Znext una architettura con un FO4 decisamente basso, e le tessi le lodi, ma allo stesso tempo critichi AMD che avrebbe sbagliato a puntare con una architettura ad alta frequenza..nonostante sia più conservativa da questo lato

puoi spiegare perchè Znext, che è pò come il Prescott confrontato con bulldozer che è un pò come northwood, sia l'architettura AMD a rappresentare il fallimento della corsa ai GHz come fu Prescott?

Prescott, come già detto in passato, fu il canto del cigno di NetBurst, di cui Intel aveva già decretato la fine, per far posto all'architettura Banias/Core.

Premesso questo, riporto un po' di dati (presi un po' da questa presentazione; qui si trova la copia con la cache di Google, se il link originale risulta inaccessibile, come stamattina. Gli altri li ho presi da Agner. Oppure wikipedia per comodità, alle rispettive pagine, perché non ho tempo di fare altre ricerche. Idem per quelli che mancano: se interessano, qualcuno potrebbe recuperali e integrarli) che smentiscono quanto hai scritto sopra. E lo faccio prendendo anche z196, il predecessore di zNext/z12/zEC12, che era a 45 nm, per metterli a confronto.

     u/Arch  Ghz  FO4  nm    die size     transistor   core  stadi pipeline consumo
       z196  5.2   16  45  512.30 mm2  1.40 miliardi      4           15-17   300W?
      zEC12  5.5   16  32  597.24 mm2  2.75 miliardi      6           15-17   300W?
   PhenomII  3.7    ?  45  258.00 mm2  0.76 miliardi      4             12?    125W
      Llano  3.0    ?  32  228.00 mm2  1.18 miliardi      4             12?    100W - APU! Non direttamente confrontabile con gli altri causa iGPU.
  Bulldozer  4.2   17  32  315.00 mm2  1.20 miliardi      4           15-22    125W
    Nehalem  3.1  20?  45  263.00 mm2  0.73 miliardi      4             19?     95W
    Nehalem  3.3  20?  45  263.00 mm2  0.73 miliardi      4             19?    130W
   Westmere  3.2  20?  32       ? mm2  0.73 miliardi      4             19?     95W
   Westmere  3.6  20?  32       ? mm2  0.73 miliardi      4             19?    130W
SandyBridge  3.9  20?  32  216.00 mm2  1.00 miliardi      4             19?     95W
SandyBridge  3.8  20?  32  216.00 mm2  1.00 miliardi      4             19?    130W

Ho integrato anche alcuni processori Intel, per completezza, perché penso che i dati possano essere comunque interessanti.

Ovviamente il focus rimane su z196 e zEC12 (zNext), dove mi pare che il passaggio sia piuttosto eloquente: +5% di clock, +50% core, e +25% in ST (questo dato lo riporto dai precedenti documenti), ma soprattutto A PARITA' DI FO4.
Ed è bene anche sottolineare che il FO4, al contrario di quel che si diceva, NON è piccolo, ma perfettamente comparabile con quello di Bulldozer.
Altra cosa importante è che la pipeline non sia affatto lunghissima, ma anche qui confrontabilissima con quella di Bulldozer.

C'è bisogno che aggiunga qualcosa o ti rendi conto da solo della portata dei dati che ho riportato? E spero che apprezzerai il lavoro di ricerca che ho fatto, che mi ha portato via non poco tempo.

secondo me, il problema del SOI, non riguarda il leakage, anche perchè sarebbe un fallimento clamoroso del HKMG (il fatto che Znext giri a 5,5GHz toglie qualsiasi dubbio, imho), ma il consumo dinamico causato da vcore più alti. Non credo che sia un caso se thuban con l'azoto liquido ha fatto registrare 1GHz di frequenza in più di llano, con vcore in entrambi i casi prossimi ai 2V. Sui vcore più alti abbiamo almeno due indizi...entrambe dichiarazioni ufficiali di AMD, una sulla frequenza/vcore della cache l3 di BD, l'altra sulla frequenza/vcore di k10..puntualmente disattesi 4 dati su 4....

quello che sto dicendo, cosa ti assicura, che i miglioramenti di Znext non siano dovuti alla riduzione della corrente di leakage, enorme a quelle frequenze, più che ad un alquanto improbabile, visti i risultati tutt'altro che esaltanti ottenuti con le soluzioni llano/piledriver nel mobile, ad una forte riduzione del consumo dinamico?

Se c'è una cosa che dimostra Znext, che almeno sul SOI, una architettura ad altissima frequenza non era qualcosa di infattibile....

Assolutamente, ma zNext (e predecessori) hanno anche power budget ben lontani da ciò che sostenibile in ambito desktop o anche enthusiast.

Io non so se il problema di Bulldozer sia dovuto al vcore, al consumo dinamico, al FO4, o qualunque altra diavoleria.

So, però, quel che IBM è riuscita a fare con lo stesso processo produttivo e stesso budget che, come detto anche altre volte, è un invariante: IBM produce da sempre processori per fasce alte di mercato, con costi / transistor / die / consumi molto più elevati rispetto a roba consumer. E mi pare che i dati parlino da soli.

Originariamente inviato da OEidolon

Cesare scusa, cercando nei vecchi post ho trovato questo:


dato che c'è qualcosa che non mi torna/convince ho spulciato un po', però nel bilancio linkato non trovo la frase che ho evidenziato in blu, puoi darmi un riferimento più preciso su dove trovarla? O magari è in unaltro pdf che avevi linkato (ma di cui non riesco a trovare il post dove è linkato)?

EDIT: come non detto, trovato!

Grazie per aver riportato il mio commento coi dati su IBM.

Originariamente inviato da riuzasan

Non è incoerente.
E' fazioso ma vuol passare per esperto superparte.

Ma quanto rosichi, eh? D'altra parte dopo tutte le batoste che hai preso, è ovvio che ti bruci ancora, e che approfitti miseramente di qualche occasione per sfogare le tue frustrazioni, riversando il tuo veleno per appagare il tuo ego violato.

Cresci.

Del resto oggi, secondo qualcuno, conta il SingleTread sul mercato, non il MultiTread

Chi l'avrebbe detto questo? Quote e link, cortesemente, così da verificare. Grazie.

Nel mentre, ringraziamo AMD per aver riportato un poì di concorrenza in un mercato piatto e stagnante da anni, con buona pace di chi ci guadagnava sopra quel mercato monopolista de facto.

Da quando hai a disposizione i dati ufficiali / definitivi di RyZen?

O devo presumere che dalle tue parti le sfere di cristallo siano a buon mercato...

[bjt2]

http://imgur.com/VXf2s1t

A guardare questa splendida immagine, Zen offre, come linee pciex e altro I/O, più della piattaforma 1151, ma meno, ovviamente della 2011... Se costa come la 1151, è un vero uovo di colombo...

[the_joe]

Una domanda tecnica e forse non banale, dato che Intel nelle ultime CPU ha integrato le istruzioni per la codifica/decodifica hardware dei flussi video in h.265 e credo che Ryzen non le integri, è possibile che una volta che i programmi le supporteranno Ryzen resti molto distanziato in questo campo?

Sarebbe importante capirlo perché la codifica/decodifica video è uno dei settori che stressa di più le cpu che però se fatta in hardware è supportata da cpu molto economiche come quelle dei vari TV-Box che si trovano in vendita a 30$ completi, mentre se fatto via software stressa al limite anche i processori più prestanti da centinaia di €, il fatto di supportarle in hardware potrebbe essere un bel passo avanti per Intel o no?

[bjt2]

Originariamente inviato da cdimauro

Premesso questo, riporto un po' di dati (presi un po' da questa presentazione; qui si trova la copia con la cache di Google, se il link originale risulta inaccessibile, come stamattina. Gli altri li ho presi da Agner. Oppure wikipedia per comodità, alle rispettive pagine, perché non ho tempo di fare altre ricerche. Idem per quelli che mancano: se interessano, qualcuno potrebbe recuperali e integrarli) che smentiscono quanto hai scritto sopra. E lo faccio prendendo anche z196, il predecessore di zNext/z12/zEC12, che era a 45 nm, per metterli a confronto.

     u/Arch  Ghz  FO4  nm    die size     transistor   core  stadi pipeline consumo
       z196  5.2   16  45  512.30 mm2  1.40 miliardi      4           15-17   300W?
      zEC12  5.5   16  32  597.24 mm2  2.75 miliardi      6           15-17   300W?
   PhenomII  3.7    ?  45  258.00 mm2  0.76 miliardi      4             12?    125W
      Llano  3.0    ?  32  228.00 mm2  1.18 miliardi      4             12?    100W - APU! Non direttamente confrontabile con gli altri causa iGPU.
  Bulldozer  4.2   17  32  315.00 mm2  1.20 miliardi      4           15-22    125W
    Nehalem  3.1  20?  45  263.00 mm2  0.73 miliardi      4             19?     95W
    Nehalem  3.3  20?  45  263.00 mm2  0.73 miliardi      4             19?    130W
   Westmere  3.2  20?  32       ? mm2  0.73 miliardi      4             19?     95W
   Westmere  3.6  20?  32       ? mm2  0.73 miliardi      4             19?    130W
SandyBridge  3.9  20?  32  216.00 mm2  1.00 miliardi      4             19?     95W
SandyBridge  3.8  20?  32  216.00 mm2  1.00 miliardi      4             19?    130W

Ho integrato anche alcuni processori Intel, per completezza, perché penso che i dati possano essere comunque interessanti.

Ovviamente il focus rimane su z196 e zEC12 (zNext), dove mi pare che il passaggio sia piuttosto eloquente: +5% di clock, +50% core, e +25% in ST (questo dato lo riporto dai precedenti documenti), ma soprattutto A PARITA' DI FO4.
Ed è bene anche sottolineare che il FO4, al contrario di quel che si diceva, NON è piccolo, ma perfettamente comparabile con quello di Bulldozer.
Altra cosa importante è che la pipeline non sia affatto lunghissima, ma anche qui confrontabilissima con quella di Bulldozer.

C'è bisogno che aggiunga qualcosa o ti rendi conto da solo della portata dei dati che ho riportato? E spero che apprezzerai il lavoro di ricerca che ho fatto, che mi ha portato via non poco tempo.

Assolutamente, ma zNext (e predecessori) hanno anche power budget ben lontani da ciò che sostenibile in ambito desktop o anche enthusiast.

Io non so se il problema di Bulldozer sia dovuto al vcore, al consumo dinamico, al FO4, o qualunque altra diavoleria.

So, però, quel che IBM è riuscita a fare con lo stesso processo produttivo e stesso budget che, come detto anche altre volte, è un invariante: IBM produce da sempre processori per fasce alte di mercato, con costi / transistor / die / consumi molto più elevati rispetto a roba consumer. E mi pare che i dati parlino da soli.

Le architetture IBM hanno 300W di TDP... AMD con 220W è arrivata a 4.7/5, non distante dai 5.5Ghz. Ma con 8 core e non 6. Mi dirai che i 6 core di IBM sono sicuramente più complessi ed hanno IPC più alto. Ma sono 6 contro 8 e 300W contro 220. Inoltre ho letto in giro che BD non sale per colpa della L2 condivisa tra i 2 core e quindi il FO4 basso è un po' sprecato per quello.
In ogni caso se sali a 300W di TDP e seghi 2 core, forse ci arrivi a 5.2, anche se non a 5.5... Ma ripeto, sembra sia colpa della L2...

[newtechnology]

Originariamente inviato da the_joe

Una domanda tecnica e forse non banale, dato che Intel nelle ultime CPU ha integrato le istruzioni per la codifica/decodifica hardware dei flussi video in h.265 e credo che Ryzen non le integri, è possibile che una volta che i programmi le supporteranno Ryzen resti molto distanziato in questo campo?

Sarebbe importante capirlo perché la codifica/decodifica video è uno dei settori che stressa di più le cpu che però se fatta in hardware è supportata da cpu molto economiche come quelle dei vari TV-Box che si trovano in vendita a 30$ completi, mentre se fatto via software stressa al limite anche i processori più prestanti da centinaia di €, il fatto di supportarle in hardware potrebbe essere un bel passo avanti per Intel o no?

Ma tu per far funzionare Ryzen ci dovrai mettere una VGA giusto?!?! Ti sei già risposto da solo.

I Tv-Box che dici te infatti sono degli all-soc come una apu ed è la igp che gestisce il flusso, ma zen non avendo igp sarà la VGA esterna a fare da encoding.
PS. I box da 30€ gestiscono il flusso h265 come mia nonna... X un h265 buono c'è ne vogliono almeno 150€

[cdimauro]

Originariamente inviato da paolo.oliva2

Io non perdo il mio tempo a guardare i bilanci delle aziende... al limite guardo i listini delle offerte.

Ed è meglio che rimanga ai soli listini allora, ed eviti di riportare cose prive di senso, perché sono proprio i bilanci che non vuoi leggere che ti smentiscono.

Nessuna falsità, tu hai detto che Intel fa la sua scaletta e se ne frega di quello che fa AMD.

Quando mi farai vedere che Intel ha cambiato un progetto in corso a causa della concorrenza, ti stenderò il tappeto rosso.

Il che per me non lo è, perchè nella sua scaletta può impostare una miniaturizzazione silicio ed una architettura in una data X, che può anticipare se la ditta Y offre un'alternativa migliore. Invece per te non cambia... però mi devi spiegare il perchè un 6950X inesistente è comparso dopo che AMD parlava di Zen... sarà che probabilmente chi presentava il programma gli era caduto un foglio... unica spiegazione.

Non ho alcuna difficoltà a credere che tu creda che un'azienda come Intel tiri fuori dal cilindro e COMMERCIALIZZI (Q2 2016) un processore con 10 core quando, all'epoca, di Zen non esisteva nemmeno uno straccio di benchmark.

Continua pure a vivere nel tuo universo parallelo.

No.... dai, non mi dire... al massimo si sforza di abbassare i prezzi... sai... io Zen lo chiamerei Gutalax, ottimo lassativo per sforzarsi di meno.

Non sei buono nemmeno a fare delle battute. Caliamo un velo pietoso.

Infatti il mondo ha cdimauro come stella polare...

Non cercare di cambiare discorso e farmi passare come il cattivone di turno: sei tu che spari balle colossali su cose di cui non hai la benché minima comprensione.

Come t'ho suggerito già diverse altre volte, evita, che è meglio. Limitati a quello che, da commerciante, dovresti saper fare: parlare di listino prezzi.

O delle toppe? Visto che delle righe più in basso per te non sono evoluzioni quelle di BD ma toppe.

Le toppe si mettono ai pantaloni bucati: segno che c'è qualche PROBLEMINO da risolvere.

Ti risulta che Nehalem abbia avuto problemi?

Magari soltanto a te, visto che in generale è considerata l'architettura che ha ridato in mano a Intel la leadership microarchitetturale nonché prestazionale. Robuccia da sue soldi, eh!

Comunque visto che abbiamo un esperto in materia, saresti così gentile da farmi vedere di quali "toppe" avesse bisogno Nehalem?

Con la concorrenza ferma al 32nm/28nm, anche se ci metti sterco equino sul silicio verrebbe meglio.

Westmere prima e SandyBridge poi erano "casualmente" anche loro a 32nm. Ma NON mi pare che sfigurassero. Tutt'altro.

Certo, considerato il disastro Bulldozer, Intel avrebbe benissimo potuto campare di rendita, specialmente con SB (che ha introdotto le AVX e FPU a 256 bit), ma come sua natura ha deciso di continuare a migliorare, ove possibile, la sua microarchitettura.

Ma stai scherzando? Da un bilancio evidenzi il costo di un procio?
Magari pure la percentuale dei fallati

I dati che ho riportato parlano chiaro. Per chi li capisce o li vuol capire, ovviamente.

Non ricominciare sempre con le offese..

Dove si configurerebbe l'offesa? Perché ho parlato di frustrazioni?

Tu hai bisogno di una buona ripassata anche alla lingua italiana.

sono stato buono, ho accettato, ma nel mio discorso non c'è nulla di fanboysmo se difendo BD che mi piace come architettura e per te esiste solamente Intel.

E' la cieca difesa di un prodotto, come BD nel tuo caso, anche di fronte all'evidenza, che ti etichetta come fanboy.

Poi continui a mistificare: mai detto che esista solo Intel. Ma è evidente che ormai sei andato fuori i binari e cominci a inventarti cose che non esistono pur di accampare qualche ragione.

Quindi abbi la cortesia di ACCETTARE l'opinione degli altri SENZA OFFENDERE e ricorda che tu sei entrato nel TH con la scusa di difendere l'onore di Intel (LADRA), non di attaccare chiunque non la pensi come te in nome del Dio Intel.

Le offese non esistono, e se non ti è chiaro questo è un forum di discussione, e il fatto che tu possa dire la tua NON vuol dire che altri non possano replicare a quello che hai scritto.

Il resto si configura come lo sfogo di un fanboy, con annesse invenzioni di attacchi e divinità varie.

Su, rilassati, che non t'ho toccato la mammina.

Per me BD era una architettura onesta, senza tante pretese, gambizzata dal silicio, questa è la mia idea e punto. Tu hai un'altra idea? Tieniti la tua idea. Io scrivo la mia e continuerò a scrivere la mia, senza che tu mi attacchi e mi dai del fanboy, è chiaro? Usa il rispetto e avrai rispetto, manca di rispetto e ti mancherò di rispetto, e abbi la cortesia di evitare questi post lunghi da insegnate che corregge i compiti, perchè se ancora non l'hai capita, non lo vuole nessuno e se a te viene da fare così, bisogna che a cambiare sei tu, non tutto il TH per te.

In tal caso mettimi pure in ignore list e vivi felice, ma come già detto come tu hai libertà di parola, ce l'ho pure io, e posso replicare alle balle che scrivi.

E continuerò a parlare... non è il TUO TH e personalmente io non pendo dalle tue labbra e non devo chiedere il permesso a te per scrivere quello che penso, ti è abbastanza chiaro?

Chiarissimo. E a te è abbastanza chiaro che continuerò a replicare ove lo riterrò opportuno?

E vai con le solite frecciatine da fanboy Intel... Non si chiamano toppe, sono evoluzioni.

In cosa sarei un fanboy? Per caso mi sono inventato delle cose di sana pianta? Davanti a certi fatti, per caso li ho negati? Su, fammi pure un elenco di cose per cui dovrei essere considerato un fanboy.

Invece guarda cosa riesce a dire un "fanboy" Intel:
- Netburst è stata un flop;
- l'Athlon prima e Athlon64 poi è stato superiore ai P3 e ai primi P4;
- Intel è stata giustamente condannata per concorrenza sleale;
- Intel è stata giustamente condannata per non aver riportato nella documentazione il comportamento dei suoi compilatori.

Adesso passiamo ai fanboy AMD:
- BD è stato un fl... fl.... flll.... flllllllll.

Niente da fare, non ci si riesce proprio. Per maggiori informazioni sull'argomento consultare: https://www.youtube.com/watch?v=pZmGRnFXsX8

Ma dai, hai letto i bilanci pure di GF... ma non è meglio che fai il commercialista?

Fammi capire: i clienti di GF avrebbero deciso di passare dai 32nm ai 28nm perché masochisticamente amano pagare di più i loro chip?

Ti dirò, il problema è tuo, certamente non mio. Ricordati che sono in Africa... la banda la devo centellinare su quello che a mia discrezione reputo più importante.

Stupenda scusa, da uno che scrive papiri interminabili dalla mattina a notte inoltrata, ed è continuamente a caccia di informazioni anche su siti che sono noti per il click bait.

Certo, certo: tranquillo che ti credo, eh!

Io ho scritto che a parità di IPC INIZIALE, quindi un procio CMT perderebbe un 10% in ST e guadagnerebbe un 50% in MT verso lo stesso procio ma SMT. Se fai un procio con 2.500.000 transistor, in cui l'SMT richiede il 10% in più di transistor e il CMT il 20%, non credo che tra 2.750,000 transistor e 3.000.000 la differenza sia "esosa" di transistor, al più dipende da chi lo produrrà.

La realtà è che AMD ha buttato sul suo CMT una VAGONATA di transistor (vedi i numeri nel box che ho scritto a tuttodigitale), quando l'SMT di Intel ha dato mediamente risultati nettamente migliori sia in ST sia in MT.

E i link che ho postato in passato sui numerosi test che sono stati fatti all'epoca, servivano a prenderne atto. Poi, ripeto, se uno non vuole leggere i dati REALI e continuare a parlare astrattamente di SMT, CMT, tirando fuori percentuali (su cosa? I dati li ho riportati, per l'appunto)... beh, sono affari suoi.

Originariamente inviato da digieffe

Paolo non capisco la parte in grassetto

interpretando correttamente termini impropri e concetti espressi male, il ragionamento dà una buona idea di cosa è accaduto...

ovviamente, Cesare, che non ha seguito i thread precedenti né conosce bene il modo di "improprio" esprimersi di Paolo, contesterà quanto sopra sulla base di equivoci espressivi ed interpretativi...

Stamattina se io avessi avuto un po' di tempo te lo avrei disambiguato prima di innescare un "pippone" dei soliti, purtroppo sono di cerimonia e devo scappare...

Cesare, cortesemente evita di dare risposte "polemiche", soprattutto alle argomentazioni sulle quali ci possa essere anche un minimo dubbio interpretativo, grazie.

La parte che hai evidenziato riguarda frequenze e previsioni, sulle quali dovresti già sapere bene come la penso, visto che NON mi esprimo.

Per cui non capisco perché tu abbia scritto questo commento e messo le mani avanti.

Originariamente inviato da Crysis90

Basta guardare la situazione finanziaria di AMD oggi e l'andamento del titolo in borsa da Gennaio 2012 in poi...
I dubbi personali sono un conto e possono essere del tutto soggettivi, mentre il verdetto del mercato è indiscutibile.

*

Originariamente inviato da Capozz

Paolo, io capisco il tuo discorso però, a prescindere dal silicio, non ho mai capito la scelta di AMD di puntare ad un'architettura che prevedeva un basso livello di IPC da compensare con un'elevata frequenza di funzionamento. E' una soluzione che non funziona, loro stessi qualche anno prima diedero sonore batoste ai Pentium 4 con gli Athlon 64, anche se lavoravano a frequenze molto più basse.

*

Originariamente inviato da paolo.oliva2

Però abbiamo delle differenze di fondo, il CMT di per sè non ha alcun bisogno di intervenire sull'IPC del core, in quanto il 2° TH ha una parte INT tutta propria e condivide unicamente l'FP, mentre l'SMT, proprio perchè il guadagno sul 2° TH è basso, richiede un aumento dell'IPC del core altrimenti non "renderebbe".

L'SMT non richiede un aumento dell'IPC: non esiste questo concetto.

L'SMT richiede un aumento delle PORTE di esecuzione a disposizione dei thread hardware, perché se le condividono, e le prestazioni dei singoli thread ovviamente ne risentirebbero.

A parità di porte a disposizione (e di altro: cache, ad esempio), l'SMT è mediamente di gran lunga più efficiente del CMT, perché dalla teoria delle code è dimostrato che una coda unica in grado di servire contemporaneamente 2 clienti è meglio di due code specializzate in grado di servirne solo uno alla volta, visto che in quest'ultimo caso una delle code potrebbe benissimo rimanere ferma / inutilizzata.

E' qui il punto, secondo me. AMD ha scelto il CMT semplicemente perchè non ha speso nulla o veramente poco nel potenziare l'IPC a monte,

Veramente ha speso un quantità spropositata di transistor: vedi sopra.

BD rappresenta un'implementazione economica del CMT, basata su delle aspettative silicio svanite...

BD è costato un patrimonio ad AMD in termini di transistor e di un die ENORME rispetto alla concorrenza. Ancora una volta, vedi sopra.

Originariamente inviato da Roland74Fun

Super quoto! Sennza SSD un utente inesperto non noterebbe la differenza tra un Atom ed i7 5960X.

Adesso non esageriamo.

Ho un primissimo netbook con Atom, un sub-notebook con AMD C50, e uno i7 6700K, tutti dotati di SSD, e tutti con Windows 10 x64.

Indovina chi dei tre arriva alla schermata iniziale in 3 secondi, e quali impiegano 20-30 secondi.

E questo solo per il boot. Poi possiamo anche parlare di aprire il browser, navigare, leggere la posta con GMail (che è un pachiderma), aprire Facebook, ecc.: non c'è proprio storia...

[cdimauro]

Originariamente inviato da bjt2

Le architetture IBM hanno 300W di TDP... AMD con 220W è arrivata a 4.7/5, non distante dai 5.5Ghz. Ma con 8 core e non 6. Mi dirai che i 6 core di IBM sono sicuramente più complessi ed hanno IPC più alto. Ma sono 6 contro 8 e 300W contro 220. Inoltre ho letto in giro che BD non sale per colpa della L2 condivisa tra i 2 core e quindi il FO4 basso è un po' sprecato per quello.
In ogni caso se sali a 300W di TDP e seghi 2 core, forse ci arrivi a 5.2, anche se non a 5.5... Ma ripeto, sembra sia colpa della L2...

E quindi non del silicio. Vogliamo ammetterlo una buona volta?

La colpa è del DESIGN di AMD: come LEI ha deciso di utilizzare il budget di transistor a disposizione.

P.S. Sì, i core dell'architettura Z sono dei mostri. E' un'architettura estremamente complessa, ben più di x86: più di mille istruzioni, e molte decisamente complesse. Ergo: silicio a volontà per implementarle.

[riuzasan]

Originariamente inviato da cdimauro

Ma quanto rosichi, eh? D'altra parte dopo tutte le batoste che hai preso, è ovvio che ti bruci ancora, e che approfitti miseramente di qualche occasione per sfogare le tue frustrazioni, riversando il tuo veleno per appagare il tuo ego violato.

Cresci.

Chi l'avrebbe detto questo? Quote e link, cortesemente, così da verificare. Grazie.

Da quando hai a disposizione i dati ufficiali / definitivi di RyZen?

O devo presumere che dalle tue parti le sfere di cristallo siano a buon mercato...

Bimbo, crescere dovrebbero dirtelo a te.
Scendi dal piedistallo, perchè la puzza di snob interessato si sente ad un chilometro.
Continui a blaterare banalità su compilatori ed emulatori a cui ad oggi anche su progetti complessi basta uno scafesso processore da 50$ per essere compilati e/o utilizzati in una manciata di secondi (basta vedere gli incredibili e ridicoli esempi che hai addottto, il che ci porta a chiederci come mai Intel ha licenziato una barca di gente, in questo anno).
Blateri di essere un super partes ma, se ti si fa notare che da quello che si è visto fin'ora finalmente potrebbe esistere una competizione migliore nel mercato X86, continui a INVENTARTI tu che non c'è, non esiste, non è possibile etc etc
Caro di mauro, un po mi vergogno a pensare che gente nata sui testi di Ciucci per programmare in assembler su amiga, sia tutta felice di sperare faziosamente in un altro flop di AMD, in un mercato dove di concorrenti ce ne dovrebbero essere almeno 3 seri.
Per il resto, buona fortuna. Vedo che le basi ci sono.

[cdimauro]

Originariamente inviato da riuzasan

Bimbo, crescere dovrebbero dirtelo a te.
Scendi dal piedistallo, perchè la puzza di snob interessato si sente ad un chilometro.

Continua pure, visto che non hai altro a cui aggrapparti.

Continui a blaterare banalità su compilatori ed emulatori a cui ad oggi anche su progetti complessi basta uno scafesso processore da 50$ per essere compilati e/o utilizzati in una manciata di secondi (basta vedere gli incredibili e ridicoli esempi che hai addottto, il che ci porta a chiederci come mai Intel ha licenziato una barca di gente, in questo anno).

Se non sbaglio sono davanti alla prossima medaglia Fields: aspettiamo ancora che tu ci faccia vedere in che modo un emulatore, o un compilatore (su SINGOLO sorgente da processare), possa essere scritto in modo da sfruttare TUTTI i core a disposizione.

Blateri di essere un super partes ma, se ti si fa notare che da quello che si è visto fin'ora finalmente potrebbe esistere una competizione migliore nel mercato X86, continui a INVENTARTI tu che non c'è, non esiste, non è possibile etc etc

In tal caso sei liberissimo di QUOTARMI e portare i link ai miei commenti, onde DIMOSTRARE la tua tesi.

Che, in mancanza, rimarrà falsa come una moneta da 3 euro, e dunque le tue si configureranno come menzogne e mistificazioni.

Caro di mauro, un po mi vergogno a pensare che gente nata sui testi di Ciucci per programmare in assembler su amiga,

Gente chi? Non io.

Fabio Ciucci lo conosco e ci siamo scambiati anche e-mail in passato, ma la mia formazione sull'Amiga me la sono fatta in maniera indipendente da lui, su manuali di Motorola, Hardware Manual di Commodore, e riviste del settore.

Ovviamente se hai del materiale che possa dimostrare il contrario, anche qui sei liberissimo di postarlo.

sia tutta felice di sperare faziosamente in un altro flop di AMD,

Anche questo te lo sei inventato di sana pianta: mai detto nulla del genere. E, a contrario, diverse volte ho scritto che la concorrenza fa bene, e che non avrei alcun problema a scegliere un processore AMD se fosse compatibile con le MIE esigenze.

Questo, peraltro, l'ho scritto anche di recente, nero su bianco, e qui tanti possono testimoniare.

in un mercato dove di concorrenti ce ne dovrebbero essere almeno 3 seri.

Che dire: mettiti pure in affari. Rileva Via e portala ai livelli di Intel o almeno di AMD.

Per il resto, buona fortuna. Vedo che le basi ci sono.

Buona fortuna a te con la ricerca delle prove sulle balle che hai, ancora una volta, sparato. Perché nei hai tanto bisogno...

[Piedone1113]

Originariamente inviato da bjt2

Le architetture IBM hanno 300W di TDP... AMD con 220W è arrivata a 4.7/5, non distante dai 5.5Ghz. Ma con 8 core e non 6. Mi dirai che i 6 core di IBM sono sicuramente più complessi ed hanno IPC più alto. Ma sono 6 contro 8 e 300W contro 220. Inoltre ho letto in giro che BD non sale per colpa della L2 condivisa tra i 2 core e quindi il FO4 basso è un po' sprecato per quello.
In ogni caso se sali a 300W di TDP e seghi 2 core, forse ci arrivi a 5.2, anche se non a 5.5... Ma ripeto, sembra sia colpa della L2...

Secondo me sono diversi i fattori.
Non conosco il numero transistor dei core, ne la densità Dell area core.
Ma quello che ad occhio mi da da pensare è la cachemire l3.
Quella dei z è abbastanza veloce ma sopratutto ha 48 mb di l3.
Credo quindi che tutto il tdp dei core a 5.5 Ghz sia in parte compensata dalla enorme l3.

[george_p]

Originariamente inviato da cdimauro

E quindi non del silicio. Vogliamo ammetterlo una buona volta?

La colpa è del DESIGN di AMD: come LEI ha deciso di utilizzare il budget di transistor a disposizione.

P.S. Sì, i core dell'architettura Z sono dei mostri. E' un'architettura estremamente complessa, ben più di x86: più di mille istruzioni, e molte decisamente complesse. Ergo: silicio a volontà per implementarle.

Sarà, ma glofo aveva promesso con i 32 nm un ottima riduzione del consumo, che a me non pare mai esserci stata.
Se partiamo dal presupposto che il silicio glofo sia buono solo perché permette alte frequenze ok, ma per BD ci si è sempre riferiti anche al consumo.
Troppe incognite paragonando architetture diverse per costruttore e tipologia.
Llano stesso invece che consumi ha rispetto alla stessa architettura costruita a 45nm?

Con il suo silicio glofo prometteva un sensibile abbattimento dei consumi a parità di frequenza. Perché non si ragiona su questo, cercando di eliminare la parte grafica?
Forse si trovano risultati più coerenti per tipologia di architettura

Originariamente inviato da bjt2

Le architetture IBM hanno 300W di TDP... AMD con 220W è arrivata a 4.7/5, non distante dai 5.5Ghz. Ma con 8 core e non 6. Mi dirai che i 6 core di IBM sono sicuramente più complessi ed hanno IPC più alto. Ma sono 6 contro 8 e 300W contro 220. Inoltre ho letto in giro che BD non sale per colpa della L2 condivisa tra i 2 core e quindi il FO4 basso è un po' sprecato per quello.
In ogni caso se sali a 300W di TDP e seghi 2 core, forse ci arrivi a 5.2, anche se non a 5.5... Ma ripeto, sembra sia colpa della L2...

[cdimauro]

Originariamente inviato da bjt2

L'avevo già letta ieri (qualcuno su semi o anand l'aveva postato)... In inglese si capisce meglio.
Non ho scritto nulla perchè non c'è niente di nuovo o interessante. In sostanza dice quello che sapevamo già e fa il confronto con le architetture INTEL sopratutto sui salti. Zen ne può fare 2 per ciclo anche sullo stesso thread ed ha 6 pipeline separate dalle FP contro INTEL (ma questo già lo sapevamo).

Infatti, il contenuto è simile a quanto già lo stesso sito aveva riportato.

INTEL poteva fare un salto per ciclo fino a SKL/KBL esclusi. Ma siccome la porta era condivisa anche con istruzioni FP, hanno deciso in SKL/KBL di introdurre la porta 6 ad uso esclusivo di istruzioni intere semplici e salti.

No, già a partire da Haswell le uArch Intel possono eseguire due salti, e la porta 6 è dedicata esclusivamente all'ALU + branch. Ecco qui, dal solito AnandTech.

INTEL può fare 2 salti per ciclo solo se:
1) La porta 0 non serve per altre istruzioni intere (questo anche in zen succede) o FP (questo in zen non può succedere... )
2) uno dei due salti è non preso

Non si sa se su zen ci sono limitazioni di sorta, ma comunque anche SKL non può farne sempre due per ciclo.

Penso che sia normale: anche se puoi fare due salti, c'è una mutua dipendenza fra i due, legata al fatto che un singolo thread deve comunque portare avanti l'esecuzione sequenzialmente.

Poi c'è una conferma interessante sul branch fusion: una volta fuse le due istruzioni (penso a livello di decoding?) occupano sempre un posto dappertutto (code, uop cache, esecuzione, retirement). Questo è interessante perchè non era detto che fosse così.

Veramente ricordo che ne avevamo parlato. Ma magari mi sbaglio, eh! Non posso ricordare tutto quello che abbiamo scritto.

Non so se intel fa altrettanto, ma anche se fosse, siamo alla pari con zen, perchè non si può fare di meglio.

Sì, ovviamente le istruzioni fuse DEVONO essere trattate come singola uop fino alla fine: è proprio per questo motivo che esistono.

Originariamente inviato da the_joe

Una domanda tecnica e forse non banale, dato che Intel nelle ultime CPU ha integrato le istruzioni per la codifica/decodifica hardware dei flussi video in h.265 e credo che Ryzen non le integri, è possibile che una volta che i programmi le supporteranno Ryzen resti molto distanziato in questo campo?

Sarebbe importante capirlo perché la codifica/decodifica video è uno dei settori che stressa di più le cpu che però se fatta in hardware è supportata da cpu molto economiche come quelle dei vari TV-Box che si trovano in vendita a 30$ completi, mentre se fatto via software stressa al limite anche i processori più prestanti da centinaia di €, il fatto di supportarle in hardware potrebbe essere un bel passo avanti per Intel o no?

Il codec H265 fa parte della sezione video nei processori Intel, mentre Zen non ne ha una. Dunque penso che non ne abbia uno integrato.

Originariamente inviato da george_p

Sarà, ma glofo aveva promesso con i 32 nm un ottima riduzione del consumo, che a me non pare mai esserci stata.

In realtà GF era AMD stessa, visto che all'epoca quest'ultima era azionista, e il processo a 32nm l'aveva sviluppato proprio lei.

GF è il risultato della dismissione delle fonderie di AMD. Non è un'entità aliena a cui AMD s'era rivolta per soddisfare le sue esigenze.

Poi non so se AMD abbia promesso a sé stessa consumi minori sui 32nm.

Se partiamo dal presupposto che il silicio glofo sia buono solo perché permette alte frequenze ok, ma per BD ci si è sempre riferiti anche al consumo.
Troppe incognite paragonando architetture diverse per costruttore e tipologia.
Llano stesso invece che consumi ha rispetto alla stessa architettura costruita a 45nm?

Con il suo silicio glofo prometteva un sensibile abbattimento dei consumi a parità di frequenza. Perché non si ragiona su questo, cercando di eliminare la parte grafica?
Forse si trovano risultati più coerenti per tipologia di architettura

Le risposte le trovi nel lavoro che IBM ha fatto con z12, di cui ho riportato i dati nello schema della mia risposta a tuttodigitale.

Ed è un chiaro esempio di ciò che un'azienda può realizzare con lo stesso processo produttivo, ma decidendo di utilizzare il budget dei transistor in un modo anziché un altro.

[paolo.oliva2]

@Bjt2

Quando avevo l'8350 montato sulla Asrock 95W, mi sono trovato costretto a diminuire i core/undervoltare/undercloccare per far rientrare nei 95W l'8350, e ho notato delle cose "strane", ma non escludo che siano dovute all'alimentazione della Asrock (fascia mobo 35€), però mi sembra che avevo avuto le stesse info già precedentemente con le Asus.

A spannella, tensione occorrente per benchare:
4 moduli attivi 1,6V @5,2GHz (liquido ~200W/220W)
3 moduli attivi 1,55V @5,2GHz (liquido)
2 moduli attivi 1,55V @5,250GHz (liquido)
1 modulo attivo 1,55V @5,3GHz, muro 5,350GHz (dissi stock ~100W).

Il test su 1 modulo è fisso obbligatoriamente sul 0, in quanto non si può scegliere, l'opzione a 2 moduli e 3 li ho incrociati per vedere se c'erano differenze a livello di modulo, ma non le ho viste.

Ma disattivando 1 core a modulo per arrivare (esempio) sempre a 4 core, a liquido non avevo visto differenze di frequenza massima (discorso L2), ma ad aria un aumento marcato di temperatura.

A me è sembrato un comportamento a mo' di esplosione di leakage, più che limitazioni a livello di modulo.
Comunque l'8150, l'8350 e idem l'8370 hanno tutti comportamenti silicio in OC differenti. L'8150 dava molto di più l'impressione limite silicio, l'8350 più un muro 5,350GHz magari non architetturale ma dovuto al distanziamento transistor, l'8370 mi sembra la massima espressione TDP/frequenza con tutto fuorchè limiti architetturali...

Onestamente trovo incomprensibile il perchè sul 32nm/FX hanno cercato il massimo dal silicio ma trascurando completamente miglioramenti di efficienza architetturali, quali il turbo o cose simili.

[bjt2]

Originariamente inviato da cdimauro

E quindi non del silicio. Vogliamo ammetterlo una buona volta?

La colpa è del DESIGN di AMD: come LEI ha deciso di utilizzare il budget di transistor a disposizione.

P.S. Sì, i core dell'architettura Z sono dei mostri. E' un'architettura estremamente complessa, ben più di x86: più di mille istruzioni, e molte decisamente complesse. Ergo: silicio a volontà per implementarle.

Non mi ricordo di aver detto che non fosse colpa dell'architettura... E se l'ho fatto, ho detto una cazzata!
Sono d'accordo sul fatto che ha sprecato un po' di budget di transistor per il CMT e la mega cache. Il CMT poteva anche funzionare, ma il problema, dicono in giro, è la L2...

Comunque anche Zen dovrebbe avere un FO4 basso, altrimenti non si spiega il suo alto clock con TDP più contenuto di BWE... E vedremo dal turbo max definitivo (io non penso che sarà 4GHz, sono solo degli ES... Per test vari vanno bene anche solo 100MHz in più per ogni step) e dagli OC se effettivamente il FO4 è ai livelli di BD. A giudicare dal numero di stadi direi di si... Ma vediamo...

[cdimauro]

Non ce l'avevo con te. Se ti è parso così, mi scuso.

[bjt2]

Originariamente inviato da cdimauro

No, già a partire da Haswell le uArch Intel possono eseguire due salti, e la porta 6 è dedicata esclusivamente all'ALU + branch. Ecco qui, dal solito AnandTech.

Ah ok... Ero convinto che l'avessero fatto solo nel passaggio da 6 a 8 pipelines, visto che la porta 6 è la settima (la numerazione parte da 0)...

EDIT: visto ora che anche HSW ha 8 porte... Ero convinto ne avesse 6...

Originariamente inviato da cdimauro

Penso che sia normale: anche se puoi fare due salti, c'è una mutua dipendenza fra i due, legata al fatto che un singolo thread deve comunque portare avanti l'esecuzione sequenzialmente.

Si può anche fare un salto per thread per ciclo, eh!