[Thread Ufficiale] Aspettando ZEN

[tuttodigitale]

un processo LP, scadente in low-power. (hanno centrato l'obiettivo:p ) :sofico:

Pensa l'efficienza di nvidia se si accontenta degli 0.875v(1600-1750mhz), invece di cloccare a bestia...

cmq nessuno mi ha risposto, il 16nm tsmc ha varianti HP/HPL ?
Non sono mica io a dirlo...quando avrò finito (sto in questo momento scrivendo un pezzo su AM4, spero di non scordarmi nessun rumors degno di nota....), toccherà al processo produttivo.

[paolo.oliva2]

Se fosse vero, e se il controller fosse integrato, sarebbe un'ottima cosa che non avrebbe nemmeno SkyLake (non ce l'ha integrato nel chipset, bisogna aspettare kabylake, e quindi una volta fuori windows, per esempio con le livecd, non hai il 3.1).

Veramente Zen si sa già per certo che ha tutto integrato, a parte forse la parte sonora (e ovviamente l'iGPU), infatti è pure per questo che c'è l'aspettativa di prezzi mobo AM4 particolarmente bassi

[paolo.oliva2]

Purtroppo mi ciuccerei tutto il vantaggio di costi nel fatto che voglio ITX. Fin'ora di AMD fra l'altro si sono viste solo mobo ITX di cartapesta, e io ne voglio una diciamo almeno vera.

Sent from my HTC One M9 using Tapatalk

Invece la mia più grande paura è che facciano mobo AM4 95W pro BR e non idonee ad un OC 200W Zen.
Ma tu mette resti un Zen X8+8 su una ITX? Va bene che io vado per i 53 anni, comincio a non vedere una mazza e con condimento di goffaggine... però diventerei matto con tutti i miei cavi HD...

[bjt2]

Su anandtech è stata fatta chiarezza (alcune cose le sapevo anche io sbagliate) su tre tecnologie che sono in Polaris, che sono state introdotte nelle varie iterazioni di BD e che quasi sicuramente saranno integrate in Zen (c'è una quarta tecnologia che probabilmente funziona come scrivo qui):

BTC: boot time calibration. La CPU/GPU ha dei sensori per il Vcore. In fabbrica si determina il valore minimo, come misurato da quei sensori, per far funzionare il chip a quella frequenza e con un dato carico elaborativo. Ad ogni boot, il chip imposta il VID sui VRM e misura il Vcore effettivo. Poi apporta le correzioni affinchè il Vcore effettivo misurato, sia quello di fabbrica. La tecnologia di compensazione per l'invecchiamento, probabilmente cambia il Vcore target con il tempo, aumentandolo mano a mano che la parte invecchia. Questo fa si che non serva più il margine sul Vcore per compensare la variabilità delle schede madri, dei VRM e loro invecchiamento. In più questo fa durare di più una scheda madre, perchè se i vrm invecchiano e con il tempo abbassano il vcore, anche sotto carico, al boot questo è compensato e quindi finchè ci sono un certo numero di VRM funzionanti per erogare la corrente necessaria, il tutto funziona.

AVFS: contrariamente a quello che pensavo, l'AVFS varia la tensione in funzione delle condizioni di frequenza, temperatura e carico, in modo da avere la tensione minima necessaria al funzionamento del chip. E' l'ADAPTATIVE CLOCKING che abbassa temporaneamente il clock sui droop di tensione... Li confondevo sempre... L'AVFS invece fa qualcosa di diverso. Anche queste due tecnologie permettono di tenere il Vcore più basso.

[paolo.oliva2]

Sembra tutto per impedire l'OC.
Però la storia dell'invecchiamento è scientifica certamente, ma nella pratica... Ho un 8350 preso il primo giorno, l'ho tenuto sempre a 4,6GHz in Italia, ci ho fatto OC a 5,217GHz in bench, l'ho seviziato a più non posso come X4/X6, ed ancora è li funzionante, forse può essere un po' degradato (pensandoci un +0,025V forse li vuole, visto 1,425V per i 4,4GHz, ma con tamb equatoriale), però a parametri def ampiamente funzionante. Se questo dopo 5 anni (o più?) per come l'ho sfruttato io, va bene che deve durare...

[Roland74Fun]

Sarebbe una buona idea visto che il mio 8350 di stock ha un VID di 1,325 e vcore di 1,375.
L'ho abbassato step by step e funge perfettamente a 4.0 GHz con 1,28v (confermato da IBT Very High).
A 4,2 GHz, sempre stressato a dovere, sta con 1,345.

[bjt2]

Devo dire che all'atto pratico questa idea non ha funzionato un granché, si è già visto gente che downvolta e guadagna 30-35W e quindi maggiori performance.

La mia impressione è che la fase di testing sia un po' tirata via con il risultato che le tensioni di targa sono tutte sovrastimate.

Per ridurre il tempo di testing, il programma probabilmente proverà poche tensioni... La più bassa per cui va bene viene scritta nel BIOS. Se un chip è fortunello e non è stato testato più in basso, probabilmente è stato "etichettato" con un vcore superiore all'ottimale. Per ridurre il tempo di testing e contemporaneamente gli scarti, probabilmente quelle 2-3 tensioni che prova saranno altine...

[bjt2]

Sembra tutto per impedire l'OC.
Però la storia dell'invecchiamento è scientifica certamente, ma nella pratica... Ho un 8350 preso il primo giorno, l'ho tenuto sempre a 4,6GHz in Italia, ci ho fatto OC a 5,217GHz in bench, l'ho seviziato a più non posso come X4/X6, ed ancora è li funzionante, forse può essere un po' degradato (pensandoci un +0,025V forse li vuole, visto 1,425V per i 4,4GHz, ma con tamb equatoriale), però a parametri def ampiamente funzionante. Se questo dopo 5 anni (o più?) per come l'ho sfruttato io, va bene che deve durare...

Lo scopo è proprio per eliminare il margine. In passato si doveva mettere un vcore diciamo del +10% per compensare invecchiamento, vrm difettosi, tolleranze del VRM... ora invece in fabbrica si setta il vcore minimo che serve, senza il 10%di margine (magari con un 1-2%) , perchè tanto ci sono quelle 4 tecnologie che ho menzionato...

[paolo.oliva2]

http://www.hwupgrade.it/articoli/skvideo/4679/radeon-rx-480-amd-ridefinisce-le-schede-video-mainstream_14.html

Io mi sono letto l'articolo e sinceramente da un'idea nettamente differente.
In pratica, "ai listini odierni una GTX 1070 costa quanto 2 schede RX480 con 8GB ciascuna con un vantaggio medio del 50%" e questo con versioni 1070 occate e RX480 def. La prima coda che mi viene in mente è fare un CF di 2 RX480 ed ottenere più potenza allo stesso prezzo. Siccome per la massa è il prezzo il problema per aumentare la potenza, non capisco il perché un nuovo prodotto con un prezzo/prestazioni i migliore venga criticato.

[bjt2]

E' quello che ho detto, anche se molto più in soldoni perché non so un cazzo di come fanno all'atto pratico :D

Si scusa... Avevo letto di fretta e solo la prima frase... :D

[Free Gordon]

Anche queste due tecnologie permettono di tenere il Vcore più basso.

e mi sa che nella 480 non sono per nulla attive/funzionanti... :D

[Free Gordon]

Se un chip è fortunello e non è stato testato più in basso, probabilmente è stato "etichettato" con un vcore superiore all'ottimale. Per ridurre il tempo di testing e contemporaneamente gli scarti, probabilmente quelle 2-3 tensioni che prova saranno altine...

Più che fortunelli...pare ci sia una sovrastima generalizzata della maggioranza dei chip in commercio.

Io credo semplicemente che abbiano buttato in produzione tutti i chip vagamente funzionanti :D che riuscivano a tirare fuori da GF e che gli abbiano piazzato un vcore decisamente alto per evitare che failassero.

Così ---> consumi alle stelle e dissipatore al limite con annesso throttling.

Se uno prende una reference, è praticamente obbligato al downvolting per avere temp e performance migliori.

[Free Gordon]

L'unica vera critica sensata e sacrosanta è che il dissipatore reference è una cacata atomica, infatti aspetto una custom, il mio target è il silenzio, quindi sceglierò in base a quello anche se dovrò spendere di più.


Se vuoi un dissi ad aria silenzioso, prendi una reference e mettigli un accelero, no?
Sono più silenziosi di tutti i dissi custom di norma

https://www.arctic.ac/eu_en/accelero-twin-turbo-iii.html

Questo dovrebbe montare sulla 480

https://www.youtube.com/watch?v=Uvhyrz5oDPo

Quì c'è il video (nella seconda parte dovrebbero mostrare i vari accelero)

[capitan_crasy]

Più che fortunelli...pare ci sia una sovrastima generalizzata della maggioranza dei chip in commercio.

Io credo semplicemente che abbiano buttato in produzione tutti i chip vagamente funzionanti :D che riuscivano a tirare fuori da GF e che gli abbiano piazzato un vcore decisamente alto per evitare che failassero.

Così ---> consumi alle stelle e dissipatore al limite con annesso throttling.

Se uno prende una reference, è praticamente obbligato al downvolting per avere temp e performance migliori.

Che significa buttare in produzione tutti i chip vagamente funzionanti???
Non ha senso...
Le GPU dopo la produzione passano al testing, quelle che passano vengono montati sulle schede e messe in commercio, gli altri vengono semplicemente scartati...

[Free Gordon]

Le GPU dopo la produzione passano al testing, quelle che passano vengono montati sulle schede e messe in commercio, gli altri vengono semplicemente scartati...

nel senso che per inserire anche i chip che le frequenze target (boost di 1266mhz) non le raggiungono al vcore desiderato (ipotizzo, poco sopra il volt.. 1,02 1,05), hanno alzato il vcore base senza fare una cernita granulare dei chip.

Appunto i test sono stati fatti con vcore più alti per inserire anche i chip che non avrebbero passato il test (boost freq di 1266) con il vcore terghettato in origine.

Sennò i consumi esagerati non si spiegano. ;)

Ste schede con vcore attorno al volt, hanno il consumo teorizzato in origine (120 tutta la scheda, considerati anche i 15w delle ram), infatti praticamente tutti reggono il boost default, a Volt 1,04/05...invece di 1,150.


Cmq, è tutta un'ipotesi per spiegare i consumi assurdi che ha la scheda considerati i 14nm eh.. ;)

[Piedone1113]

nel senso che per inserire anche i chip che le frequenze target (boost di 1266mhz) non le raggiungono al vcore desiderato (ipotizzo, poco sopra il volt.. 1,02 1,05), hanno alzato il vcore base senza fare una cernita granulare dei chip.

Appunto i test sono stati fatti con vcore più alti per inserire anche i chip che non avrebbero passato il test (boost freq di 1266) con il vcore terghettato in origine.

Sennò i consumi esagerati non si spiegano. ;)

Ste schede con vcore attorno al volt, hanno il consumo teorizzato in origine (120 tutta la scheda, considerati anche i 15w delle ram), infatti praticamente tutti reggono il boost default, a Volt 1,04/05...invece di 1,150.


Cmq, è tutta un'ipotesi per spiegare i consumi assurdi che ha la scheda considerati i 14nm eh.. ;)

Credo che un vcore più basso si avrà con la possibile uscita di rx 480x (perchè le premesse per farla ci sono), conseguentemente ad una migliore resa della fonderie ed ad un testing più granurale.
Per il momento vogliono saturare il mercato e prendersi tutto il possibile.

[bjt2]

Credo che un vcore più basso si avrà con la possibile uscita di rx 480x (perchè le premesse per farla ci sono), conseguentemente ad una migliore resa della fonderie ed ad un testing più granurale.
Per il momento vogliono saturare il mercato e prendersi tutto il possibile.

Può anche darsi che stiano facendo una minima cernita e si stiano conservando i chip che funzionano a basso voltaggio, per fare un hard launch di una versione low power o per la versione mobile...

[Free Gordon]

Per il momento vogliono saturare il mercato e prendersi tutto il possibile.

Era proprio quello che intendevo..

Anche quello che ipotizza bjt2 potrebbe essere vero.

[tuttodigitale]

http://wccftech.com/amd-naples-32-core-zen/

http://sm.uploads.im/d/uB76e.jpg

32 core, previsti per il q4-2016/q1-2017, basati su 4 die ZEN x8. Ho fatto il punto della situazione in prima pagina

[bjt2]

http://wccftech.com/amd-naples-32-core-zen/

http://sm.uploads.im/d/uB76e.jpg

32 core, previsti per il q4-2016/q1-2017, basati su 4 die ZEN x8. Ho fatto il punto della situazione in prima pagina

Ma sono scemi? Il Vesuvio è quello che caratterizza di più Napoli e lo tagliano dalla foto?

[Free Gordon]

Ma sono scemi? Il Vesuvio è quello che caratterizza di più Napoli e lo tagliano dalla foto?

Si ma sai quanti sfottò tipo: "calda come un vulcano" "cpu vulcanica" "la lava è più fresca" :asd:

Bisogna sempre stare attenti a quel che si dice nel campo del marketing :D

[bjt2]

Si ma sai quanti sfottò tipo: "calda come un vulcano" "cpu vulcanica" "la lava è più fresca" :asd:

Bisogna sempre stare attenti a quel che si dice nel campo del marketing :D

Beh... Intel ha un TDP minimo di 55W, mentre AMD parte da 35W...

[Free Gordon]

Beh... Intel ha un TDP minimo di 55W, mentre AMD parte da 35W...


sai che non c'ho capito una fava dell'articolo?

Praticamente dicono che ci sarà una config, da 2core? cioè, 2+2+2+2? :confused: Sempre Zen ovviamente..


EDIT: cioè, Naples ha dei chip con soli 2 cores?? 2???? stop? I 35W a quel punto sono giustificati... 4 thread a 35W sui 14nm non mi paiono irraggiungibili.
Questo significherebbe un 8core, clockato simile, entro i 125W probabilmente.

A questo punto, considerando il target desktop, io avrei immesso solo i 4core (8t) sul desktop...e clockati molto in alto. Per fare concorrenza agli i5/i7 attuali e stop.

[bjt2]

sai che non c'ho capito una fava dell'articolo?

Praticamente dicono che ci sarà una config, da 2core? cioè, 2+2+2+2? :confused: Sempre Zen ovviamente..


EDIT: cioè, Naples ha dei chip con soli 2 cores?? 2???? stop? I 35W a quel punto sono giustificati... 4 thread a 35W sui 14nm non mi paiono irraggiungibili.

Ok, hai editato. Si. Io penso che useranno i die fallati in cui almeno il NB e il MC funzionano per avere sempre 128 linee PCIEx e 8 controller, disabilitando gli altri... Però mi viene il dubbio che le soluzioni con meno di 16 core siano APU...

[tuttodigitale]

sai che non c'ho capito una fava dell'articolo?

Praticamente dicono che ci sarà una config, da 2core? cioè, 2+2+2+2? :confused: Sempre Zen ovviamente...
la fonte è fudzilla, e questa non fa nessun riferimento a 2core, o sbaglio?

[george_p]

la fonte è fudzilla, e questa non fa nessun riferimento a 2core, o sbaglio?

Più che altro scriverei:
la fonte è FUDzilla... ...

e basta :D

[paolo.oliva2]

Se quanto è arrivato di info è vero, Zen spiccherà realmente.
Ora, 180W un X32 sono 45W a die X8+8.
Non so come spiagarmi, ci provo, ma se il 14nm tiene botta, qui si occa di brutto.
8350 125W X8 - Opteron X16 137W quindi 68,5W a die.
Se vogliamo arrotondare, 65W X8 Opteron e 130W desktop.
Con Zen si avrebbe 45W a die, e questo porta a pensare effettivamente Zen X8 desktop 95W, ma con ben 45W (140W max) tutti per l'OC sono un margine ENORME, qualsiasi frequenza def abbia, 45W possono dire +500MHz/1GHz.

Quello che mi rende dubbioso e ottimista al contempo, sarebbero i 95W def. Perché? Perché il TDP svetta e scala poco o perché a 95W è già 4GHz?

In ogni caso, mi sembra OVVIO che se AMD ha fissato 140W per il socket AM4, non è certamente per BR, ma mi viene da ipotizzare Zen X86 X12/Zen APU X8 e chissà... Non si fa altro che parlare di Zen APU X16.... Probabile che non abbia bisogno di un gran click per essere un signore procio da gamer.

[enricoa]

Siccome per la massa è il prezzo il problema per aumentare la potenza, non capisco il perché un nuovo prodotto con un prezzo/prestazioni i migliore venga criticato.

forse perché a produrlo è amd?

[tuttodigitale]

Più che altro scriverei:
la fonte è FUDzilla... ...

e basta :D
a questo giro, pare che hanno trovato una talpa in AMD....:stordita:

[tuttodigitale]

forse perché a produrlo è amd?
la cosa buffa che nessuno ha notato che un mese fa la gtx 970 costava di più:
il listino è passato da 329dollari (articolo anandtech 18 Maggio 2016) a 269 dollari (articolo anandtech 29 Giugno 2016)...se la gtx970 costa quanto costa oggi, è grazie a questa carta dal pessimo rapporto prezzo-prestazioni...

[george_p]

a questo giro, pare che hanno trovato una talpa in AMD....:stordita:
Lurkando siti più affidabili di loro magari :D

la cosa buffa che nessuno ha notato che un mese fa la gtx 970 costava di più:
il listino è passato da 329dollari (articolo anandtech 18 Maggio 2016) a 269 dollari (articolo anandtech 29 Giugno 2016)...se la gtx970 costa quanto costa oggi, è grazie a questa carta dal pessimo rapporto prezzo-prestazioni...

Intanto quella scheda pessima funziona con le DX12 mentre le altre (idem nuove) per niente.

[paolo.oliva2]

Questo è quanto compare nella bolla.

FOC VOCE-2D-YA331-H100 / CCA, QCA9379-7 WB NPL01.1, NAPLES1.0, 2X2 / 2 .4G + 2X2 / 5G-11AC- (TEST SCHEDA)

Probabilmente hanno letto 2X2 come X2 ed è per quello che hanno riportato X2 e X4.

Però... 2.4G potrebbe essere 2,4GHz, però c'è anche 5g... Turbo?

Altro punto è che i die sono perfettamente operativi, cioè che anche se ES, hanno assolutamente le caratteristiche di un pre produzione, quindi quei rumor che danno Zen in commercio per ottobre, potrebbero essere REALI.

[tuttodigitale]

Lurkando siti più affidabili di loro magari :D



Intanto quella scheda pessima funziona con le DX12 mentre le altre (idem nuove) per niente.
ma le DX12/Vulcan fanno schifo dovresti saperlo, non si diffonderanno, il futuro sono le DX7 :D

[george_p]

ma le DX12/Vulcan fanno schifo dovresti saperlo, non si diffonderanno, il futuro sono le DX7 :D

Si infatti mi sto facendo una cultura leggendo i commenti di molti utenti e molti recensori al top.
Consiglio occhiali con lenti serie prosciutto aromatizzato menta :cool:

[stefanonweb]

Scusate, una domanda molto pratica: Io vorrei solo una mobo AM4 decente ed un APU con la grafica simile a quella di un A10-7800 ma il lato x86 grossomodo al livello di un Intel Sandy Bridge 2500K (Roba di 5 anni fa)... Pensate sia possibile già con Bristol Ridge? Oppure NO? La potenza di calcolo di un 2500k pensate si possa raggiungere con un 4 core? O bisogna andare di APU 8x ecc...??? In pratica una CPU con una grafica decente ed una potenza di calcolo "normale" quando potrebbe essere disponibile? Grazie a tutti... Spero in una risposta semplice e chiara...

Per esempio questa APU potrebbe competere con un 2500k?

TBD 4 3.6/4.0 GHz 2 MB 8 CUs 512 SPs 948 MHz DDR4-2400 65W/45W

[Piedone1113]

Scusate, una domanda molto pratica: Io vorrei solo una mobo AM4 decente ed un APU con la grafica simile a quella di un A10-7800 ma il lato x86 grossomodo al livello di un Intel Sandy Bridge 2500K (Roba di 5 anni fa)... Pensate sia possibile già con Bristol Ridge? Oppure NO? La potenza di calcolo di un 2500k pensate si possa raggiungere con un 4 core? O bisogna andare di APU 8x ecc...??? In pratica una CPU con una grafica decente ed una potenza di calcolo "normale" quando potrebbe essere disponibile? Grazie a tutti... Spero in una risposta semplice e chiara...

Dai rumor ed aspettative un quad anche senza ht dovrebbe asfaltare un 2500K.
Per il resto bisogna aspettare comunque.

[stefanonweb]

Dai rumor ed aspettative un quad anche senza ht dovrebbe asfaltare un 2500K.
Per il resto bisogna aspettare comunque.

Asfaltare, con un 4x... Ma allora se state parlando di 8x, 16x ecc...
Verosimilmente una APU/CPU attorno ai 200/250€ che prestazioni x86 potrebbe avere? Paragonata ad un Intel attuale intendo? Grazie...

[dav1deser]

Questo è quanto compare nella bolla.

FOC VOCE-2D-YA331-H100 / CCA, QCA9379-7 WB NPL01.1, NAPLES1.0, 2X2 / 2 .4G + 2X2 / 5G-11AC- (TEST SCHEDA)

Probabilmente hanno letto 2X2 come X2 ed è per quello che hanno riportato X2 e X4.

Però... 2.4G potrebbe essere 2,4GHz, però c'è anche 5g... Turbo?

Altro punto è che i die sono perfettamente operativi, cioè che anche se ES, hanno assolutamente le caratteristiche di un pre produzione, quindi quei rumor che danno Zen in commercio per ottobre, potrebbero essere REALI.

2.4 e 5 effettivamente sono GHz...ma quelli del modulo wifi della scheda:


Classi

Esistono varie classi di Wi-Fi con prestazioni diverse (come specificato meglio nei dettagli dello standard IEEE 802.11), le principali sono:

classe a a 54 Mb/s (5 GHz)
classe b a 11 Mb/s (2,4 GHz)
classe g a 54 Mb/s (2,4 GHz)
classe n a 450 Mb/s (2,4 GHz e 5 GHz)

[bjt2]

2.4 e 5 effettivamente sono GHz...ma quelli del modulo wifi della scheda:

11AC sarà il protocollo e 2x2 sono la configurazione MIMO delle antenne (probabile che sia MB+CPU e che abbia il wifi integrato)...

[tuttodigitale]

Si ma sai quanti sfottò tipo: "calda come un vulcano" "cpu vulcanica" "la lava è più fresca" :asd:

Bisogna sempre stare attenti a quel che si dice nel campo del marketing :D

se non sbaglio il nome in codice della r9 295x2 è proprio Vesuvio...però era effettivamente fresca (i chip)

[capitan_crasy]

Scusate, una domanda molto pratica: Io vorrei solo una mobo AM4 decente ed un APU con la grafica simile a quella di un A10-7800 ma il lato x86 grossomodo al livello di un Intel Sandy Bridge 2500K (Roba di 5 anni fa)... Pensate sia possibile già con Bristol Ridge? Oppure NO? La potenza di calcolo di un 2500k pensate si possa raggiungere con un 4 core? O bisogna andare di APU 8x ecc...??? In pratica una CPU con una grafica decente ed una potenza di calcolo "normale" quando potrebbe essere disponibile? Grazie a tutti... Spero in una risposta semplice e chiara...

Per esempio questa APU potrebbe competere con un 2500k?

TBD 4 3.6/4.0 GHz 2 MB 8 CUs 512 SPs 948 MHz DDR4-2400 65W/45W

Non si ha ancora informazioni sulle APU ZEN (e ancora troppo presto), quindi niente di nuovo compresi i rumors; per Bristol Ridge dovrebbero mancare poco più di un paio di mesi all'uscita...

[Piedone1113]

Asfaltare, con un 4x... Ma allora se state parlando di 8x, 16x ecc...
Verosimilmente una APU/CPU attorno ai 200/250€ che prestazioni x86 potrebbe avere? Paragonata ad un Intel attuale intendo? Grazie...
Dovrebbe essere comparabile come ipc alle ultime soluzioni Intel (dal 5 al 7% in meno circa) ma con frequenze maggiori.
Non sappiamo di preciso le frequenze (intorno ai 3,8-4.0 ghz per l'8 core con ht attivo come clock base, si presume) ma un 2500 dovrebbe essere ampiamente superato da un'apu x4 top (ma sicuramente ci saranno modelli sempre x4 con freq più basse che potrebbero andare meno, anche se ne dubito)

[Free Gordon]

http://www.overclock.net/t/1604585/oc3d-rx480-power-bottleneck/20#post_25309361

Quì un altro utente ipotizza una situazione del genere..

[paolo.oliva2]

2.4 e 5 effettivamente sono GHz...ma quelli del modulo wifi della scheda:

Lol. Al wij-fi della mono non ci avevo pensato.

Quindi la descrizione è tutta nei primi codici, ed essendo un ES con molti libero il codice non ha alcun riscontro con le frequenze.

Aspettiamo i bench, allora.

[paolo.oliva2]

http://www.overclock.net/t/1604585/oc3d-rx480-power-bottleneck/20#post_25309361

Quì un altro utente ipotizza una situazione del genere..

Comunque la tua "nasata" di prima botta ha molto senso. AMD ha puntato sul prezzo/prestazioni, se ci pensiamo, meglio il prezzo che ha e qualche Watt in più che 50$ in più e qualche Watt def in meno.

Anche con Zen probabilmente farà così... 2 modelli X8, uno sui 3,3GHz e l'altro sui 4GHz, con Vcore def taglia XL.

[cdimauro]

Ah ok. Mi viene da pensare che questo faccia parte dei piani HSA di amd e consorzio.
Non m'ero accorto che prima mi avevi scritto, ma lo faccio ora.

HSA serve ad altro. Qui, invece, parliamo di caratteristiche di un processore che si adatta più o meno bene a gestire compiti "generici", e dunque non strettamente funzionali al rendering del frame di un videogioco.
Da poco più di 2 anni abbiamo comprato un sistema socket 2011 in un rack 19" con 2 GTX 690 in SLI, viste come 4 GPU. Le usiamo per il GPGPU e mi sono studiato l'architettura. Anche li (e che io sappia anche in architetture precedenti) c'è una unità scalare, mi pare 4 ogni 192. Sono usate anche per le funzioni trascendenti. Il filtro Non Local Mean che abbiamo implementato, usa exp e mi ero fatto il calcolo per vedere se eravamo limitati da quello. Purtroppo siamo limitati dalla banda L1 (neanche da quella RAM) perchè l'algoritmo è abbastanza semplice (ma non troppo semplice da essere limitati dalla banda RAM).
In questo caso potete provare a inventarvi un'altra implementazione, oppure cercare di intervallare quel calcolo con un altro (che ovviamente non stressi così la L1).
Interessante! :D Se 6 wide vuol dire che ha 6 decoder, è una ottima notizia...
In genere è proprio questo che s'intende.
Daltronde un modulo XV ne ha 8 per 2 thread, ma 4+4, quindi 6 decoder, magari unificati, per la teoria delle code non è tanto peggio di un 4+4!
Dipende sempre dal tipo di codice. A parità di "sportelli" a disposizione, è meglio che a servirli sia una sola coda, in modo da evitare che alcuni sportelli rimangano vuoti pur avendo una coda per gli altri.

E' il motivo per cui BD si è rivelato fallimentare, con le sue macro ALU intere accessibili soltanto dallo specifico, dedicato, thread hardware.
nelle patch i decoder risultato 4.. in effetti se si riferissero al wide-dispatch sarebbe molto più stretta di quello che siamo pensati a pensare.

per wide in letteratura si può intendere qualsiasi cosa....per quel che ne sappiamo potrebbe essere un 6 wide-issue OoO :D e la cosa avrebbe anche il suo senso...
Come dicevo, per issue in genere s'intende quello. Anche dal tuo primo post:

"4 wide decoders
That makes z ten pipelines with a general four wide design."

;)
aggiungo un dato: il fattore di scaling dai 28 ai 14nm per le gpu AMD è pari a solo a 1,7x...se questo fosse vero anche per la CPU il die ZEN sarebbe grande 251mmq.
Immagino che 1,7x sia riferito a una sola dimensione, per cui bidimensionalmente dovrebbe essere 2,89x.
non capisco è troppa o troppo poca. Alla fine sono 2MB vs 2,5MB degli XEON Intel...non vedo sta grande differenza.
No, infatti. La soluzione a 32 core, con 64MB di cache L3, è certamente competitiva da questo punto di vista.

E' l'APU che, dalle slide del CERN, avrebbe soltanto 8MB per 16 core, che fanno appunto 512KB per core. Considerato che sono "inclusive", e che ci sono sempre 512KB di L2 per core, IMO non ha senso aver integrato questa scarsa quantità di cache L3.
Se invece ti riferisci alle dimensioni della L2, potrebbe anche essere dovuta ad algoritmi non infallibili per la predizione dei rami, a pensar male..
La dimensione della cache L2 è ragionevole/normale.
auspichi un ritorno al vliw?
No, IMO passando al paradigma SIMD hanno fatto benissimo, perché si presta meglio per carichi di lavoro abbastanza simili, come quelli che servono in ambito grafico.

Ma aver aggiunto logica e funzionalità "più da CPU", hanno complicato i core, e sprecato transistor.

Come già detto, AMD dovrebbe pensare principalmente all'ambito videoludico, mentre se vuole supportare anche il settore GPGPU computing dovrebbe offrire soluzioni appositamente potenziate da questo punto di vista.

Con gli shader processor attuali prova a coprire entrambi i settori, ma ci rimette proprio in quello per lei più importante: quello videoludico.
l'esperto sei tu, ma non penso che sia così determinante il quantitativo di l2...comunque sono 64-128KB per CU a seconda della GPU.
Come ho già detto altre volte, non sono un esperto di microarchitetture: a me piace studiarmi le architetture.

Poi per le GPU generalmente non sono disponibili molte informazioni sulle microarchitetture, e molto peggio per l'architettura, che in genere non è pubblica.

Per quanto detto, e riguardo alla cache L2, non ho quindi idea se vada bene oppure no.
AMD parla di modulo ZEN, quindi sono in parte tentato a pensare che la l3 sarà sempre presente...
Questo dice la slide del CERN.
pare proprio di si. Anzi credo che il fine ultimo dello sviluppo delle HBM sia proprio il mercato server.
In ambito server serve, però, parecchia memoria, e AMD non ne può certo integrare un grosso quantitativo.

Probabilmente sarà utile alla GPU, visto che dovrebbe essere questo l'elemento centrale dell'APU.

Se e come l'HBM potrà essere usata dai core Zen è tutto da vedere, e non mi pare di aver letto informazioni in merito.
Dati i risultati finanziari, mi sa che hai ragione..
:)

[bjt2]

In questo caso potete provare a inventarvi un'altra implementazione, oppure cercare di intervallare quel calcolo con un altro (che ovviamente non stressi così la L1).

Il filtro è tipo convolutivo e per ogni pixel fa la media pesata dell'intorno, con i pesi funzione complessa. Facendo fare al compilatore CUDA il disassemblato del codice, abbiamo confrontato varie implementazioni, scendendo da 25 ops (flop+int op) a 7 ops per ciclo per pixel (arrivando ad usare un vettore intero per gli offset in 3D, per trasformare l'indicizzazione 3D in una 1D) senza scendere di tempo di esecuzione. Overcloccando o undercloccando la ram non succede niente o quasi, invece le prestazioni sono proporzionali al clock degli SP. Le SP si stanno sempre a girare i pollici aspettando i dati della L1, o forse no, perchè di quelle 7 o 25 ops, una è una exp, che deve essere fatta nella unità scalare, di cui ce ne sono 1/32 delle SP e resta da vedere la latenza... Non ho ritenuto approfondire ulteriormente...

In genere è proprio questo che s'intende.

Dipende sempre dal tipo di codice. A parità di "sportelli" a disposizione, è meglio che a servirli sia una sola coda, in modo da evitare che alcuni sportelli rimangano vuoti pur avendo una coda per gli altri.

E' il motivo per cui BD si è rivelato fallimentare, con le sue macro ALU intere accessibili soltanto dallo specifico, dedicato, thread hardware.

Ricordi di teoria delle code dall'università... Se ne sono accorte anche le poste che sono passate alla coda unica da una decina di anni almeno...

[george_p]

Non m'ero accorto che prima mi avevi scritto, ma lo faccio ora.
HSA serve ad altro. Qui, invece, parliamo di caratteristiche di un processore che si adatta più o meno bene a gestire compiti "generici", e dunque non strettamente funzionali al rendering del frame di un videogioco.


Ma HSA mica nasce per svolgere solo rendering di videogames.

[paolo.oliva2]

@Capitano

Ho visto che hai postato disponibilità BR a settembre.

Io continuo a non capire il ruolo di BR... Un conto era un BR a giugno e un Zen APU 4-5 mesi dopo Zen X86 ( che se posizionassimo Zen X86 verso fine anno, BR avrebbe avuto circa 1 anno commerciale), ma a me sembra che Zen abbia le carte in tavola per essere commercializzato a settembre, quindi mi sembra che per paradosso uscirebbe prima Zen di BR... e questo indubbiamente accorcerebbe considerevolmente i tempi commerciali di BR, perché secondo me 6 mesi di tempo da Zen X86 a Zen APU sarebbero giusti per vedere commercializzato Zen APU.

Produrre BR e produrre Zen APU in termini di costo la differenza secondo me è esigua, ma è ovvio che prezzare Zen X4+4 APU concederebbe margini superiori rispetto a BR.
Io mi rifiuto di ipotizzare un Zen QPU a settembre 2017, non avrebbe senso il ritardo.

Io ho ipotizzato 3 motivi, il 1° un problema di TDP di contenere nei 15W un Zen X4+4 APU, la 2′ una differenziazione di prezzi e la 3a inquadrare Zen APU come X8 APU.

La prima cade perché guardando un X32+32 a 55W, farebbe 7W per X4+4 con L3, quindi come APU ci sguazzerebbe.
La seconda ci potrebbe anche stare, se BR viene sui 150$, un Zen X4+4 APU a 250$ ci può stare, però alzerebbe il prezzo di Zen X86 X8+8 almeno a 400$ e non vedo convenienza per AMD, nel senso che fino a disponibilità commerciale Zen X4 APU AMD non avrebbe il prezzo per competere con la fascia 1155 Intel e questo comporterebbe un volume almeno 20/30 volte inferiore.
La terza giustificherebbe in parte la seconda, perché vorrebbe dire che AMD prezzerebbe 8 core tanto quanto oggi Intel prezza i 4 core, ed ovviamente un BR a 150$ come massimo il suo spazio l'avrebbe.

Cosa ne pensi? Se ti va FI rispondere (ti faccio sbilanciare)

[paolo.oliva2]

Ma HSA mica nasce per svolgere solo rendering di videogames.

Io penso che si debba valutate una cosa... HSA vuole la condivisione memoria video e X86, e già da Kaveti AMD offre il supporto nativamente.
Quindi se ciò vale per una L3 X86 utilizzabile dall'iGPU, non vedo che differenza ci sia se la iGPU usa le HBM in condivisione con i core X86.

Tra l'altro mi sembra che Zen APU abbia una HBM di 16GB che equivarrebbe ai 16GB che avrebbe Zen X16 X86, ma ovviamente essendo la HBM più veloce.
Aggiungo, ma non mi intendo, in BD l'interfacciamento era lFSB, in Zen si passa a 150GB/s, in BD quanto era? 15GB/s? L'ossatura di tutto l'I/O a me sembra più in veste X86/iGPU che X86 e stop, anche perché Intel ha un 4 channel su un X22 e AMD si ritroverebbe un 8 channel (+100%) con poco meno di +50% di core...

[capitan_crasy]

@Capitano

Ho visto che hai postato disponibilità BR a settembre.

Io continuo a non capire il ruolo di BR... Un conto era un BR a giugno e un Zen APU 4-5 mesi dopo Zen X86 ( che se posizionassimo Zen X86 verso fine anno, BR avrebbe avuto circa 1 anno commerciale), ma a me sembra che Zen abbia le carte in tavola per essere commercializzato a settembre, quindi mi sembra che per paradosso uscirebbe prima Zen di BR... e questo indubbiamente accorcerebbe considerevolmente i tempi commerciali di BR, perché secondo me 6 mesi di tempo da Zen X86 a Zen APU sarebbero giusti per vedere commercializzato Zen APU.

Produrre BR e produrre Zen APU in termini di costo la differenza secondo me è esigua, ma è ovvio che prezzare Zen X4+4 APU concederebbe margini superiori rispetto a BR.
Io mi rifiuto di ipotizzare un Zen QPU a settembre 2017, non avrebbe senso il ritardo.

Io ho ipotizzato 3 motivi, il 1° un problema di TDP di contenere nei 15W un Zen X4+4 APU, la 2′ una differenziazione di prezzi e la 3a inquadrare Zen APU come X8 APU.

La prima cade perché guardando un X32+32 a 55W, farebbe 7W per X4+4 con L3, quindi come APU ci sguazzerebbe.
La seconda ci potrebbe anche stare, se BR viene sui 150$, un Zen X4+4 APU a 250$ ci può stare, però alzerebbe il prezzo di Zen X86 X8+8 almeno a 400$ e non vedo convenienza per AMD, nel senso che fino a disponibilità commerciale Zen X4 APU AMD non avrebbe il prezzo per competere con la fascia 1155 Intel e questo comporterebbe un volume almeno 20/30 volte inferiore.
La terza giustificherebbe in parte la seconda, perché vorrebbe dire che AMD prezzerebbe 8 core tanto quanto oggi Intel prezza i 4 core, ed ovviamente un BR a 150$ come massimo il suo spazio l'avrebbe.

Cosa ne pensi? Se ti va FI rispondere (ti faccio sbilanciare)

Non entro nelle danze sui numeri del teorico TDP, ne tanto meno sulle presunte frequenze di Zen...
BR è pronto, HP e forse altri partner hanno già in mano le versioni APU "definitive" (si sono viste al Computex).
Il fatto che escano a settembre può significare che la resa produttiva non sia "eccezionale", quindi AMD si porta avanti per avere un buon numero sia per il mercato OEM, sia per quello (si spera) Retail.
Zen non esce a settembre (tranne miracoli), nel mese di luglio/agosto dovrebbero essere distribuiti ES per lo sviluppo delle schede AM4.
All'uscita di quest'ultimi dovrebbe cominciare la fase finale prima della produzioni in volumi e se tutto va bene fine anno dovremmo avere le versioni definitive.

[tuttodigitale]

HSA serve ad altro. Qui, invece, parliamo di caratteristiche di un processore che si adatta più o meno bene a gestire compiti "generici", e dunque non strettamente funzionali al rendering del frame di un videogioco.
HSA serve proprio per i calcoli generici.


Immagino che 1,7x sia riferito a una sola dimensione, per cui bidimensionalmente dovrebbe essere 2,89x
no è proprio 1,7x
14nm 5,7 miliardi transistor 232mmq
28nm 6,2 miliardi transistor 438mmq

lo stesso vale per nvidia. passando da maxwell (28nm) a Pascal (16nm)


E' l'APU che, dalle slide del CERN, avrebbe soltanto 8MB per 16 core, che fanno appunto 512KB per core. Considerato che sono "inclusive", e che ci sono sempre 512KB di L2 per core, IMO non ha senso aver integrato questa scarsa quantità di cache L3.

in quel sito c'è scritto che le caratteristiche dell'apu sono basate su rumors...e ad essere sincero è la prima volta che lo leggo...le indiscrezioni che venga usato sempre lo stesso die si fanno sempre più insistenti. Tutto è possibile, ma una l3 da 8MB per 16 core non è possibile dai..


No, IMO passando al paradigma SIMD hanno fatto benissimo, perché si presta meglio per carichi di lavoro abbastanza simili, come quelli che servono in ambito grafico.
direi proprio di no...hanno perso un pò in efficienza. Alla fine nel vliw avevi a parità di transistor avevi circa il 30% di ALU in più, e a detta di AMD nei giochi si sfruttavano mediamente 85%...ma era troppo condizionato dal compilatore e secondo me un ostacolo in più al calcolo eterogeneo.


In ambito server serve, però, parecchia memoria, e AMD non ne può certo integrare un grosso quantitativo.
aspetta un attimo....se parliamo di VRAM, AMD ne può integrare 16GB, se utilizzeranno 2 die HBM per singolo package...questa quantità può sembrare poca, ma non dimenticare che la GPU può comunque comunicare con le DDR4 in configurazione quad channel, avendo accesso diretto allo spazio di indirizzamento della cpu..


Se e come l'HBM potrà essere usata dai core Zen è tutto da vedere, e non mi pare di aver letto informazioni in merito.

:) questo non saprei dirtelo. Penso di si.

[tuttodigitale]

@Capitano

Ho visto che hai postato disponibilità BR a settembre.

Io continuo a non capire il ruolo di BR... Un conto era un BR a giugno e un Zen APU 4-5 mesi dopo Zen X86 ( che se posizionassimo Zen X86 verso fine anno, BR avrebbe avuto circa 1 anno commerciale), ma a me sembra che Zen abbia le carte in tavola per essere commercializzato a settembre, quindi mi sembra che per paradosso uscirebbe prima Zen di BR... e questo indubbiamente accorcerebbe considerevolmente i tempi commerciali di BR, perché secondo me 6 mesi di tempo da Zen X86 a Zen APU sarebbero giusti per vedere commercializzato Zen APU.
ma quel rumors sui problemi del chipset sono veri oppure è una montatura? Potrebbe essere questa la causa del ritardo....il ruolo è quello di vendere qualche prodotto a 100 euro...comunque qualcosa di aggiornato, soprattutto lato igp, che contrasti gli i3 ci vuole...un prezzo concorrenziale è un conto, svendere ZEN, è l'ultimo dei desideri di AMD....

PS se ZENx4 è un processorone da gioco, una igp da 1000sp, o quanto saranno, AMD se la farà pagare, puntando sul multi gpu esplicito offerto dai motori grafici dx12 (funziona anche con le gpu discrete della concorrenza), ne sono certo...

[cdimauro]

Il filtro è tipo convolutivo e per ogni pixel fa la media pesata dell'intorno, con i pesi funzione complessa. Facendo fare al compilatore CUDA il disassemblato del codice, abbiamo confrontato varie implementazioni, scendendo da 25 ops (flop+int op) a 7 ops per ciclo per pixel (arrivando ad usare un vettore intero per gli offset in 3D, per trasformare l'indicizzazione 3D in una 1D) senza scendere di tempo di esecuzione. Overcloccando o undercloccando la ram non succede niente o quasi, invece le prestazioni sono proporzionali al clock degli SP. Le SP si stanno sempre a girare i pollici aspettando i dati della L1, o forse no, perchè di quelle 7 o 25 ops, una è una exp, che deve essere fatta nella unità scalare, di cui ce ne sono 1/32 delle SP e resta da vedere la latenza... Non ho ritenuto approfondire ulteriormente...
Un buon profiler dovrebbe aiutare a chiarire questi problemi. :)
Ma HSA mica nasce per svolgere solo rendering di videogames.
Ma infatti qui mi riferivo ai singoli core, e non all'HSA.

L'HSA nasce per facilitare la condivisione di risorse, ad esempio eliminando la necessità di copie di buffer di memoria fra CPU e GPU, e questa funzionalità è trasversale: serve sia per calcolare il determinante di una matrice (calcolo "general purpose") sia per renderizzare grafica (la CPU può "immediatamente" condividere un buffer che la GPU deve elaborare).

Mentre le funzionalità "general purpose" introdotte negli shader processor sono utili nel primo caso, e non nel secondo.

Spero che sia chiaro adesso.
HSA serve proprio per i calcoli generici.
Ho spiegato meglio sopra.
no è proprio 1,7x
14nm 5,7 miliardi transistor 232mmq
28nm 6,2 miliardi transistor 438mmq

lo stesso vale per nvidia. passando da maxwell (28nm) a Pascal (16nm)
Non mi pare un gran risultato. Sappiamo che i 14nm di Samsung e i 16nm di TSMC non sono "veri", ma con questi numeri è come se il processo fosse un 20-22nm.
in quel sito c'è scritto che le caratteristiche dell'apu sono basate su rumors...e ad essere sincero è la prima volta che lo leggo...le indiscrezioni che venga usato sempre lo stesso die si fanno sempre più insistenti. Tutto è possibile, ma una l3 da 8MB per 16 core non è possibile dai..
Beh, è proprio quel che dico da quando ho letto quel dato. :)

Per cui tenderei a prender con le pinze i dati del CERN, considerato che parla pure di core 6-wide, e probabilmente nemmeno i 64KB+64KB di cache saranno veri (mentre 64KB di cache codice L1 sono plausibili per K12, similmente ad altri ARMv8, perché la densità del codice è inferiore a quella di x86/x64).
direi proprio di no...hanno perso un pò in efficienza. Alla fine nel vliw avevi a parità di transistor avevi circa il 30% di ALU in più, e a detta di AMD nei giochi si sfruttavano mediamente 85%...ma era troppo condizionato dal compilatore e secondo me un ostacolo in più al calcolo eterogeneo.
Strano, perché con un design SIMD puoi realizzare un decoder molto più semplice di uno VLIW, visto che ti basta decodificare una sola istruzione e replicare l'operazione n volte.

Però bisogna anche vedere anche cos'hanno aggiunto (in termini di funzionalità) nei core SIMD, rispetto a quelli VLIW.

Comunque non avendo documentazione su nessuna delle due architetture, non si può fare alcuna analisi.
aspetta un attimo....se parliamo di VRAM, AMD ne può integrare 16GB, se utilizzeranno 2 die HBM per singolo package...questa quantità può sembrare poca, ma non dimenticare che la GPU può comunque comunicare con le DDR4 in configurazione quad channel, avendo accesso diretto allo spazio di indirizzamento della cpu..
Quindi fino a 8GB di HBM per die. Mi sembra una quantità adeguata.

[tuttodigitale]

Dipende sempre dal tipo di codice. A parità di "sportelli" a disposizione, è meglio che a servirli sia una sola coda, in modo da evitare che alcuni sportelli rimangano vuoti pur avendo una coda per gli altri.

E' il motivo per cui BD si è rivelato fallimentare, con le sue macro ALU intere accessibili soltanto dallo specifico, dedicato, thread hardware.
quello che si perde in efficienza computazionale si guadagna in efficienza energetica, non è un caso se esistono cpu da 32 core e non core da 32 thread..

[cdimauro]

Ma è roba da server, non da desktop o mobile.

[Free Gordon]

Strano, perché con un design SIMD puoi realizzare un decoder molto più semplice di uno VLIW, visto che ti basta decodificare una sola istruzione e replicare l'operazione n volte.

Però bisogna anche vedere anche cos'hanno aggiunto (in termini di funzionalità) nei core SIMD, rispetto a quelli VLIW.

Comunque non avendo documentazione su nessuna delle due architetture, non si può fare alcuna analisi.

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/07/AMD_GCN3_Instruction_Set_Architecture.pdf

Questa è GCN1.2 (ora con Polaris sono alla terza revision)



Quindi fino a 8GB di HBM per die. Mi sembra una quantità adeguata.

Scorpio (l'unica APU Zen di cui abbiano notizia certa oggi), ha un bus a 384 bit che accede a 12 moduli di GDDR5. Stessa cosa per PS4 e PS4 Neo (tutte con controller per GDDR5).
Quindi per ora non si sa se faranno APU solo dotate di HBM o no..

[Free Gordon]

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Asynchronous-Shaders-White-Paper-FINAL.pdf

Questo il pdf sui tanto chiacchierati ACE..

Nvidia imho non li implementa perchè nella sua architettura non porterebbero giovamento...tutto quì. :D

Non è che Maxwell e Pascal mancano di ACE per una ragione tecnica, mancano di ACE perchè gli sp di queste due architetture sono già abbastanza impegnati già ora. :D

[capitan_crasy]

Scorpio (l'unica APU Zen di cui abbiano notizia certa oggi), ha un bus a 384 bit che accede a 12 moduli di GDDR5. Stessa cosa per PS4 e PS4 Neo (tutte con controller per GDDR5).
Quindi per ora non si sa se faranno APU solo dotate di HBM o no..

Di certo su scorpio sappiamo che si tratta di una APU semi-custom con una potenza complessiva (?) di 6 TFLOPs.
Tutto il resto compreso che sia composta da core X86 ZEN, GPU Polaris o quant'altro sono solo rumors!

[tuttodigitale]

Strano, perché con un design SIMD puoi realizzare un decoder molto più semplice di uno VLIW, visto che ti basta decodificare una sola istruzione e replicare l'operazione n volte.
le architetture VLIW di AMD non rinunciavano mica al design SIMD.



Ma infatti qui mi riferivo ai singoli core, e non all'HSA.

L'HSA nasce per facilitare la condivisione di risorse, ad esempio eliminando la necessità di copie di buffer di memoria fra CPU e GPU, e questa funzionalità è trasversale: serve sia per calcolare il determinante di una matrice (calcolo "general purpose") sia per renderizzare grafica (la CPU può "immediatamente" condividere un buffer che la GPU deve elaborare).

Mentre le funzionalità "general purpose" introdotte negli shader processor sono utili nel primo caso, e non nel secondo.

Spero che sia chiaro adesso.
per la verità non è molto chiaro....
è vero che HSA sarebbe utile anche nei giochi, ma al più è stato pubblicizzato solo come acceleratore della fisica....con l'apu che diventa una sorta di CELL.
l'intento teorico, è quello di far lavorare CPU e GPU in perfetta sinergia tra loro, anche se in effetti stanno snaturando la seconda...

le funzionalità general purpose del chip va proprio in ottica HSA, perchè con questo paradigma AMD si è prefissato l'obiettivo di poter sfruttare i vantaggi offerti dalla potenza offerta dalle GPU, su un numero crescente di applicazioni

http://techreport.com/r.x/amd-fad-2012/hsa-feature-roadmap.jpg

[Free Gordon]

Di certo su scorpio sappiamo che si tratta di una APU semi-custom con una potenza complessiva (?) di 6 TFLOPs.
Tutto il resto compreso che sia composta da core X86 ZEN, GPU Polaris o quant'altro sono solo rumors!

Si sa che sono 12GB di GDDR5 ;)
e mi pare moooooooooolto difficile che abbia un Jaguar o un DB sotto dai.... :D (anche se non c'è nulla di ufficiale)

[tuttodigitale]

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Asynchronous-Shaders-White-Paper-FINAL.pdf

Questo il pdf sui tanto chiacchierati ACE..

Nvidia imho non li implementa perchè nella sua architettura non porterebbero giovamento...tutto quì. :D

Non è che Maxwell e Pascal mancano di ACE per una ragione tecnica, mancano di ACE perchè gli sp di queste due architetture sono già abbastanza impegnati già ora. :D

detta così la fai apparire come una sciocchezzuola da implementare, o addirittura che bastano pochi ritocchi a Maxwell e Pascal. Non ne sarei così sicuro.

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/07/AMD_GCN3_Instruction_Set_Architecture.pdf

Questa è GCN1.2 (ora con Polaris sono alla terza revision)
quarta. tanto che è stato ribattezzato GCN 4.0


Scorpio (l'unica APU Zen di cui abbiano notizia certa oggi), ha un bus a 384 bit che accede a 12 moduli di GDDR5. Stessa cosa per PS4 e PS4 Neo (tutte con controller per GDDR5).
Quindi per ora non si sa se faranno APU solo dotate di HBM o no..
ZEN? Ma ne sei sicuro?
Jaguar è la soluzione adatta...sui 14nm le dimensioni del singolo core non supererà i 2mmq (si 2mmq)... gli otto-core +L2 sarebbero grandi appena 30mmq.

le console vecchie rimarranno in commercio e dovranno, prima o poi calare di prezzo...e quindi ci dovrà comunque essere un die shrink a 14nm di Jaguar.

APU solo dotate di HBM no, per lo stesso motivo per cui Intel non ha solo prodotti con l'edram...basterebbe un solo MC HBM2, per avere 256 GB/s :O e 4/8GB di ram...

[bjt2]

Un buon profiler dovrebbe aiutare a chiarire questi problemi. :)

Uno scambio di PVT con un utente mi ha fatto ritornare la memoria (sono passati almeno 2 anni): ho provato ad eliminare l'esponenziale, per verificare l'ipotesi (ovviamente il calcolo non era più quello giusto, ma lo scopo era solo trovare il collo di bottiglia) e non cambiava nulla, quindi il collo di bottiglia era la cache L1.

Quindi fino a 8GB di HBM per die. Mi sembra una quantità adeguata.

E' la HBM2 che ha doppia banda e fino a 8 GB per chip. La HBM1 si ferma a 1GB. Con 4 chip sarà possibile fare una GPU o una APU con 32GB... Per socket. Più che sufficiente per il consumer con un solo socket e da vedere se sarà sufficiente in ambito server... Ma si può sempre arrivare a 8 chip... Lo spazio c'è...

[bjt2]

http://forums.anandtech.com/showpost.php?p=38331614&postcount=2105

Finalmente qualcuno ragiona... Una cosa che avevo sentito, ma non avevo mai riportato: i core CON (che sarebbero construction, ossia Bulldozer e seguenti) sono limitati in frequenza dalla L2 condivisa. Se la L2 fosse fatta meglio, sarebbero potuti salire ancora di più... Sul 28nm... Ma Zen non ha la L2 condivisa... Ed è fatto sul 14nm... :D

Poi un'altra cosa: A57 va a 2.1GHz a 1.6W (immagino sul 14nm), con 15 stadi e uno scheduler e PRF unificato, quindi più lento. Zen, secondo lui, dovrebbe avere 20 stadi ed ha scheduler memoria, INT e FP separati... Quindi dovrebbe avere un FO4 inferiore e quindi consumare di meno a parità di transistor e frequenza.

[tuttodigitale]

http://forums.anandtech.com/showpost.php?p=38331614&postcount=2105

Finalmente qualcuno ragiona... Una cosa che avevo sentito, ma non avevo mai riportato: i core CON (che sarebbero construction, ossia Bulldozer e seguenti) sono limitati in frequenza dalla L2 condivisa. Se la L2 fosse fatta meglio, sarebbero potuti salire ancora di più... Sul 28nm... Ma Zen non ha la L2 condivisa... Ed è fatto sul 14nm... :D

Poi un'altra cosa: A57 va a 2.1GHz a 1.6W (immagino sul 14nm), con 15 stadi e uno scheduler e PRF unificato, quindi più lento. Zen, secondo lui, dovrebbe avere 20 stadi ed ha scheduler memoria, INT e FP separati... Quindi dovrebbe avere un FO4 inferiore e quindi consumare di meno a parità di transistor e frequenza.
Premesso che l'a57 ha 18 stadi e non 15.

se posso dire la mia, non si possono paragonare gli stadi e paragonare architetture tanto diverse.. Rimane il fatto che sono degli ASIC, e quindi hanno di partenza un fo4 sfavorevole ....tanto che alla fine che abbiamo un'architettura 6-wide, ampia il doppio dell'a57, da soli 9 stadi con frequenze di funzionamento simile...vedi Twister di Apple.
e un 'altra sempre 3-wide, che con soli 11 stadi rullava fino a 2,7GHz in uno smartphone con i 28nm Bulk...La "magia" dei custom.


EDIT "piccola" imprecisione A57 arriva a 2,5GHz vs 1,85GHz del twister.

Ritengo altamente improbabile che il problema nel salire di frequenza sia dovuta alla cache. Anche IBM si è scontrata con il "muro" dei 4,4GHz, anche lei ha una terribile cache?

[bjt2]

Premesso che l'a57 ha 18 stadi e non 15.

se posso dire la mia, non si possono paragonare gli stadi e paragonare architetture tanto diverse.. Rimane il fatto che sono degli ASIC, e quindi hanno di partenza un fo4 sfavorevole ....tanto che alla fine che abbiamo un'architettura 6-wide, ampia il doppio dell'a57, da soli 9 stadi con frequenze di funzionamento simile...vedi Twister di Apple.
e un 'altra sempre 3-wide, che con soli 11 stadi rullava fino a 2,7GHz in uno smartphone con i 28nm Bulk...La "magia" dei custom.


EDIT "piccola" imprecisione A57 arriva a 2,5GHz vs 1,85GHz del twister.

Si ma infatti non so se il tizio sa della differenza tra ASIC e custom e compara solo gli stadi... Resta il fatto che 1.6W per 2.1GHz è pochissimo e ci da l'idea del consumo di Zen, che avevo stimato in [email protected] considerando la macro Neon. Ora non è che Zen sia 3 volte più complesso di un A57... E anche se lo fosse, ha un FO4 più basso, quindi dovrebbe consumare di meno... E infatti a quella frequenza (anzi di più) consuma tanto un modulo XV sul 28nm!

[tuttodigitale]

Si ma infatti non so se il tizio sa della differenza tra ASIC e custom e compara solo gli stadi... Resta il fatto che 1.6W per 2.1GHz è pochissimo e ci da l'idea del consumo di Zen, che avevo stimato in [email protected] considerando la macro Neon. Ora non è che Zen sia 3 volte più complesso di un A57... E anche se lo fosse, ha un FO4 più basso, quindi dovrebbe consumare di meno... E infatti a quella frequenza (anzi di più) consuma tanto un modulo XV sul 28nm!
probabilmente lo è: pensa che un modulo XV è 4,4x volte più grande di 2 core Jaguar ed entrambi usano le HDL...e Jaguar ha un ipc, credo innavvicinabile per l'a57, e ha la pesante, così si dice, ISA x86....non oso immaginare ZEN quanto possa essere più grosso...le differenze sarebbero poi mitigate dalla presenza delle cache l2 e l3, ma non credo che incidano più di tanto sui consumi.

[Free Gordon]

detta così la fai apparire come una sciocchezzuola da implementare, o addirittura che bastano pochi ritocchi a Maxwell e Pascal. Non ne sarei così sicuro.

Non è che sia un sciocchezzuola...è che AMD ha degli SP in idle (conta che una 1070 fa 6,5Tflops di picco...un pò meno di una Fury liscia ma guarda le differenze di performance. :D ), Nvidia ha un'occupazione molto più alta, rendendo inutile l'implementazione degli ACE nella sua archtettura. Certo, AMD ha un sacco di "room" in più da sfruttare, ecco perchè GCN è utile nelle console... :)


quarta. tanto che è stato ribattezzato GCN 4.0

Sì, mi sono sbagliato, intendevo dire che quel pdf è sulla terza gen (GCN1.2 Tonga Fiji). ;)


ZEN? Ma ne sei sicuro?
Jaguar è la soluzione adatta...sui 14nm le dimensioni del singolo core non supererà i 2mmq (si 2mmq)... gli otto-core +L2 sarebbero grandi appena 30mmq.

Scorpio è un design ad alte performance, non ci mettono nel 2017 quel catorcio di Jaguar assieme a una Polaris/Vega dai... ;)


le console vecchie rimarranno in commercio e dovranno, prima o poi calare di prezzo...e quindi ci dovrà comunque essere un die shrink a 14nm di Jaguar.

C'è già ;)
http://www.xbox.com/it-IT/xbox-one-s

L'apu del 2013 a 28nm è shrinkata sui 14 GF o sui 16 di TSMC (non si sa).


APU solo dotate di HBM no, per lo stesso motivo per cui Intel non ha solo prodotti con l'edram...basterebbe un solo MC HBM2, per avere 256 GB/s :O e 4/8GB di ram...

Speriamo :D

[capitan_crasy]

Si sa che sono 12GB di GDDR5 ;)

"Dovrebbero" essere 12GB GDDR5.
Inoltre esce tra un anno e mi sembra chiaro che quell'immagine sia solo di bellezza per far bagnare i bimbi minchia presenti al E3...

e mi pare moooooooooolto difficile che abbia un Jaguar o un DB sotto dai.... (anche se non c'è nulla di ufficiale)

Conta anche da dove arriva la produzione di queste APU...
Se arrivano da tsmc (come quelle di PS4 e Xbox one) allora sarà difficile che abbia dei core ZEN e anche delle GPU Polaris/Vega.

[Free Gordon]

Se arrivano da tsmc (come quelle di PS4 e Xbox one) allora sarà difficile che abbia dei core ZEN e anche delle GPU Polaris/Vega.

Non si ancora che fonderia useranno...ma è ovvio che useranno Zen, non possono usare Jaguar su una APU del genere (6tflops di elaborazione grafica..)

[paolo.oliva2]

ma quel rumors sui problemi del chipset sono veri oppure è una montatura? Potrebbe essere questa la causa del ritardo....il ruolo è quello di vendere qualche prodotto a 100 euro...comunque qualcosa di aggiornato, soprattutto lato igp, che contrasti gli i3 ci vuole...un prezzo concorrenziale è un conto, svendere ZEN, è l'ultimo dei desideri di AMD....

PS se ZENx4 è un processorone da gioco, una igp da 1000sp, o quanto saranno, AMD se la farà pagare, puntando sul multi gpu esplicito offerto dai motori grafici dx12 (funziona anche con le gpu discrete della concorrenza), ne sono certo...

Io avevo letto che AMD e ASmedia avevano smentito ufficialmente, ma io non ho letto il comunicato ufficiale. Purtroppo il casino è che i rumor sono pochi e quando un sito posta qualche cosa questo rimbalza a 1000 perché tutti lo riportano.

Per come la penso io, tutta la parte I/O dentro Zen non è che sia progettata specificatamente per AMD, ma non sono altro che circuiti già super collaudati "copiati" nel film di Zen. Fai gli ES per verificare se tutto funzia (ed è impossibile che non abbiano risolto altri errori) e gli ES costano un puttanaio, se non altro perché costano più di un procio a regime e sono a rendita zero perché non vendibili, e in AMD si accorgerebbero ora?

[paolo.oliva2]

Non si ancora che fonderia useranno...ma è ovvio che useranno Zen, non possono usare Jaguar su una APU del genere (6tflops di elaborazione grafica..)

Ma poi a parte la potenza, paghi la progettazione e il tutto per avere nel 2017 un Jaguar?
Già secondo me sarebbe improbabile con la potenza attuale, ma personalmente io sono dell'idea che a prescindere da quale potenza avrà Zen, sicuramente AMD aumenterà il numero di core e di cascata dovrà farlo pure Intel, poi nel 2018 non si passerebbe ai 7nm?

[plainsong]

Ho una domanda per gli esperti del thread: non so se la questione è già stata affrontata in modo esaustivo, ma dalle performance della RX 480 ritenete possibile farsi una prima idea della attuale qualità dei 14nm di GF? In caso di risposta affermativa, quali sono le vostre impressioni?

[paolo.oliva2]

Ho una domanda per gli esperti del thread: non so se la questione è già stata affrontata in modo esaustivo, ma dalle performance della RX 480 ritenete possibile farsi una prima idea della attuale qualità dei 14nm di GF? In caso di risposta affermativa, quali sono le vostre impressioni?

Per quello che hanno risposto, tra una CPU e una VGA c'è troppa differenza e quindi non è un metro valido. Inoltre il passaggio dalla precedente miniaturizzazione al 14nm credo che sia buona e non ottima ma nel giudizio c'è un TDP più alto ma che potrebbe essere dovuto a Vcore def di manica larga (probabilmente per fare una selezione meno costosa e abbattere ancor più i prezzi).

[bjt2]

Ora ho capito perchè su semiaccurate ci sono tutti quei pessimisti... Il primo ES (A0) aveva frequenza 2.4GHz... E da li a dire che non supererà i 3GHz... Ma lo step A0 probabilmente sarà quello di novembre 2015 e il primo in assoluto... Ne è passato di tempo...

[george_p]

Ora ho capito perchè su semiaccurate ci sono tutti quei pessimisti... Il primo ES (A0) aveva frequenza 2.4GHz... E da li a dire che non supererà i 3GHz... Ma lo step A0 probabilmente sarà quello di novembre 2015 e il primo in assoluto... Ne è passato di tempo...

E' grave un es a 2.4?
Ma da dove è uscito fuori dell'es a 3 GHz?

[paolo.oliva2]

http://wccftech.com/amd-zen-cpu-core-microarchitecture-detailed/

Qui c'è una patch di Dresdenboy ma è datata ottobre 2015 ma ci sono confronti con Phenom e BD.

http://wccftech.com/amd-zen-competes-intel-performance-features-price-launching-2016/

Qui ci sono le affermazioni ufficiali di AMD, circa un Zen X16 APU e un Zen X4 APU e l'X32 Opteron... però non capisco, perché se li riporta annunci ufficiali di AMD, con tanto di domanda e risposta (CEO e Lisa Su), perché si postano rumor se poi ufficialmente AMD le ha già annunciate? Esempio Zen X32 AMD lo aveva già detto come pure l'APU Zen X16.

P.S.
Riporta pure che Zen ha superato le specifiche o aspettative come le si vuole chiamare, cioè che il target di +40% di IPC è stato superato.

Per il problema "supposto" di Zen con l'I/O

Responding to the rumours, an AMD spokesperson declined to comment on customer specific board level solutions. Instead they announced development of the Zen processors remains on track and that they are pleased with progress.
ASMedia was quick to dispel the issues as nothing more than a market rumour, assuring buyers that its product's signal, stability and compatibility have all passed the required certification.

[paolo.oliva2]

Ora ho capito perchè su semiaccurate ci sono tutti quei pessimisti... Il primo ES (A0) aveva frequenza 2.4GHz... E da li a dire che non supererà i 3GHz... Ma lo step A0 probabilmente sarà quello di novembre 2015 e il primo in assoluto... Ne è passato di tempo...

Ma non era 3GHz?

@george_p
L'ES BW era 2,2GHz....

Io direi che vuole dire poco se nulla... Nei nostri confronti di Zen con BD, bisogna vedere quali ES si prende. Il primissimo di BD mi sembra che era 1,7GHz e forse era il B1, noi avevamo preso il B2 a 2,7GHz. In teoria, se l'ES di Zen era A0, quindi in teoria sarebbe precedente in termini di sviluppo al B1 di BD.
Comunque ci capisco sempre meno.... BD era una nuova architettura, come del resto Zen, ma credo che in termini di progettazione Zen sia più complesso di BD, ma BD ha necessitato di 2 anni tra primo ES alla commercializzazione, Zen praticamente metà tempo se non meno.
È vero che Zen sembra nascere parallelamente a BD e forse nelle infornate sul 32nm magari c'era pure qualche ES di Zen, e poi il tutto è stato portato sul 14nm.

[george_p]

Ma non era 3GHz?

@george_p
L'ES BW era 2,2GHz....

Io direi che vuole dire poco se nulla... Nei nostri confronti di Zen con BD, bisogna vedere quali ES si prende. Il primissimo di BD mi sembra che era 1,7GHz e forse era il B1, noi avevamo preso il B2 a 2,7GHz. In teoria, se l'ES di Zen era A0, quindi in teoria sarebbe precedente in termini di sviluppo al B1 di BD.
Comunque ci capisco sempre meno.... BD era una nuova architettura, come del resto Zen, ma credo che in termini di progettazione Zen sia più complesso di BD, ma BD ha necessitato di 2 anni tra primo ES alla commercializzazione, Zen praticamente metà tempo se non meno.
È vero che Zen sembra nascere parallelamente a BD e forse nelle infornate sul 32nm magari c'era pure qualche ES di Zen, e poi il tutto è stato portato sul 14nm.

BW?

Sto pensando che riguardo BD forse il 32 nm è stato spremuto fino ai 3600 e non ha più reso oltre quello.
E forse anche per quello ha richiesto due anni.
Naturalmente parlo senza sapere nulla, però mi va di fare un confronto a logica e quindi 2.4 GHz potrebbe non essere male come base di partenza.
Chissà come sarà Zen finale.

[bjt2]

E' grave un es a 2.4?
Ma da dove è uscito fuori dell'es a 3 GHz?

Il tizio dice che l'ES A0 era 1.8/2.4GHz (non so se è base/turbo oppure se erano più di uno), ma A0 vuol dire primissimo silicio che può essere anche non funzionante e invece questo funzionava... Quello di 3GHz magari era uno degli ultimi... A0 può voler dire novembre 2015... 8 mesi fa...

Ma non era 3GHz?

@george_p
L'ES BW era 2,2GHz....

Io direi che vuole dire poco se nulla... Nei nostri confronti di Zen con BD, bisogna vedere quali ES si prende. Il primissimo di BD mi sembra che era 1,7GHz e forse era il B1, noi avevamo preso il B2 a 2,7GHz. In teoria, se l'ES di Zen era A0, quindi in teoria sarebbe precedente in termini di sviluppo al B1 di BD.
Comunque ci capisco sempre meno.... BD era una nuova architettura, come del resto Zen, ma credo che in termini di progettazione Zen sia più complesso di BD, ma BD ha necessitato di 2 anni tra primo ES alla commercializzazione, Zen praticamente metà tempo se non meno.
È vero che Zen sembra nascere parallelamente a BD e forse nelle infornate sul 32nm magari c'era pure qualche ES di Zen, e poi il tutto è stato portato sul 14nm.

vedi sopra... Se ci vogliono 2 mesi tra un ES e l'altro (non mi ricordo) ne sono già stati fatti 4...

[capitan_crasy]

Il tizio dice che l'ES A0 era 1.8/2.4GHz (non so se è base/turbo oppure se erano più di uno), ma A0 vuol dire primissimo silicio che può essere anche non funzionante e invece questo funzionava... Quello di 3GHz magari era uno degli ultimi... A0 può voler dire novembre 2015... 8 mesi fa...


Io trovo già una bella cosa che uno step A0 su una nuova architettura e nuovo processo produttivo semplicemente funzioni.:D
Gli A0 dei K10 sono stati usati come portachiavi...:asd:

[george_p]

Io trovo già una bella cosa che uno step A0 su una nuova architettura e nuovo processo produttivo semplicemente funzioni.:D
Gli A0 dei K10 sono stati usati come portachiavi...:asd:
:eek: :) :cool: :D
Apperò

[capitan_crasy]

:eek: :) :cool: :D
Apperò

Eccolo!
http://i.imgur.com/22YnHRB.jpg
Per ora non riesco a trovare il primo piano del porta chiavi con il quad core del K10 in bella vista...:asd:

[george_p]

Eccolo!
http://i.imgur.com/22YnHRB.jpg
Per ora non riesco a trovare il primo piano del porta chiavi con il quad core del K10 in bella vista...:asd:

Ahahahaha ma chissà se amd ha recuperato un pò di dindini vendendoli come portachiavi :sofico:

[tuttodigitale]

Non si ancora che fonderia useranno...ma è ovvio che useranno Zen, non possono usare Jaguar su una APU del genere (6tflops di elaborazione grafica..)
e perchè mai no?
Alla fine le attuali console hanno avuto come limite le gpu...per un "solo" +100-130% di potenza grafica un +30% lato cpu basta e avanza, imho

[Free Gordon]

e perchè mai no?
Alla fine le attuali console hanno avuto come limite le gpu...per un "solo" +100-130% di potenza grafica un +30% lato cpu basta e avanza, imho


Da 1,3Tflops (attuale XboxONE) a 6Tflops (Scorpio)...ce ne passa di acqua sotto i ponti....

[paolo.oliva2]

e perchè mai no?
Alla fine le attuali console hanno avuto come limite le gpu...per un "solo" +100-130% di potenza grafica un +30% lato cpu basta e avanza, imho

Ma nel 2017 presumibilmente bisognerà vedere cosa offrirà il commercio con 400€... Va bene che chi acquista una console è stile un cartone e via, ma con Zen X4 APU io prevederei dei mobili X4+4 con la parte X86 nettamente superiore e la grafica non da meno considerando pure un limite TDP sul procio ma un CF su mobo.

Io ho aperto il mio BW e la mobo è tutt'altro che pulita rispetto a quello che potrebbe essere una AM4. Addirittura il wireless è su scheda marcata Intel su slot, e questo solamente lato inferiore, lato superiore non l'ho smontato.

[cdimauro]

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/07/AMD_GCN3_Instruction_Set_Architecture.pdf

Questa è GCN1.2 (ora con Polaris sono alla terza revision)
Molto interessante, grazie.

Purtroppo per un confronto fra VLIW e SIMD/GCN1.0 servirebbero i manuali di entrambi, perché ovviamente ci saranno delle notevoli differenze (come ci sono già fra GCN 1.1 e 1.2, come puoi vedere a pag. 15).

Al momento la cosa che mi ha sorpreso è vedere un design CISC per l'architettura, che è a lunghezza variabile. :D
Scorpio (l'unica APU Zen di cui abbiano notizia certa oggi), ha un bus a 384 bit che accede a 12 moduli di GDDR5. Stessa cosa per PS4 e PS4 Neo (tutte con controller per GDDR5).
Quindi per ora non si sa se faranno APU solo dotate di HBM o no..
Scorpio avrà 12GB.

Comunque non si sa ancora se userà core Zen o Jaguar. Io propendo per i secondi.
le architetture VLIW di AMD non rinunciavano mica al design SIMD.
OK. Quindi rozzamente la differenza fra VLIW e SIMD starebbe nella possibilità, per il primo, di poter eseguire più istruzioni impacchettate nel bundle, mentre il secondo ne esegue solo una (o scalare o vettoriale).

Ma impacchettare istruzioni utili nel bundle VLIW non è cosa facile da realizzare: per quanto buono possa essere il compilatore, ci saranno delle NOP infilate nel bundle (con che frequenza, dipende dal tipo di codice).
per la verità non è molto chiaro....
è vero che HSA sarebbe utile anche nei giochi, ma al più è stato pubblicizzato solo come acceleratore della fisica....con l'apu che diventa una sorta di CELL.
l'intento teorico, è quello di far lavorare CPU e GPU in perfetta sinergia tra loro, anche se in effetti stanno snaturando la seconda...
Prima volevo rimarcare che HSA è utile per entrambe le cose: operazioni "generiche" e giochi. Mentre le modifiche apportate agli shader core in ottica general purpose sono, per l'appunto, utilizzabili in quest'ambito e i giochi se ne faranno poco o niente.
le funzionalità general purpose del chip va proprio in ottica HSA, perchè con questo paradigma AMD si è prefissato l'obiettivo di poter sfruttare i vantaggi offerti dalla potenza offerta dalle GPU, su un numero crescente di applicazioni

http://techreport.com/r.x/amd-fad-2012/hsa-feature-roadmap.jpg
Ne sono al corrente, ma sappiamo entrambi che richiede un notevole sforzo da parte degli sviluppatori.

E' già difficile oggi cercare di sfruttare più core/thread hardware con una CPU, per cui figuriamoci adattare il codice per poter sfruttare i core delle GPU.
Uno scambio di PVT con un utente mi ha fatto ritornare la memoria (sono passati almeno 2 anni): ho provato ad eliminare l'esponenziale, per verificare l'ipotesi (ovviamente il calcolo non era più quello giusto, ma lo scopo era solo trovare il collo di bottiglia) e non cambiava nulla, quindi il collo di bottiglia era la cache L1.
OK. Che poi è tipico quando si usa un filtro di convoluzione.
E' la HBM2 che ha doppia banda e fino a 8 GB per chip. La HBM1 si ferma a 1GB. Con 4 chip sarà possibile fare una GPU o una APU con 32GB... Per socket. Più che sufficiente per il consumer con un solo socket e da vedere se sarà sufficiente in ambito server... Ma si può sempre arrivare a 8 chip... Lo spazio c'è...
Dipende anche da come verrà usata questa HBM. Mi riferisco ai core della CPU.

Sicuramente in ambito server è necessaria parecchia memoria, e anche 32GB possono essere un grosso limite.
probabilmente lo è: pensa che un modulo XV è 4,4x volte più grande di 2 core Jaguar ed entrambi usano le HDL...e Jaguar ha un ipc, credo innavvicinabile per l'a57,
Lo credo anch'io, visto che già un vecchio Atom 2-wide e in-order aveva prestazioni simili all'A57.

Jaguar, essendo out-of-order, andrà enormemente meglio.
e ha la pesante, così si dice, ISA x86....
Questa non incide molto sul totale né a livello di transistor né sui consumi. Ma non posso aggiungere altro.
non oso immaginare ZEN quanto possa essere più grosso...le differenze sarebbero poi mitigate dalla presenza delle cache l2 e l3, ma non credo che incidano più di tanto sui consumi.
Ma non s'era detto che un core Zen fosse grosso modo grande quanto un XV?
Ma poi a parte la potenza, paghi la progettazione e il tutto per avere nel 2017 un Jaguar?
Perché no? E' un buon core, minuscolo, che consuma poco, e con ottime prestazioni.

Sarebbe sensato continuare a usarlo, sicuramente con frequenze aumentate, ma magari con più core a disposizione.
Già secondo me sarebbe improbabile con la potenza attuale, ma personalmente io sono dell'idea che a prescindere da quale potenza avrà Zen, sicuramente AMD aumenterà il numero di core e di cascata dovrà farlo pure Intel, poi nel 2018 non si passerebbe ai 7nm?
Bisogna vedere cosa porteranno questi fantomatici 7nm.

Se guardi i numeri riportati da tuttodigitale, i 14/16nm non è che siano una gran rivoluzione: 1,7x meglio dei 28nm riguardo alla superficie del chip (e quindi rozzamente sono dei 21nm reali), ma molto meno se vai a guardare i transistor impacchettati in quell'area. E da quest'ultimo punto di vista, non è che ti puoi aspettare tanti core impacchettati.
Il tizio dice che l'ES A0 era 1.8/2.4GHz (non so se è base/turbo oppure se erano più di uno), ma A0 vuol dire primissimo silicio che può essere anche non funzionante e invece questo funzionava...
Bisogna vedere COSA funzionasse. ;)
Quello di 3GHz magari era uno degli ultimi... A0 può voler dire novembre 2015... 8 mesi fa...
In genere hai 2-3 tapeout per lo stepping A, e ogni tapeout richiede circa 3 mesi. Un paio per lo stepping B. E poi a partire dal primo tapeout dello stepping C è possibile che si possa procedere alla commercializzazione.
vedi sopra... Se ci vogliono 2 mesi tra un ES e l'altro (non mi ricordo) ne sono già stati fatti 4...
Sono necessari 3 mesi.

Comunque io non farei ipotesi sulla base della frequenza degli ES. Ci sono ES A0 che raggiungono basse frequenze, mentre il prodotto finale avrà frequenze di gran lunga più elevate. E viceversa, ES A0 che hanno una buona frequenza, ma il prodotto finale non l'aumenterà di molto.

Sono ES, non a caso... ;)
e perchè mai no?
Alla fine le attuali console hanno avuto come limite le gpu...per un "solo" +100-130% di potenza grafica un +30% lato cpu basta e avanza, imho
Esattamente. Ma se vogliono raggiungere i 60 FPS, la potenza degli attuali core non basterà, per cui aumenteranno le frequenze, e magari metteranno un altro po' di core Jaguar.

Ma passare a Zen è insensato: è un core enorme e non può offrire le stesse prestazioni aggregate della batteria di core Jaguar. Soprattutto contenendo i consumi.
Da 1,3Tflops (attuale XboxONE) a 6Tflops (Scorpio)...ce ne passa di acqua sotto i ponti....
Per la grafica. Ma la CPU non si deve sobbarcare il lavoro più pesante. Vedi sopra. ;)

[paolo.oliva2]

http://m.hexus.net/tech/news/cpu/93140-amd-slide-shows-zen-cpu-offers-double-fx-8350-performance/

Qui ci sarebbe una sfide dove AMD riporta che Zen X8 andrebbe tanto quanto 2 8350.
È vecchia, ma la riporto perché è ufficiale (io pensavo rumors) e vorrei esporre una riflessione.

AMD riporta che Zen avrebbe >+40% di IPC su XV e sommando l'incremento di XV su PD, diciamo che saremmo a +70% su PD, e con +30% di SMT arriveremmo a +210%.

Ora, Zen allo stesso clock di PD deve dare quanto 2,1 * 8350 e non 2, diverso nel caso di Zen <4GHz, tipo 3,8GHz.

Però devo capire perché un 5960x andrebbe quanto 2 8350. È vero? Perché non può essere una media... Se un Zen X8 come riferito da AMD andrebbe tanto quanto due 8350, e il 5960X uguagliasse Zen, vorrebbe dire che la differenza di IPC sarebbe uguale allo differenza di clock tra 3,8GHz (Zen) e 3GHz (5960X) il che non torna, assurdo ~-27%.

Se un Zen ? Cioè... In base a cosa? Se la differenza di IPC tra Zen e 5960x sarebbe minima, come si sp

Ora, se AMD riporta Zen X8 = 2 * 8350, qualche cosa non torna, o Zen ha un incremento IPC inferiore se hanno fatto il confronto a parità di frequenza per valutare il core Zen Vs modulo PD, oppure Zen avrebbe una frequenza < ai 4GHz di un 8350.

[tuttodigitale]

Esattamente. Ma se vogliono raggiungere i 60 FPS, la potenza degli attuali core non basterà, per cui aumenteranno le frequenze, e magari metteranno un altro po' di core Jaguar.

Ma passare a Zen è insensato: è un core enorme e non può offrire le stesse prestazioni aggregate della batteria di core Jaguar. Soprattutto contenendo i consumi.
ma soprattutto , non torna con le tempistiche....ZEN non è pronto per il mercato in volume..

oggi, in realtà non sappiamo quanto i 30 fps siano dovuti alla CPU e quanto alla oggettiva scarsa potenza delle GPU...
ad esempio killzone gira 900p@60 fps e [email protected] gpu
diversi titoli di xbox che girano a 1080p a 30fps girano a 60 su ps4, come Tomb-Raider....


la frequenza, sempre stando alle indiscrezioni, passerà dai 1,6 a 2,1GHz, un incremento non certo da poco. E infine al momento vengono utilizzati solo 6 core Jaguar su 8...gli altri 2 sono riservati. Magari, grazie al maggior clock, e a True Audio, sarà possibile usare il settimo core.

Poi si sta perdendo di vista il fatto che i software essendo fatti su una specifica CPU, possono estrarre un livello di prestazioni superiori, senza contare il fatto che, almeno PS4, e maggior ragione nelle future console, non c'è bisogno della copia dei dati....
all'improvviso ci stiamo dimenticando che le console sono scatolette chiuse..

Da 1,3Tflops (attuale XboxONE) a 6Tflops (Scorpio)...ce ne passa di acqua sotto i ponti....
dai 1,84TFLOPs ai 5/6TFLops già molto meno :D e la Ps4 ha una versione a più basso clock di jaguar (1,6 vs 1,75GHz)

Non si ancora che fonderia useranno...ma è ovvio che useranno Zen, non possono usare Jaguar su una APU del genere (6tflops di elaborazione grafica..)
Le indiscrizione danno i 14nm, e stando alle diverse informazioni, parebbe una scelta logica.


Non è che sia un sciocchezzuola...è che AMD ha degli SP in idle (conta che una 1070 fa 6,5Tflops di picco...un pò meno di una Fury liscia ma guarda le differenze di performance. :D ), Nvidia ha un'occupazione molto più alta, rendendo inutile l'implementazione degli ACE nella sua archtettura. Certo, AMD ha un sacco di "room" in più da sfruttare, ecco perchè GCN è utile nelle console... :)
Non hai detto nulla di diverso :)
GCN è stato concepito con ACE in mente. Maxwell e compagnia no.

[paolo.oliva2]

@cdimauro
Il 14nm per quanto riguarda l'incremento di potenza a core, poco o nulla (ma questo bisogna vedere il PP), ma per quanto riguarda la potenza a die, 65W con un X22 a 1,7GHz e/o 135W a 2,2GHz sono un miglioramento enorme.
Secondo me bisogna vedere il futuro... Cioè, se mettiamo l'ancora al software, e si rimane sui 4 core, la differenza da oggi è che ci ritroveremo un PC in un telefonino ma con le prestazioni di oggi. Se invece il software si evolve, e si percorre la strada di parallelizzare quello che si può parallelizzare (ma che oggi lo si fa in minima parte), allora la miniaturizzazione del silicio ha un senso al di fuori dell'ecologismo e del max dei core per server.

P.S.
Io non mi intendo di software, ma per me il processore cerca di emulare il cervello umano. Il più grande elaboratore esistente arriva al 10% della potenza di un cervello di un topo, che a sua volta è il 10% di quello umano. Il mio pensiero è che per singole funzioni il processore è già ben più potente del cervello umano (vedi calcoli, tempi di risposta esempio sensori) ma perde enormemente nella sinergia dell'insieme.
Fantasticando, per realizzare un sistema stile cervello umano sicuramente avremmo problemi con il numero di unità di calcolo, con la mole di dati da rendere stile memoria, e quant'altro, ma credo che la vera distanza è che siamo anni luce distanti da un software con un motore AI in grado di gestire il tutto, ben di più di quanto non lo siamo a livello di procio e nanometri silicio.

[paolo.oliva2]

@Tuttodigitale
Ma che capacità ha GF?

Cacchio, va bene che la catena 32nm SOI la smantellerá e ridurrà quella 28nm Bulk, ma il 14nm dovrà far fronte anche alle VGA (prima erano di TSMC), tutti i chip custom per terzi, a Zen che da solo presumibilmente avrà una produzione di wafer ben superiore a quella di BD, cioè... è una vita (e una montagna di € per GF).

[tuttodigitale]

@Tuttodigitale
Ma che capacità ha GF? .
conta anche che con costi "irrisori" si può trasportare la produzione nelle FAB Samsung, che dovrebbero avere una eccellente capacità produttiva. Se ti ricordi, c'era una testata coreana che tempo fa parlava di produzione ANCHE dalle fab della casa coreana..

La FAB8 ha una capacità produttiva di 60.000 wafer al mese. Per contro le 2 FAB di Dresda insieme ne producono 50.000

http://www.extremetech.com/gaming/219859-samsung-globalfoundries-to-fab-next-gen-amd-gpus-apus

La cosa ha senso...usare lo stesso silicio per gpu e cpu e apu, permette di ridurre i costi per la messa a punto..

[paolo.oliva2]

conta anche che con costi "irrisori" si può trasportare la produzione nelle FAB Samsung, che dovrebbero avere una eccellente capacità produttiva. Se ti ricordi, c'era una testata coreana che tempo fa parlava di produzione ANCHE dalle fab della casa coreana..

La FAB8 sui 28nm aveva una capacità produttiva di 60.000 wafer al mese

http://www.extremetech.com/gaming/219859-samsung-globalfoundries-to-fab-next-gen-amd-gpus-apus

La cosa ha senso...usare lo stesso silicio per gpu e cpu e apu, permette di ridurre i costi per la messa a punto..

Certo che sia conveniente fare tutto con lo stesso silicio, però sono pur sempre die di rilievo, Zen è un X8 e valutando una dimensione die 5/6 di un 8350, il passaggio dal 32nm al 14nm non produrrebbe un gran aumento di die a wafer (e il volume c'è, visto che l'intera produzione server sará su Zen X8), Carrizo ha 3,2 milioni di transistor (tra iGPU, HSA nativa), quindi nel travaso a Zen e potenziamento iGPU, credo che aumenterà i transistor, si parla poi addirittura di un APU Zen X16.

[paolo.oliva2]

Tra parentesi, un Zen APU X16 desktop lo trovo innaturale, già sarebbe strapotente un X8 APU, quindi presumerei abbia un indirizzo server nei campi compatibili con HSA.

C'è qualche rumor su HSA? Perché io ci vedrei un qualche cosa sotto che bolle... fino a pre-Zen AMD non faceva altro che sbandierare HSA, poi ora sembra quasi "si, abbiamo la nuova architettura Zen, se lo faremmo APU? Ma, penso di si" e poi sotto un X16 Zen APU che sembra urlare "Zen sarà l'APU del domani", a me puzza di novità nascoste.

[Ren]

Ora ho capito perchè su semiaccurate ci sono tutti quei pessimisti... Il primo ES (A0) aveva frequenza 2.4GHz... E da li a dire che non supererà i 3GHz... Ma lo step A0 probabilmente sarà quello di novembre 2015 e il primo in assoluto... Ne è passato di tempo...

Io leggo di "ondate di pessimismo" anche sul 14nm LPP, soprattutto quando si parla di alte frequenze.


Juanrga prevede 3.1ghz base clock... :sob:


Io trovo già una bella cosa che uno step A0 su una nuova architettura e nuovo processo produttivo semplicemente funzioni.:D
Gli A0 dei K10 sono stati usati come portachiavi...:asd:

http://fricat.altervista.org/immagini/gianni.gif

[george_p]

Io leggo di "ondate di pessimismo" anche sul 14nm LPP, soprattutto quando si parla di alte frequenze.


Juanrga prevede 3.1ghz base clock... :sob:


Chi è juanrga?
Un ingegnere del silicio?
Su cosa basa le sue previsioni, sulla sfera di cristallo?
Perché le sue previsioni hanno valore uguale a quelle di chi azzarda 4.5GHz, cioè pari a zero.

Il che non vuol dire che zen avrà frequenze superiori o inferiori.
Semplicemente ognuno senza sapere una cippa di niente fa il suo pronostico che potrà andare a coincidere o meno su quello che sarà il risultato nella realtà.

[Ren]

Chi è juanrga?
Un ingegnere del silicio?
Su cosa basa le sue previsioni, sulla sfera di cristallo?
Perché le sue previsioni hanno valore uguale a quelle di chi azzarda 4.5GHz, cioè pari a zero.

Il che non vuol dire che zen avrà frequenze superiori o inferiori.
Semplicemente ognuno senza sapere una cippa di niente fa il suo pronostico che potrà andare a coincidere o meno su quello che sarà il risultato nella realtà.

Il fratello pessimista di/dei Gianni l'ottimista...:sofico:

Ho aggiunto al quadro esposta da bjt2 gli altri "pessimismi" e l'analisi di un altro utente "competente", se vuoi leggere altro vai su semiaccurate.

cmq, vedo che sei d'accordo sul totocalcio regnante, visti i pochissimi dati certi...

ps. non ti agitare che fa caldo.;)

[george_p]

Il fratello pessimista di/dei Gianni l'ottimista...:sofico:

Ho aggiunto al quadro esposta da bjt2 gli altri "pessimismi" e l'analisi di un altro utente "competente", se vuoi leggere altro vai su semiaccurate.

cmq, vedo che sei d'accordo sul totocalcio regnante, visti i pochissimi dati certi...

ps. non ti agitare che fa caldo.;)

Personalmente non sono d'accordo con nessuno, leggo e basta.
Poi come ho sempre scritto, quando uscirà Zen si vedrà, punto.

A me sembra che chi si agita e va in fermento per i post di Gianni sia tu che ti da tanto fastidio ogni volta che lo leggi e lo punzecchi :)
Ti da tanto di quel fastidio ed è parecchio evidente dai tuoi continui post provocatori ;)

[tuttodigitale]

Io leggo di "ondate di pessimismo" anche sul 14nm LPP, soprattutto quando si parla di alte frequenze.


Juanrga prevede 3.1ghz base clock... :sob:




http://fricat.altervista.org/immagini/gianni.gif
3,1GHz base non sono in assoluto pochi. c'è anche chi ha sparato 2,4-2,6 GHz (non scherzo). L'aveva riportato bjt2..

ci sono tutte le ragioni per essere ottimisti.

[capitan_crasy]

http://fricat.altervista.org/immagini/gianni.gif

Gianni è morto, la sua testa era esposta in magazzino con la scritta "Era troppo ottimista ed era uno stronzo"!:read:
http://www.capitancrasy.com/images/ciro00.gif

[paolo.oliva2]

Comunque non c'è da essere pessimisti.
AMD ha riportato ufficialmente che Zen va il doppio di un 8350.
Basta fare 2 conti, l'incremento IPC è dichiarato, quindi per trovare la frequenza basta calcolare.
A spannella Zen guadagna il 70% di IPC su PD, a cui va aggiunto il 30% di SMT, totale 221. Se Zen avesse la stessa frequenza di 4GHz, farebbe più del doppio, cioè un +10. Se perde quel 10% (e se L'IPC è quello dichiarato) è ovvio che avrà una frequenza di poco inferiore ai 4GHz di PD, ma il di poco vuole dire sopra i 3,7GHz.

Quelli che sparano addirittura frequenze sotto i 3GHz lo fanno solo per bandiera (perché AMD non può avere frequenze superiori ad Intel, come se fino ad ora non le ha avute), ma non lo dico per pro AMD, ma mi sembra lampante che guadagnare +70% di IPC ma nel contempo perdere 33% di clock, vorrebbe dire che nel complesso uno Zen X8 sarebbe più potente di un 8350 manco del +50%, al che, a culo l'SMT e restiamo in BD col suo bel CMT e XV X16 che risulterebbe +50% di quel Zen.

[cdimauro]

http://m.hexus.net/tech/news/cpu/93140-amd-slide-shows-zen-cpu-offers-double-fx-8350-performance/

Qui ci sarebbe una sfide dove AMD riporta che Zen X8 andrebbe tanto quanto 2 8350.
È vecchia, ma la riporto perché è ufficiale (io pensavo rumors) e vorrei esporre una riflessione.

AMD riporta che Zen avrebbe >+40% di IPC su XV e sommando l'incremento di XV su PD, diciamo che saremmo a +70% su PD, e con +30% di SMT arriveremmo a +210%.

Ora, Zen allo stesso clock di PD deve dare quanto 2,1 * 8350 e non 2, diverso nel caso di Zen <4GHz, tipo 3,8GHz.

Però devo capire perché un 5960x andrebbe quanto 2 8350. È vero? Perché non può essere una media... Se un Zen X8 come riferito da AMD andrebbe tanto quanto due 8350, e il 5960X uguagliasse Zen, vorrebbe dire che la differenza di IPC sarebbe uguale allo differenza di clock tra 3,8GHz (Zen) e 3GHz (5960X) il che non torna, assurdo ~-27%.

Se un Zen ? Cioè... In base a cosa? Se la differenza di IPC tra Zen e 5960x sarebbe minima, come si sp

Ora, se AMD riporta Zen X8 = 2 * 8350, qualche cosa non torna, o Zen ha un incremento IPC inferiore se hanno fatto il confronto a parità di frequenza per valutare il core Zen Vs modulo PD, oppure Zen avrebbe una frequenza < ai 4GHz di un 8350.
Quel test su Zen 8 core vs 8350 riguarda esclusivamente Cinebench R15 in multithreading (c'è scritto pure "Compute", ma che vuol dire? In genere è CPU), e dunque i risultati non puoi generalizzarli.

E' ben noto che Cinebench sfrutti bene il multithreading, ma non è così con tutti i programmi, anche multithreaded. Tutt'altro.
ma soprattutto , non torna con le tempistiche....ZEN non è pronto per il mercato in volume..
Infatti le voci parlano di un lancio per fine anno, ma in realtà i volumi arriveranno nel 2017.
oggi, in realtà non sappiamo quanto i 30 fps siano dovuti alla CPU e quanto alla oggettiva scarsa potenza delle GPU...
ad esempio killzone gira 900p@60 fps e [email protected] gpu
diversi titoli di xbox che girano a 1080p a 30fps girano a 60 su ps4, come Tomb-Raider....
Vero, ma in genere si tagliano i dettagli se non ci si arriva. Inclusa quanta roba la CPU debba elaborare.

Ma questo lo sanno di preciso gli sviluppatori, ovviamente.
la frequenza, sempre stando alle indiscrezioni, passerà dai 1,6 a 2,1GHz, un incremento non certo da poco.
Sarebbe di meno per Scorpio, perché l'XBoxOne parte da 1,75Ghz.
E infine al momento vengono utilizzati solo 6 core Jaguar su 8...gli altri 2 sono riservati. Magari, grazie al maggior clock, e a True Audio, sarà possibile usare il settimo core.
E' plausibile, ma magari mettono pure un altro cluster (4 core) Jaguar. Occupano poco spazio, e passando ai 14nm occupano ancora meno.
Poi si sta perdendo di vista il fatto che i software essendo fatti su una specifica CPU, possono estrarre un livello di prestazioni superiori, senza contare il fatto che, almeno PS4, e maggior ragione nelle future console, non c'è bisogno della copia dei dati....
all'improvviso ci stiamo dimenticando che le console sono scatolette chiuse..
Questo varrebbe anche nel caso (IMO irreale) in cui Zen fosse adottato per le prossime console, ma in ogni caso il framerate delle console attuali viene generato nelle condizioni che hai descritto, e purtroppo non è un granché al momento.
dai 1,84TFLOPs ai 5/6TFLops già molto meno :D e la Ps4 ha una versione a più basso clock di jaguar (1,6 vs 1,75GHz)
Esatto. Ma è pure quella che avrà una GPU molto meno potente in futuro.
@cdimauro
Il 14nm per quanto riguarda l'incremento di potenza a core, poco o nulla (ma questo bisogna vedere il PP), ma per quanto riguarda la potenza a die, 65W con un X22 a 1,7GHz e/o 135W a 2,2GHz sono un miglioramento enorme.
Secondo me bisogna vedere il futuro...
Non ci sono informazioni per poter parlare di numeri, a parte quelle su IPC e processo produttivo. Riguardo alle prestazioni, vedi sopra.
Cioè, se mettiamo l'ancora al software, e si rimane sui 4 core, la differenza da oggi è che ci ritroveremo un PC in un telefonino ma con le prestazioni di oggi. Se invece il software si evolve, e si percorre la strada di parallelizzare quello che si può parallelizzare (ma che oggi lo si fa in minima parte), allora la miniaturizzazione del silicio ha un senso al di fuori dell'ecologismo e del max dei core per server.
Mi spiace, ma il software è proprio una brutta bestia, e non è affatto facile parallelizzarlo. Tutt'altro, visto che ci sono tanti algoritmi che non lo sono per niente. Qualora ciò fosse possibile, potrebbe anche non essere affatto conveniente considerato il rapporto fra sforzo e miglioramento prestazionale.
P.S.
Io non mi intendo di software, ma per me il processore cerca di emulare il cervello umano. Il più grande elaboratore esistente arriva al 10% della potenza di un cervello di un topo, che a sua volta è il 10% di quello umano. Il mio pensiero è che per singole funzioni il processore è già ben più potente del cervello umano (vedi calcoli, tempi di risposta esempio sensori) ma perde enormemente nella sinergia dell'insieme.
Fantasticando, per realizzare un sistema stile cervello umano sicuramente avremmo problemi con il numero di unità di calcolo, con la mole di dati da rendere stile memoria, e quant'altro, ma credo che la vera distanza è che siamo anni luce distanti da un software con un motore AI in grado di gestire il tutto, ben di più di quanto non lo siamo a livello di procio e nanometri silicio.
Lasciamo stare il cervello umano, che funziona in maniera molto diversa. :)

[paolo.oliva2]

Qui si riporta che il 5960X va il doppio di un 8350 solamente sulla base del risultato di cinebench 15. Però guardando altri bench di confronto, ci sono cose dove il 5960X va anche di più ma altre dove va anche di meno, ed è ovvio perché PD è un BD ma con una architettura di 6 anni fa e non aggiornata con i set di istruzioni ed alcune cose non può risolverle nativamente. È impensabile che Zen non sia più che aggiornato per risolvere nativamente quello che oggi il software richiede, ed inoltre avendo una potenza ST ben superiore a PD (e le medie di performances hanno per un 50% l'ST), un Zen che va il doppio di un 8350 in MT di certo in ST non può andare come un 8350 ma ben di più.

A me non interessa se un Zen X8+8 andrà quanto un 6900k o un 6950k o un 6850k, ma siccome la produzione di QUESTO Zen ha come base X8 e si parla di riciclo fallati al max X6, è mia (personalissima) opinione che AMD non commercializzerà Zen X8 prezzandolo sulla fascia 2011 Intel, ma ricercherà volumi che può ottenere unicamente prezzandolo come alternativa alla fascia alta 1155 e bassa 2011, e questo è indipendente dalla potenza ottenuta ma più un rapporto sul costo (un po' sulla riga rx480).

Sulla base di questo mio pensiero, AMD potrebbe pure ricercare più potenza con un modello top Zen X12 (anche perché se Intel propone al max un X22 a 65W Vs un Zen X32 a 45W, e Intel nel desktop riesce a commercializzare un X10, AMD sullo stesso metro potrebbe commercializzare un Zen X16) ovviamente più costoso, ma il centro di ogni aspettativa è di quanto incrementerà la potenza Zen, a che prezzo e quanto si occherà. Un Zen che va il doppio di un 8350 valutato con lo stesso metro di un 5960x, per me non è parziale, tutt'altro.

[stefanonweb]

Scusate, ma se parlate di Zen forse ad Ottobre a 14 nm... Bristol Ridge a 28 nm quando uscirebbe e con che scopo? Siamo sicuri che i 28 nm ci saranno, oppure si potrebbe passare subito ai 14 nm? Ed allora BR che senso avrebbe... poi con delle tempistiche moto ravvicinate a Zen... :read: Grazie.

[george_p]

Scusate, ma se parlate di Zen forse ad Ottobre a 14 nm... Bristol Ridge a 28 nm quando uscirebbe e con che scopo? Siamo sicuri che i 28 nm ci saranno, oppure si potrebbe passare subito ai 14 nm? Ed allora BR che senso avrebbe... poi con delle tempistiche moto ravvicinate a Zen... :read: Grazie.

MA BR è un Apu mentre Zen inizialmente no, solo core X86 pura.
BR dovrebbe venire sostituito da Zen Apu nel 2017.
Cmq personalmente BR mi sembra quasi quasi più un paper launch cisto che doveva già essere uscito da tempo nel 2016.
E penso che lo vedremo in poche quantità, tra l'altro non mi spiego nemmeno perché amd abbia commercializzato godavari (7870K) che si pone sullo stesso piano o quasi di BR.
Di quest'ultimo ho visto solo slide di comparazioni e niente più.
Probabilmente se esce davvero sarà a settembre e l'apu zen sarà almeno un anno dopo.
Mi speculazione personale ovvio :)

[bjt2]

Dresdenboy ha postato un link a questo FPU generator:

https://sites.google.com/a/stanford.edu/fpgen/tapeout

Guardate anche le altre pagine.
In pratica il meglio che hanno fatto sul 28nm FDSOI in termini di velocità è una FPU a 3.4GHz@1V che consuma circa (32mW*GFlops*3.4*2GFlops) 218mW per una FMAC FP32, quindi una FPU in grado di fare 8x32=256 bit FMAC a 3.4GHz, consumerebbe 1744mW.

Hanno fatto anche altre versioni a clock più basso (900-1350 MHz), più efficienti per consumo o per area ed hanno fatto il tapeout di un chip di test nel 2013

Transistors LVT (si vede dal BIAS di 1.2V).

Se AMD ha usato queste FPU... Non oso pensare...

[tuttodigitale]

Cmq personalmente BR mi sembra quasi quasi più un paper launch cisto che doveva già essere uscito da tempo nel 2016.
non penso proprio che sia un paper launch alla fine il die di BR è diverso da quello visto in Carrizo, e probabilmente Carrizo come doveva essere nel 2015

http://cdn.wccftech.com/wp-content/uploads/2013/11/AMD-Carrizo-APU-Desktop-Roadmap.png

sono quasi sicuro, che l'apu che uscirà nel 2017 sia basata su ZEN+.

[george_p]

non penso proprio che sia un paper launch alla fine il die di BR è diverso da quello visto in Carrizo, e probabilmente Carrizo come doveva essere nel 2015


sono quasi sicuro, che l'apu che uscirà nel 2017 sia basata su ZEN+.

Ma questo deve essere il minimo se Zen+ è in programma per il 2017 (fine?), se no cosa metti una parte X86 "vecchia"?

D'altra parte anche Zen prima versione non dovrebbe essere male per un apu quadcore con Smt, di sicuro il balzo in avanti dopo anni e anni di apu lo fa a prescindere.

[Free Gordon]

Molto interessante, grazie.
Purtroppo per un confronto fra VLIW e SIMD/GCN1.0 servirebbero i manuali di entrambi, perché ovviamente ci saranno delle notevoli differenze (come ci sono già fra GCN 1.1 e 1.2, come puoi vedere a pag. 15).
Al momento la cosa che mi ha sorpreso è vedere un design CISC per l'architettura, che è a lunghezza variabile. :D

Cosa ti sorprende? non ho capito cosa vuoi dire.

[paolo.oliva2]

Secondo me BR va inquadrato solamente nel fatto che era stato progettato ben prima dell'ES di Zen (e quindi AMD non poteva sapere i tempi di Zen + 14nm) e avendo fatto (e speso) gran parte del lavoro... Poi il fatto di stare zitti su Zen APU io non lo vedo come una notevole distanza di tempo, ma più un fatto commerciale; se AMD dicesse Zen APU a febbraio 2017, chi si comprerebbe BR?
Per me Zen+ non sarà altro che Zen + igp + HBM/HBM2 e l'incremento prestazionale altro non sarebbe che la maggior velocità delle HBM che per mezzo di Huma farebbero sia da L3 che da Ram per l'IGP e magari qualche ottimizzazione architetturale magari condita da funzioni HSA implementate nell'hardware del procio che non necessitano di compilazioni apposite.
Una volta be succedeva quando il coprocessore matematico era un chip a parte? Il software era sempre quello ma era l'hardware che a seconda da della presenza del coprocessore smistava le operazioni. Se AMD sbandiera Carrizo compatibile nativamente a HSA 1.0, dovrà offrire qualche cosa in più rispetto a non averla.

Ritornando a Zen, Zen APU... Polaris oramai è ultimata, Zen X86 idem, AMD dalla sua ha una competenza in APU al top, il 14nm oramai lo conosce, non ci vedo tempi extra-large per un Zen APU, perché non vedo un progetto da zero ma più un progetto addirittura in contemporanea a Zen X86, però rallentato nell'evoluzione per attendere il completamento di Polaris, quindi per me un +6 mesi da Zen X86 sarebbero già più che sufficienti.

[Ren]

Quel test su Zen 8 core vs 8350 riguarda esclusivamente Cinebench R15 in multithreading (c'è scritto pure "Compute", ma che vuol dire? In genere è CPU), e dunque i risultati non puoi generalizzarli.

E' ben noto che Cinebench sfrutti bene il multithreading, ma non è così con tutti i programmi, anche multithreaded. Tutt'altro.


Aggiungo che BD ha FPU condivise, non ci vedo nulla di straordinario in quel risultato al cinebench...;)

[Free Gordon]

Aggiungo che BD ha FPU condivise, non ci vedo nulla di straordinario in quel risultato al cinebench...;)

Finalmente con Zen siamo ritornati a Deneb/Thuban?? :sofico:

Quelli alla fine erano buoni proci. Certo, non superavano Intel ma gli stavano perlomeno dietro..

[Ren]

Finalmente con Zen siamo ritornati a Deneb/Thuban?? :sofico:

Quelli alla fine erano buoni proci. Certo, non superavano Intel ma gli stavano perlomeno dietro..

Erano bei tempi...:cry:

[paolo.oliva2]

Finalmente con Zen siamo ritornati a Deneb/Thuban?? :sofico:

Quelli alla fine erano buoni proci. Certo, non superavano Intel ma gli stavano perlomeno dietro..

Non dimentichiamoci del silicio... Il modulo di BD doveva controbattere il core + HT di Intel. È ovvio che se il 32nm permetteva a BD 4 moduli in 1,2 milioni di transistor 125W ed Intel sul 22nm ci metteva 2,5 milioni di transistor in 140W con 8 core + HT, è ovvio che poi Intel possa ottenere una potenza doppia a die. Se oggi il 14nm permetterebbe 8 moduli/16 core XV, tu vedi una differenza in MT con un 6900k? Io non ne vedo... Quindi se stiamo parlando sempre di BD, mi sembra ovvio che se cambiando silicio in MT si pareggerebbero le prestazioni con Intel, a cosa attribuire se non al silicio? Poi l'ST avrà i suoi problemi, ovviamente, ma se ipotizzassimo un Zen sul 32nm che avresti? Un X8 o un X4? Certamente più ST di BD ma altrettanto certamente non un maggiore MT/potenza die.

[tuttodigitale]

Aggiungo che BD ha FPU condivise, non ci vedo nulla di straordinario in quel risultato al cinebench...;)
FPu singola che non fa chissà quanto da collo di bottiglia.
più che altro sono 8 vs 16 thread
praticamente fare il doppio di un fx8350/2700k significherebbe spannometricamente essere nelle prossimità di un octa core Haswell da 3GHz. Per un 95W sarebbe un buon/ottimo risultato

Finalmente con Zen siamo ritornati a Deneb/Thuban?? :sofico:

Quelli alla fine erano buoni proci. Certo, non superavano Intel ma gli stavano perlomeno dietro..
in teoria a parità di thread, la FPu configurata come in ZEN, è più debole, per la mancata presenza di 2 AGU (le prestazioni nei calcoli floating point, dipendono anche dalla parte intera)...
mi aspetto che le prestazioni scalino peggio anche nei test fp-intensive. Scaling peggiore -> prestazioni ST superiori.


Alla fine denigrare il CMT è come denigrare il SMT....visto che le tecniche messe in atto sono estremamente simili....il CMT alla fine che cosa è, se non un implementazione parziale del SMT?

Quindi è assolutamente falso che si ritorna a thuban...la FPU è condivisa da 2 thread anche in ZEN....in aggiunta a questo a differenza di thuban/bulldozer non ci saranno alu/agu dedicate....ZEN si allontana ancora di più da thuban, e in un certo senso prosegue il cammino intrapreso con bulldozer.

E questo appunto si rifletterà sullo scaling, sensibilmente diverso (peggiore) da una soluzione con core ST come k10


Ritornando a Zen, Zen APU... Polaris oramai è ultimata, Zen X86 idem, AMD dalla sua ha una competenza in APU al top, il 14nm oramai lo conosce, non ci vedo tempi extra-large per un Zen APU, perché non vedo un progetto da zero ma più un progetto addirittura in contemporanea a Zen X86, però rallentato nell'evoluzione per attendere il completamento di Polaris, quindi per me un +6 mesi da Zen X86 sarebbero già più che sufficienti.
credo che in tutto questo lasso di tempo AMD abbia sviluppato anche ZEN+....è probabile che iniziano a mettere sul silicio direttamente l'architettura ZEN+ per le APU...
Vedo illogico, fare un nuovo prodotto, con un'architettura "vecchia"...come è stato per piledriver, si darà precedenza alle apu, imho. Introdotte a Maggio 2012, 5 mesi prima del fx8350.

http://www.anandtech.com/show/5831/amd-trinity-review-a10-4600m-a-new-hope

[paolo.oliva2]

credo che in tutto questo lasso di tempo AMD abbia sviluppato anche ZEN+....è probabile che iniziano a mettere sul silicio direttamente l'architettura ZEN+ per le APU...
Vedo illogico, fare un nuovo prodotto, con un'architettura "vecchia"...come è stato per piledriver, si darà precedenza alle apu, imho. Introdotte a Maggio 2012, 5 mesi prima del fx8350.

http://www.anandtech.com/show/5831/amd-trinity-review-a10-4600m-a-new-hope

Io penso che Zen+ sia la naturale evoluzione da X86 a APU, con la differenza che secondo me avrà sorprese rispetto agli APU precedenti.

Rispetto al link che hai postato, c'è una tabella che non capisco.
Verso la fine riporta le differenze tra Phenom II, BD e I7.
Sigle core peak decode rate. Io non conosco che mazza voglia dire, però messo così sembra quasi come capacità di elaborazione rispetto ai core.
Non comprendo... Perché BD regge tranquillamente 4TH a modulo, ovvero 2TH a core, mentre il Phenom II cala prestazionalmente con > di 1 TH a core, come l'i7 regge tranquillamente 2TH a core ma crolla con 3TH.
Li praticamente dice che un Thuban arriva a 18 istruzioni, un X6 I7 a 24 ed un FX X8 a 16? Ma se un 8350 regge un carico almeno 3 volte superiore ad un Thuban senza mostrare rallentamenti...

[cdimauro]

Dresdenboy ha postato un link a questo FPU generator:

https://sites.google.com/a/stanford.edu/fpgen/tapeout

Guardate anche le altre pagine.
In pratica il meglio che hanno fatto sul 28nm FDSOI in termini di velocità è una FPU a 3.4GHz@1V che consuma circa (32mW*GFlops*3.4*2GFlops) 218mW per una FMAC FP32, quindi una FPU in grado di fare 8x32=256 bit FMAC a 3.4GHz, consumerebbe 1744mW.

Hanno fatto anche altre versioni a clock più basso (900-1350 MHz), più efficienti per consumo o per area ed hanno fatto il tapeout di un chip di test nel 2013

Transistors LVT (si vede dal BIAS di 1.2V).

Se AMD ha usato queste FPU... Non oso pensare...
Come già detto prima per l'unità NEON, non prenderei in considerazione questi test su FPU così semplici (questa, poi, è enormemente più semplice persino di NEON). Un'FPU x87 è decisamente più complicata (anche perché fa molto di più), e dunque il suo power budget sarà ben diverso.
Cosa ti sorprende? non ho capito cosa vuoi dire.
In genere questi core sono molto semplici, per cui si usa un design RISC, e dunque con istruzioni aventi lunghezza fissa. Hanno lo svantaggio, però, di avere una più bassa densità di codice (e questo influisce su tutta la gerarchia della memoria).

Un design CISC è a lunghezza variabile, per cui richiede un decoder più complicato, ma per contro ha il vantaggio di avere una densità di codice maggiore, e dunque fa meno pressione sulla memoria.

Un approccio di questo genere per gli shader processor mi fa pensare che uno dei problemi del design VLIW fosse dovuto alla scarsa densità di codice (che nei VLIW è ancora più accentuata rispetto ai normali RISC), che con GCN hanno eliminato.

P.S. Da quando sono nati i RISC, i CISC sono stati considerati lo zimbello delle architetture degli elaboratori, ma negli ultimi 5 lustri si sono presi delle belle rivincite sia sul piano prestazionale sia su quello del design, perché tanti blasonati RISC hanno dovuto realizzare delle versioni dell'ISA "compatte" sfruttando opcode a lunghezza variabile (in genere 16 e 32 bit), e dunque introducendo sostanzialmente un design CISC. :cool:
FPu singola che non fa chissà quanto da collo di bottiglia.
più che altro sono 8 vs 16 thread
praticamente fare il doppio di un fx8350/2700k significherebbe spannometricamente essere nelle prossimità di un octa core Haswell da 3GHz. Per un 95W sarebbe un buon/ottimo risultato
Sostanzialmente d'accordo, ma vedremo anche a che frequenze arriverà Zen, e se realmente rispetterà questi 95W.
in teoria a parità di thread, la FPu configurata come in ZEN, è più debole, per la mancata presenza di 2 AGU (le prestazioni nei calcoli floating point, dipendono anche dalla parte intera)...
Esattamente, ma dipende anche dal tipo di codice eseguito: ci può essere più o meno carico sull'unità scalare/intera (incluse le AGU) a seconda del modo in cui si accede alla memoria.

Ecco perché ritengo sia inutile continuare a prendere come riferimento l'FPU NEON degli ARM, o un'FPU molto più semplice come quella di un design dedicato: non danno e non posso dare alcuna misura di come si comporterà a livello di consumi l'FPU integrata in Zen.
mi aspetto che le prestazioni scalino peggio anche nei test fp-intensive. Scaling peggiore -> prestazioni ST superiori.
Come mai prevedi uno scaling peggiore?
Alla fine denigrare il CMT è come denigrare il SMT....visto che le tecniche messe in atto sono estremamente simili....il CMT alla fine che cosa è, se non un implementazione parziale del SMT?

Quindi è assolutamente falso che si ritorna a thuban...la FPU è condivisa da 2 thread anche in ZEN....in aggiunta a questo a differenza di thuban/bulldozer non ci saranno alu/agu dedicate....ZEN si allontana ancora di più da thuban, e in un certo senso prosegue il cammino intrapreso con bulldozer.
Diciamo che assomiglia molto a un design Intel. :fagiano:

[bjt2]

Come già detto prima per l'unità NEON, non prenderei in considerazione questi test su FPU così semplici (questa, poi, è enormemente più semplice persino di NEON). Un'FPU x87 è decisamente più complicata (anche perché fa molto di più), e dunque il suo power budget sarà ben diverso.

E' più semplice perchè fa una singola FMAC anzichè 4/8, ma è più calda di una x87 perchè questa non ha la FMAC. Inoltre molte istruzioni x87 sono microcodificate e spalmano il loro payload di consumo su molti cicli... Ad esempio sincos è oltre 200 cicli e blocca l'unità per tutto il tempo, quindi funziona un solo stadio di pipeline in ogni ciclo... Invece con istruzioni il cui throughput è 1 per ciclo, tutti gli stadi di pipeline stanno lavorando su qualcosa e quindi consumano di più...
Quella FMAC ha un throughput di 1 per ciclo di una addizione e una moltiplicazione, che termicamente è il massimo possibile stress...
Su x87 (ma anche SSE/AVX) sono poche le istruzioni che hanno un throughput di 1 per ciclo, quindi spesso c'è solo una piccola porzione di FPU che sta facendo qualcosa...
Moltiplicando per 8 hai il consumo massimo di una FPU a regime che sforna una SIMD a 256 bit di FMAC 32 bit per ciclo, cosa non raggiungibile per limiti di banda RAM a meno di codici che non fanno nulla di utile, facendo calcoli su dati in registro giusto per scaldare il chip...

In genere questi core sono molto semplici, per cui si usa un design RISC, e dunque con istruzioni aventi lunghezza fissa. Hanno lo svantaggio, però, di avere una più bassa densità di codice (e questo influisce su tutta la gerarchia della memoria).

Un design CISC è a lunghezza variabile, per cui richiede un decoder più complicato, ma per contro ha il vantaggio di avere una densità di codice maggiore, e dunque fa meno pressione sulla memoria.

Un approccio di questo genere per gli shader processor mi fa pensare che uno dei problemi del design VLIW fosse dovuto alla scarsa densità di codice (che nei VLIW è ancora più accentuata rispetto ai normali RISC), che con GCN hanno eliminato.

P.S. Da quando sono nati i RISC, i CISC sono stati considerati lo zimbello delle architetture degli elaboratori, ma negli ultimi 5 lustri si sono presi delle belle rivincite sia sul piano prestazionale sia su quello del design, perché tanti blasonati RISC hanno dovuto realizzare delle versioni dell'ISA "compatte" sfruttando opcode a lunghezza variabile (in genere 16 e 32 bit), e dunque introducendo sostanzialmente un design CISC. :cool:

Ricordo ancora la domanda di esame di Calcolatori I: una istruzione frequente è bene codificarla con pochi o molti bit? :cool:

Il RISC vs CISC è un po' come la compressione della memoria sulle GPU (se lossless): si risparmia banda e spazio RAM a scapito di un po' di area chip e complessità... E' un gioco che spesso vale la candela...

[stefanonweb]

Per caso si sa a che voltaggio saranno le memorie DDR4 per BR e ZEN? Grazie. 1,2 volt? E che frequenze potrebbero andare bene?

[Ren]

edit

[Ren]

FPu singola che non fa chissà quanto da collo di bottiglia.
più che altro sono 8 vs 16 thread

Appunto, sono 8(+SMT) core contro 4+CMT.

Per il resto si vedrà...

[cdimauro]

E' più semplice perchè fa una singola FMAC anzichè 4/8, ma è più calda di una x87 perchè questa non ha la FMAC. Inoltre molte istruzioni x87 sono microcodificate e spalmano il loro payload di consumo su molti cicli... Ad esempio sincos è oltre 200 cicli e blocca l'unità per tutto il tempo, quindi funziona un solo stadio di pipeline in ogni ciclo... Invece con istruzioni il cui throughput è 1 per ciclo, tutti gli stadi di pipeline stanno lavorando su qualcosa e quindi consumano di più...
Quella FMAC ha un throughput di 1 per ciclo di una addizione e una moltiplicazione, che termicamente è il massimo possibile stress...
Su x87 (ma anche SSE/AVX) sono poche le istruzioni che hanno un throughput di 1 per ciclo, quindi spesso c'è solo una piccola porzione di FPU che sta facendo qualcosa...
Prima ho sbagliato a scrivere: anziché FPU x87 dovevo mettere FPU x86. :(

Comunque istruzioni dell'FPU che, su Skylake, hanno un throughput di 1 o anche 2 ce ne sono molte. In particolare quelle più comuni (incluse quelle "fused"/FMA) hanno un throughput di 2, com'è ovvio che sia visto che ci sono due porte dedicate.

Quindi, almeno su Skylake, è possibile eseguire 2 istruzioni SIMD di tipo FMA a 256 bit per ciclo di clock. Oltre ovviamente ad un paio di istruzioni intere/scalari, che fanno molto comodo visto che, per l'appunto, non è possibile eseguire soltanto istruzioni dell'FPU in un normale codice.

Zen dovrebbe poter eseguire fino a 4 istruzioni SIMD a 128 bit, oppure 2 istruzioni SIMD a 256 bit per ciclo di clock (o 2/128 bit + 1/246 bit, sulla carta). E niente istruzioni intere in questo caso, visto che il decoder riesce a decodificare al massimo 4 istruzioni per ciclo di clock.
Moltiplicando per 8 hai il consumo massimo di una FPU a regime che sforna una SIMD a 256 bit di FMAC 32 bit per ciclo, cosa non raggiungibile per limiti di banda RAM a meno di codici che non fanno nulla di utile, facendo calcoli su dati in registro giusto per scaldare il chip...
Ma ancora non raggiungeresti quanto possibile con un'FPU x86 con AVX, che riesce a eseguire 8 + 8 (8 per istruzione) operazioni FMAC a 32 bit per ciclo di clock. :)
Ricordo ancora la domanda di esame di Calcolatori I: una istruzione frequente è bene codificarla con pochi o molti bit? :cool:

Il RISC vs CISC è un po' come la compressione della memoria sulle GPU (se lossless): si risparmia banda e spazio RAM a scapito di un po' di area chip e complessità... E' un gioco che spesso vale la candela...
Già, ma dipende molto anche dalla struttura dell'ISA.

Devo dire che sono rimasto estremamente impressionato da quella dell'Hitachi/STM SH4: è l'unico design RISC (che finora m'è capitato di studiare) che ha un'eccezionale densità di codice, pur avendo opcode a dimensione fissa da 16 bit (ma l'ISA è a 32 bit, con 16 registri).

E per design RISC intendo che gli opcode siano rigorosamente a lunghezza fissa, non fake-RISC come il Thumb di ARM o l'AVR32, che in realtà hanno istruzioni da 16 o 32 bit liberamente mischiabili.

Per il resto i CISC (inclusi questi due ultimi che ho citato) dominano nella classifica della densità di codice. :cool:
Appunto, sono 8(+SMT) core contro 4+CMT.
Anche per questo è un confronto che lascia il tempo che trova: uno Zen da 8 core che ha il doppio di prestazioni di un PD da 4 core non ha assolutamente nulla di eccezionale...

[george_p]

Anche per questo è un confronto che lascia il tempo che trova: uno Zen da 8 core che ha il doppio di prestazioni di un PD da 4 core non ha assolutamente nulla di eccezionale...

Si ma occhio che PD ha 8 cores integer, sono le fpu ad essere 4, ossia 1 fpu per due integer.
Amd quando ha introdotto BD intendeva come core quello integer e non l'fpu.
Quindi il confronto lo farebbe con l'FX 8150 o 8350. Mi auguro con il secondo almeno, se no...

[cdimauro]

AMD poteva intendere quello che voleva, ma non erano core veri e propri.

[george_p]

AMD poteva intendere quello che voleva, ma non erano core veri e propri.

Mah, molti dicono che i core veri e propri siano quelli integer, nati quando ancora non esisteva l'fpu come esiste oggi (da svariati anni realmente).
Comunque, sta di fatto che la stessa amd (con il cambio di dirigenza naturalmente) sia tornata indietro sui suoi passi e integrando l'smt al posto del cmt... c'è arrivata con un bel decennio di ritardo ma alla fine ci è arrivata.
E alla fine questo conta.

[Theodorakis]

AMD poteva intendere quello che voleva, ma non erano core veri e propri.

Mah ... http://www.bitsandchips.it/informativa-sull-uso-dei-cookie/9-hardware/6271-class-action-contro-amd-un-modulo-cmt-di-bd-non-e-un-vero-dual-core

[digieffe]

IMHO, core è quello che può cambiare il flusso di esecuzione di un codice, quindi una LU (Logical Unit) che poi la troviamo sempre accorpata con l'unità arimetica.
tutto il resto che se ne possa dire sono coprocessori vari.

Resterebbe la condivione del decoder (non più cosi a partire da XV?) delle caches ecc. ma la possibilità di eseguire nello stesso ciclo di clock due salti condizionati ed avere distinte e non condivise pipeline per fare ciò (2 alu+2 aglu)x2, esclude che si tratti dello stesso core.
inoltre al contrario di SMT il CMT è "più" deterministico nell'esecuzione.

in altre parole i 2 core risc sono ben distinti ed indipendenti ma condividono qualche accessorio

IMHO causa persa...


Edit:
ho appena letto il motivo della causa: "cannot perform eight instructions simultaneously and independently as claimed"

ridicolo...

[cdimauro]

Mi sono già espresso sull'argomento tempo fa. In particolare qui (http://www.hwupgrade.it/forum/showthread.php?p=43067516#post43067516) e nei commenti seguenti.

@digieffe: non conta la possibilità di eseguire due salti nello stesso clock, e nemmeno che ci siano ALU e AGU separate. Altrimenti, da questo punto di vista, anche un thread hardware di Intel lo si potrebbe contare come core.

Riguardo alla causa, bisogna vedere cos'abbia dichiarato AMD. L'unica cosa ridicola è quella di fare un'affermazione che, poi, non corrisponda al vero...

[bjt2]

Prima ho sbagliato a scrivere: anziché FPU x87 dovevo mettere FPU x86. :(

Comunque istruzioni dell'FPU che, su Skylake, hanno un throughput di 1 o anche 2 ce ne sono molte. In particolare quelle più comuni (incluse quelle "fused"/FMA) hanno un throughput di 2, com'è ovvio che sia visto che ci sono due porte dedicate.

Quindi, almeno su Skylake, è possibile eseguire 2 istruzioni SIMD di tipo FMA a 256 bit per ciclo di clock. Oltre ovviamente ad un paio di istruzioni intere/scalari, che fanno molto comodo visto che, per l'appunto, non è possibile eseguire soltanto istruzioni dell'FPU in un normale codice.

Zen dovrebbe poter eseguire fino a 4 istruzioni SIMD a 128 bit, oppure 2 istruzioni SIMD a 256 bit per ciclo di clock (o 2/128 bit + 1/246 bit, sulla carta). E niente istruzioni intere in questo caso, visto che il decoder riesce a decodificare al massimo 4 istruzioni per ciclo di clock.

Ma ancora non raggiungeresti quanto possibile con un'FPU x86 con AVX, che riesce a eseguire 8 + 8 (8 per istruzione) operazioni FMAC a 32 bit per ciclo di clock. :)

Già, ma dipende molto anche dalla struttura dell'ISA.

Devo dire che sono rimasto estremamente impressionato da quella dell'Hitachi/STM SH4: è l'unico design RISC (che finora m'è capitato di studiare) che ha un'eccezionale densità di codice, pur avendo opcode a dimensione fissa da 16 bit (ma l'ISA è a 32 bit, con 16 registri).

E per design RISC intendo che gli opcode siano rigorosamente a lunghezza fissa, non fake-RISC come il Thumb di ARM o l'AVR32, che in realtà hanno istruzioni da 16 o 32 bit liberamente mischiabili.

Per il resto i CISC (inclusi questi due ultimi che ho citato) dominano nella classifica della densità di codice. :cool:

Anche per questo è un confronto che lascia il tempo che trova: uno Zen da 8 core che ha il doppio di prestazioni di un PD da 4 core non ha assolutamente nulla di eccezionale...

La FPU di Zen non dovrebbe essere potente quanto quella di Skylake. E' su questo che stavo facendo i calcoli. Come dici tu dovrebbe avere 4 pipeline in grado di fare 4 operazioni a 128 bit (ad esempio 4 a 32 bit), accoppiabili per farne 2 da 256, con MOP double. Fino a XV 2 erano per l'FP (compreso FMAC) e due facevano l'SSE/AVX/MMX su interi e le altre operazioni, come conversione, accesso a memoria, e non ho notizie sulle x87.

Ci sono rumors che la FPU di Zen sia più potente di quella di BD, ma dalle stime ad occhio dell'area occupata da Zen, non sembra più grande di un modulo XV, quindi non mi aspetto che la FPU sia molto più potente...
Comunque i rumors danno 2 pipeline in grado di fare FMAC o FADD o FMUL e 2 pipeline in grado di fare solo FADD, ma anche il resto delle istruzioni (memoria conversione ecc)... Ancora nessuna notizia sulle x87...

La mia stima ottenuta moltiplicando per 8 il consumo di una FMAC a 32 bit costruita come hanno fatto quei tizi, corrisponde al caso IDEALE di 2 pipeline simmetriche, in grado di fare 2x4x32 FMAC per ciclo, continuamente alimentate dalla L1, che dovrebbe avere 2 porte in lettura a 128 bit e una in scrittura, giusto giusto per uno stream. Quindi la mia stima era per eccesso, poichè la cache può supportare solo una FMAC, ma visto che l'IPC medio di un codice FP è circa 2 (se non mi sbaglio per spec FP è stato calcolato un IPC di 2.4, compreso le istruzioni intere di controllo e di flusso, che è tantissimo, visto che per spec INT si è poco sopra 1), si può supporre che in media sia occupata un'altra pipeline, con dati intermedi, da registro, simulando un calcolo mediamente complesso.

E' chiaro che la FPU di Zen dovrebbe poter fare almeno altre 2 FADD per ciclo, ma la cache non dovrebbe riuscire a sostenere questo carico allo steady state. Neanche si trattasse di due thread, perchè la cache dati dovrebbe essere una sola.

L'unico codice che riuscirebbe a sforare questo limite è un codice che fa parecchie operazioni per ogni dato in memoria e quindi può usare dei registri di appoggio per i dati intermedi. Ad esempio il powerhog che mi viene in mente è un calcolo che fa una FMAC e poi combina questo risultato altre 3 volte con dati fissi oppure di cicli precedenti, conservati in registri. Potrebbe essere un qualche filtro convolutivo molto ottimizzato. A regime si potrebbero avere anche 4 istruzioni per ciclo, se i risultati nei registri sono forwardati in tempo.

Ma la maggior parte dei calcoli utili, non usano solo fmac, fmul o addizioni, ma anche funzioni più complesse come fdiv, sqrt ecc, che non hanno un throughput di 1 per ciclo per pipeline e che quindi riducono l'IPC... In casi reali non si supera il 2.

[george_p]

Mi sono già espresso sull'argomento tempo fa. In particolare qui (http://www.hwupgrade.it/forum/showthread.php?p=43067516#post43067516) e nei commenti seguenti.

@digieffe: non conta la possibilità di eseguire due salti nello stesso clock, e nemmeno che ci siano ALU e AGU separate. Altrimenti, da questo punto di vista, anche un thread hardware di Intel lo si potrebbe contare come core.

Riguardo alla causa, bisogna vedere cos'abbia dichiarato AMD. L'unica cosa ridicola è quella di fare un'affermazione che, poi, non corrisponda al vero...

Non posso entrare troppo nel tecnico per mia ignoranza, anche se mi piace leggere a riguardo.
Difatti ho scritto che per molti il concetto di core è prettamente l'unità integer, io i miei dubbi un pò li ho sempre, anche perché, ripeto, amd stessa è tornata indietro con core a un integer+un fpu scartando praticamente tutto il concetto di cluster, fpu condivisa, cmt ecc., aggiungendo invece anche l'smt, che per "presunzione", come voler distinguersi dalla concorrenza forse, non hanno voluto implementare sin dall'inizio.

[george_p]

Carino il tentativo di bitsandchips di storicizzare la cosa a come fosse un "core" all'inizio, ma davvero inutile, visto che era un processore, non un core.


Il processore prima era costituito da un "core" in cuiera presente la sola unità integer senza la fpu, inizialmente esterna, poi introdotta in seguito come integrazione del "core" nel suo insieme.

[george_p]

Il fatto è che è tutto molto opinabile, non c'è una definizione univoca di "core". Ad oggi i nostri computer sono tutti dei multiprocessore asimmetrici, con "cores" molto diversi fra di loro. Un "CUDA Core" o uno "Stream Processor" hanno una conformazione del tutto diversa da un core x86, per dirne una. Allora non sono core? Quando ti mettono una GPU sul mercato con 4096 core ti stanno truffando perché queste unità sono raggruppate poi a formare cluster di elaborazione più grandi? Non direi proprio, è una definizione che chi produce i chip si autoproduce e non ci vedo niente di trascendentale.

Ribadisco, se la mia mente malata interpreta "hyper" come più di "il doppio" sono titolato a dire che chiamare l'SMT "HyperThreading" è una truffa? Non direi proprio.

Questa class action fa ridere :>

Mah, indubbiamente, solo non penso che la definizione di core nelle schede video sia la stessa di core nei processori x86.
Core è un termine e come tutti i termini viene applicato per intendere un insieme o parti di insiemi fondamentali, niente più.

Sulla class action nulla da dire, pare inutile anche a me.

[digieffe]

Mi sono già espresso sull'argomento tempo fa. In particolare qui (http://www.hwupgrade.it/forum/showthread.php?p=43067516#post43067516) e nei commenti seguenti.

la differenza è che tu consideri il decoder parte del core, io considero core solo il singolo risc.

@digieffe: non conta la possibilità di eseguire due salti nello stesso clock, e nemmeno che ci siano ALU e AGU separate. Altrimenti, da questo punto di vista, anche un thread hardware di Intel lo si potrebbe contare come core.
i thread hardware di intel condividono le pipeline (dell'unico risc) in modo probabilistico. In un unico ciclo di clock se uno stadio della pipeline è occupato da un th hw non può essere disponibile per l'altro th cosa che non accade per il CMT.


Riguardo alla causa, bisogna vedere cos'abbia dichiarato AMD. L'unica cosa ridicola è quella di fare un'affermazione che, poi, non corrisponda al vero...
quale sarebbe l'affermazione che non corrisponderebbe al vero?


Ps: personalmente preferisco SMT.


Edit:
a partire da un successore di BD hanno messo due decoder, da quel momento li consideri due core?

[george_p]

Purtroppo ero già nato e già usavo i computer quando è successo :D

Quel che dicevo è che non c'è bisogno di quella narrazione storica per deridere abbondantemente una class action basata sul nulla come questa :>

Le prime CPU x86 non avevano una FPU, che aveva un socket dedicato sulla scheda madre in cui installarla sotto forma di coprocessore x87. Questa distinzione è continuata fino al 386, di cui esisteva una versione senza FPU (SX) e una con (DX). Ma quel che dico è che si trattava di un processore, non di un core, il concetto di core era ancora ben lontano, quindi non si trattava di un core senza fpu, perché nessuno parlava di core.

Ma, ti dirò, a me quella narrazione storica ha dato informazioni che mi mancavano, non penso ne mi sembra sia fatta per deridere una class action che è fondata sul nulla già di suo, magari per spiegarne un pò l'evoluzione di un processore che oggi come oggi è divenuto un insieme di "processori".

Mi sembra che attorno al concetto core esistano molti punti di vista anche tra ingegneri, vedi amd con BD.

Un core sarà pure principalmente unità integer ma personalmente non inserire la fpu, come è stato fatto in BD è grosso errore, soprattutto perché la fpu non è più elemento esterno come un tempo.

[tuttodigitale]

Mi sono già espresso sull'argomento tempo fa.


ne avevano discusso tempo fa.

Ma, ti dirò, a me quella narrazione storica

ma quale narrazione storica...:D
la FPU era opzionale fino a pochi anni fa, per le architetture di ARM...

Come non detto....in piena epoca multi-core la FPU è opzionale, per l'a5..
http://www.arm.com/files/pdf/AT2_-_Power_Efficient_Processing_with_the_Cortex-A5_v1.pdf vedi pagina 19

[Free Gordon]

Può essere che in AMD quando crearono BD, pensarano principalmente alla sua integrazione con Fusion e quindi "risparmiarono" potenza in virgola mobile, sperando di delegarla alla futura GPU integrata..? :)

Io ho sempre pensato così..

Peccato che le APU/HSA non abbian ancora preso piede adesso...nel 2017 tra un pò..

[george_p]

ne avevano discusso tempo fa.



ma quale narrazione storica...:D
la FPU era opzionale fino a pochi anni fa, per le architetture di ARM...

Come non detto....in piena epoca multi-core la FPU è opzionale, per l'a5..
http://www.arm.com/files/pdf/AT2_-_Power_Efficient_Processing_with_the_Cortex-A5_v1.pdf vedi pagina 19

Boh a me risulta che lo fosse venti anni fa non pochi anni fa. Ma non insisto su argomenti di cui sono poco esperto.

[tuttodigitale]

Boh a me risulta che lo fosse venti anni fa non pochi anni fa. Ma non insisto su argomenti di cui sono poco esperto.

l'a5 non è vecchissimo, essendo costuito sui 40nm, e poteva avere fino a 4 core.

a pagina 19,è chiaro che la NEON e la FPU erano opzioni...

[george_p]

l'a5 non è vecchissimo, essendo costuito sui 40nm, e poteva avere fino a 4 core.

a pagina 19,è chiaro che la NEON e la FPU erano opzioni...

Si però tutto quello che vuoi per quanto siano potenti oggi non considero arm cpu a livello delle storiche intel, amd e ibm.
Poi ripeto, ognuno ha i suoi punti di vista su cosa sia un core, e visto che funziona così per ingegneri che lavorano nel settore, chi sono io per dire cosa è o cosa non è un determinato concetto?

[plainsong]

Può essere che in AMD quando crearono BD, pensarano principalmente alla sua integrazione con Fusion e quindi "risparmiarono" potenza in virgola mobile, sperando di delegarla alla futura GPU integrata..? :)


Questa è una ben nota leggenda metropolitana della cui veridicità dubito fortemente, a meno che in AMD non avessero a suo tempo del tutto cannato le loro previsioni. Siamo ancora molto lontani dalla possibilità di abolire convenientemente l'unità fp, figuriamoci ai tempi della progettazione dell'architettura BD.

[paolo.oliva2]

Io penso che l'interpretazione reale di fatto non esista per considerare un core come entità che racchiude INT + FP, quindi il nocciolo della questione è che un BD X8 è un X8 e non un X4 perché ha 4 FP (condivise}.
Per me il metro plausibile sarebbe quello prestazkonale, perché per assurdo, fantasticando, si potrebbe avere una quantità di core senza FP da una parte e dall'altra soluzioni per elaborare dati in FP. Basta confrontare la capacità prestazionale per avere un metro di misura, anche perché alla fine bisognerebbe vedere anche il costo, perché noi valutiamo la potenza ST e MT, ma ad esempio quella MT non dipende dalla potenza del core ma anche dal numero dei core, se la ditta X offre soluzioni che per stessa potenza offre un numero maggiore di core ma allo stesso prezzo, che importa a me se la ditta Y ha un core più potente?

[stefanonweb]

Scusate si sa almeno se le mobo AM4 avranno un connettore di alimentazione NORMALE a 24 pin... tanto per capire se il pico ali andrà ancora bene o no... Grazie.

[capitan_crasy]

Può essere che in AMD quando crearono BD, pensarano principalmente alla sua integrazione con Fusion e quindi "risparmiarono" potenza in virgola mobile, sperando di delegarla alla futura GPU integrata..? :)

Io ho sempre pensato così..

Peccato che le APU/HSA non abbian ancora preso piede adesso...nel 2017 tra un pò..

Questa è una ben nota leggenda metropolitana della cui veridicità dubito fortemente, a meno che in AMD non avessero a suo tempo del tutto cannato le loro previsioni. Siamo ancora molto lontani dalla possibilità di abolire convenientemente l'unità fp, figuriamoci ai tempi della progettazione dell'architettura BD.

A livello teorico era una considerazione che in molti azzardavano soprattutto quando si parlava del progetto "Fusion 2" che doveva o dovrebbe essere l'ibrido tra una CPU e una GPU.
Con le APU AMD ha mandato avanti questo concetto unificando e ampliando il controller RAM, ma anche se non si parla più direttamente di fusion 2 può darsi che l'ibridazione non sia stata abbandonata, forse deve solo evolversi e prendere nuove strade (L1 e/o L2 condivisa?).
Sono curioso di capire cosa voglia dire quel + nell'architettura ZEN destinata alle future APU...

[stefanonweb]

Questo mi pare scontato, le CPU andranno montate su mobo in standard ATX, no?

Si, certo, magari c'è alimentazione supplementare a 8 pin ecc...

[bjt2]

Può essere che in AMD quando crearono BD, pensarano principalmente alla sua integrazione con Fusion e quindi "risparmiarono" potenza in virgola mobile, sperando di delegarla alla futura GPU integrata..? :)

Io ho sempre pensato così..

Peccato che le APU/HSA non abbian ancora preso piede adesso...nel 2017 tra un pò..

Esisteranno sempre algoritmi non paralellizzabili per cui un solo core da 5 GHz sarà sempre meglio anche di 10000 core a 1GHz... E questo gli ingegneri di AMD lo sanno bene... L'unica cosa sarebbe fare pochi core ad alta frequenza, con molti core a bassa frequenza, con spazio di memoria unificato... Ma questo è proprio una APU con supporto HSA... Quindi già ci siamo...

[tuttodigitale]

Si però tutto quello che vuoi per quanto siano potenti oggi non considero arm cpu a livello delle storiche intel, amd e ibm.
Poi ripeto, ognuno ha i suoi punti di vista su cosa sia un core, e visto che funziona così per ingegneri che lavorano nel settore, chi sono io per dire cosa è o cosa non è un determinato concetto?

più che altro mi pare di capire che per cdimauro, la questione non è avere o no la FPU, ma se le 2 sezioni integer sono totalmente indipendenti
Io direi che ogni core in configurazione CMT è pari al 90%, proprio per la penalità dello scaling. Non sono 2 core puri, ma ci vanno dannatamente vicini, soprattutto da steamroller in poi che ha decoder dedicati.

Detto questo il CMT ha molto poco a che vedere con lo scarso ipc di Bulldozer.

PS molte definizioni, vengono stravolte per esigenze di marketing, vedi le ALU della gpu chiamati core/processor, i nanometraggi del silicio, ecc. Non è la prima e non sarà l'ultima volta.

Mah, indubbiamente, solo non penso che la definizione di core nelle schede video sia la stessa di core nei processori x86.
Core è un termine e come tutti i termini viene applicato per intendere un insieme o parti di insiemi fondamentali, niente più.

Sulla class action nulla da dire, pare inutile anche a me.
per core delle gpu, nvidia si riferisce alle singole ALU...in questo senso è come se un FX8350 fosse una cpu da 48 core:D

EDIT
come non detto mi ero dimenticato che il oltre al SMM c'è il GPC

[george_p]

più che altro mi pare di capire che per cdimauro, la questione non è avere o no la FPU, ma se le 2 sezioni integer sono totalmente indipendenti
Io direi che ogni core in configurazione CMT è pari al 90%, proprio per la penalità dello scaling. Non sono 2 core puri, ma ci vanno dannatamente vicini, soprattutto da steamroller in poi che ha decoder dedicati.

Detto questo il CMT ha molto poco a che vedere con lo scarso ipc di Bulldozer.

PS molte definizioni, vengono stravolte per esigenze di marketing, vedi le ALU della gpu chiamati core/processor, i nanometraggi del silicio, ecc. Non è la prima e non sarà l'ultima volta.


per core delle gpu, nvidia si riferisce alle singole ALU...in questo senso è come se un FX8350 fosse una cpu da 48 core:D

maxwell ha 4 scheduler/cluster da 32 core (ALU).
quindi nella dominazione AMD, i 128 cuda core, sarebbero "solo" 4 core.
Ma questi 4core, per funzionare necessitano di un front-end, e di altre unità "accessorie" tutte condivise...e questo costituirebbe il modulo CMT di AMD.

Appunto, come scritto, alla fine core è un mero termine che non indica granché di specifico in sé, ma in ogni categoria (cpu o gpu) trova una sua maggiore "definizione", e nemmeno al 100% da ciò che ho visto.
A maggior ragione creare class action per questo motivo è da pazzi o furbi.

[tuttodigitale]

Appunto, come scritto, alla fine core è un mero termine che non indica granché di specifico in sé, ma in ogni categoria (cpu o gpu) trova una sua maggiore "definizione", e nemmeno al 100% da ciò che ho visto.
Questo è certo.


A maggior ragione creare class action per questo motivo è da pazzi o furbi.
furbi non saprei...qualcosa dovranno pur sborsare immagino....

[george_p]

Questo è certo.


furbi non saprei...qualcosa dovrammo pur sborsare immagino....

Furbi non è (quasi) mai sinonimo di intelligenza.

[Free Gordon]

Ma questo è proprio una APU con supporto HSA... Quindi già ci siamo...

:)
Forse dovrebbero spingere moolto di più lato software...ora..
Ma ci immaginiamo cosa potrebbe fare AMD con le APU, con un team "tipo" quello di CUDA alle spalle?

[cdimauro]

La FPU di Zen non dovrebbe essere potente quanto quella di Skylake. E' su questo che stavo facendo i calcoli. Come dici tu dovrebbe avere 4 pipeline in grado di fare 4 operazioni a 128 bit (ad esempio 4 a 32 bit), accoppiabili per farne 2 da 256, con MOP double. Fino a XV 2 erano per l'FP (compreso FMAC) e due facevano l'SSE/AVX/MMX su interi e le altre operazioni, come conversione, accesso a memoria, e non ho notizie sulle x87.

Ci sono rumors che la FPU di Zen sia più potente di quella di BD, ma dalle stime ad occhio dell'area occupata da Zen, non sembra più grande di un modulo XV, quindi non mi aspetto che la FPU sia molto più potente...
Comunque i rumors danno 2 pipeline in grado di fare FMAC o FADD o FMUL e 2 pipeline in grado di fare solo FADD, ma anche il resto delle istruzioni (memoria conversione ecc)... Ancora nessuna notizia sulle x87...
Non credo ci siano particolari differenze con le altre istruzioni SSE/AVX: quelle x87 saranno mappate in qualche porta che mette a disposizione servizi simili.
La mia stima ottenuta moltiplicando per 8 il consumo di una FMAC a 32 bit costruita come hanno fatto quei tizi, corrisponde al caso IDEALE di 2 pipeline simmetriche, in grado di fare 2x4x32 FMAC per ciclo, continuamente alimentate dalla L1, che dovrebbe avere 2 porte in lettura a 128 bit e una in scrittura, giusto giusto per uno stream. Quindi la mia stima era per eccesso, poichè la cache può supportare solo una FMAC, ma visto che l'IPC medio di un codice FP è circa 2 (se non mi sbaglio per spec FP è stato calcolato un IPC di 2.4, compreso le istruzioni intere di controllo e di flusso, che è tantissimo, visto che per spec INT si è poco sopra 1), si può supporre che in media sia occupata un'altra pipeline, con dati intermedi, da registro, simulando un calcolo mediamente complesso.
Considera che ci sono anche le MOV (sia fra registri, sia con la memoria), che sono sempre istruzioni conteggiate come floating point, e sono pure molto frequenti (oltre a essere molto veloci), per cui si capisce perché l'IPC possa superare il 2.
E' chiaro che la FPU di Zen dovrebbe poter fare almeno altre 2 FADD per ciclo, ma la cache non dovrebbe riuscire a sostenere questo carico allo steady state. Neanche si trattasse di due thread, perchè la cache dati dovrebbe essere una sola.

L'unico codice che riuscirebbe a sforare questo limite è un codice che fa parecchie operazioni per ogni dato in memoria e quindi può usare dei registri di appoggio per i dati intermedi. Ad esempio il powerhog che mi viene in mente è un calcolo che fa una FMAC e poi combina questo risultato altre 3 volte con dati fissi oppure di cicli precedenti, conservati in registri. Potrebbe essere un qualche filtro convolutivo molto ottimizzato. A regime si potrebbero avere anche 4 istruzioni per ciclo, se i risultati nei registri sono forwardati in tempo.
4 saranno il picco, per quanto hai già detto.
Ma la maggior parte dei calcoli utili, non usano solo fmac, fmul o addizioni, ma anche funzioni più complesse come fdiv, sqrt ecc, che non hanno un throughput di 1 per ciclo per pipeline e che quindi riducono l'IPC... In casi reali non si supera il 2.
Dipende. Ci sono anche le istruzioni reciproco di divisioni e radice quadrata, che sono di gran lunga più veloci di quelle normali, e che un compilatore può benissimo utilizzare al loro posto.

Comunque il ragionamento che hai fatto mi è chiaro, ma riguarda soltanto l'unità FMAC ma, sebbene sia importante, non tiene conto di tutto il "contorno", che consuma anch'esso corrente.

Per questo rimango scettico sul prendere soltanto questo elemento per fare previsioni.
Non posso entrare troppo nel tecnico per mia ignoranza, anche se mi piace leggere a riguardo.
Difatti ho scritto che per molti il concetto di core è prettamente l'unità integer, io i miei dubbi un pò li ho sempre, anche perché, ripeto, amd stessa è tornata indietro con core a un integer+un fpu scartando praticamente tutto il concetto di cluster, fpu condivisa, cmt ecc., aggiungendo invece anche l'smt, che per "presunzione", come voler distinguersi dalla concorrenza forse, non hanno voluto implementare sin dall'inizio.
O magari sarà stato dovuto alla cocciutaggine di qualche ingegnere capo. Capita anche questo.
la differenza è che tu consideri il decoder parte del core, io considero core solo il singolo risc.
[...]
a partire da un successore di BD hanno messo due decoder, da quel momento li consideri due core?
Per quanto mi riguarda, considero core un processore (nell'accezione del termine "elemento che processa") che non ha parti della pipeline condivisa con altri blocchi, fatta eccezione per le cache L2/L3/L4/memory controller/memoria.
i thread hardware di intel condividono le pipeline (dell'unico risc) in modo probabilistico. In un unico ciclo di clock se uno stadio della pipeline è occupato da un th hw non può essere disponibile per l'altro th cosa che non accade per il CMT.
Veramente succede più spesso il contrario, specialmente con codice più orientato al single-threading: le unità del thread hardware CMT sono impegnate e non possono processare altre istruzioni che, se ci fossero a disposizione tutte le porte che mette a disposizione un sistema SMT, sarebbe possibile eseguire.

E non serve nemmeno che il sistema SMT abbia lo stesso numero di porte totali di quello CMT.
quale sarebbe l'affermazione che non corrisponderebbe al vero?
Leggi il link di Bits&Chips.
Ps: personalmente preferisco SMT.
Io preferisco chi riesce a darmi migliori prestazioni in single-thread/core. :fagiano:
ne avevano discusso tempo fa.
In particolare qui (http://www.hwupgrade.it/forum/showthread.php?p=43303424#post43303424). Come mai hai rimosso poi il link? :fiufiu: :D
ma quale narrazione storica...:D
la FPU era opzionale fino a pochi anni fa, per le architetture di ARM...

Come non detto....in piena epoca multi-core la FPU è opzionale, per l'a5..
http://www.arm.com/files/pdf/AT2_-_Power_Efficient_Processing_with_the_Cortex-A5_v1.pdf vedi pagina 19
E lo sarebbe a prescindere dall'architettura. Si potrebbe benissimo sviluppare un processore x86 senza alcuna FPU: solo unità intere.

Comunque non ha più senso parlare di unità intera e unità FPU: da tempo c'è una pipeline che si "forca" sfruttando le varie porte a disposizione.

Di fatto l'unità intera e l'FPU sono state smembrate e/o moltiplicate, e il carico di lavoro viene smistato sulle varie porte specializzate.
Questa è una ben nota leggenda metropolitana della cui veridicità dubito fortemente, a meno che in AMD non avessero a suo tempo del tutto cannato le loro previsioni. Siamo ancora molto lontani dalla possibilità di abolire convenientemente l'unità fp, figuriamoci ai tempi della progettazione dell'architettura BD.
Non credo che l'FPU verrà mai rimossa dal core per smistare sulla GPU tutte le operazioni in virgole mobile. Hanno domini applicativi abbastanza diversi fra loro, anche se molti algoritmi (IN BLOCCO: non singole istruzioni FPU) possono essere smistati sulla GPU, SE ciò risultasse conveniente. Soprattutto se qualche sviluppatore abbia provveduto a scrivere il codice opportunamente.
Esisteranno sempre algoritmi non paralellizzabili per cui un solo core da 5 GHz sarà sempre meglio anche di 10000 core a 1GHz... E questo gli ingegneri di AMD lo sanno bene... L'unica cosa sarebbe fare pochi core ad alta frequenza, con molti core a bassa frequenza, con spazio di memoria unificato... Ma questo è proprio una APU con supporto HSA... Quindi già ci siamo...
In ogni caso non risolveresti il problema in generale.

Pensa a un'applicazione Python che dev'essere eseguita: smisteresti TUTTE le operazioni in virgola mobile a uno o più core della GPU integrata? Anche con la versione più evoluta ed efficiente dell'HSA, prestazionalmente sarebbe un suicidio.

Idem se fossero più istanze di applicazioni Python a girare in parallelo su più core (cosa che succede nei server, generalmente).
più che altro mi pare di capire che per cdimauro, la questione non è avere o no la FPU, ma se le 2 sezioni integer sono totalmente indipendenti
Esattamente. Ho precisato ulteriormente sopra la mia idea.
Detto questo il CMT ha molto poco a che vedere con lo scarso ipc di Bulldozer.
Prova a lanciare un emulatore. In giro trovi benchmark di quelli più usati/blasonati (Dolphin e PCSX2 in particolare): persino il top di gamma basato su PileDriver, che è il successore di Bulldozer, mostra risultati molto scarsi.
:)
Forse dovrebbero spingere moolto di più lato software...ora..
Ma ci immaginiamo cosa potrebbe fare AMD con le APU, con un team "tipo" quello di CUDA alle spalle?
Puoi spingere quanto vuoi: in certi (molti) calcoli l'FPU tradizionale rimane irraggiungibile.

L'unica, come dicevo, è portare interi blocchi di codice da far girare sulla GPU, ma solo se ciò ha senso e mostra realmente dei risultati migliori.

[tuttodigitale]

In particolare qui. Come mai hai rimosso poi il link? :fiufiu: :D

perchè nei post della nostra discussione si parla anche del bench sysmark, e volevo lasciare alle spalle la vicenda in questo thread.


Prova a lanciare un emulatore. In giro trovi benchmark di quelli più usati/blasonati (Dolphin e PCSX2 in particolare): persino il top di gamma basato su PileDriver, che è il successore di Bulldozer, mostra risultati molto scarsi.
ma l'ipc basso non ha molto a che a vedere come il CMT....è come dire che le cpu SMT hanno sempre un ipc elevato....eppure il power6 è noto per avere un ipc molto basso nonostante il SMT4...ma in compenso viaggiava ad oltre 5GHz su un silicio, il 65nm, che ha dato non pochi problemi ad AMD.
è probabilmente vero il contrario: senza CMT bulldozer avrebbe un ipc ancora più basso.


Comunque non ha più senso parlare di unità intera e unità FPU: da tempo c'è una pipeline che si "forca" sfruttando le varie porte a disposizione.
Nell'architettura Intel è senz'altro vero. In quella AMD che presenta uno scheduler e porte dedicate alle pipeline FP, ho qualche riserva.

[cdimauro]

Concordo assolutamente: se n'è parlato abbastanza.

Ma, parimenti, sarebbe da evitare di riprendere la discussione su core vs non-core, per gli stessi motivi.

[tuttodigitale]

Ma, parimenti, sarebbe da evitare di riprendere la discussione su core vs non-core, per gli stessi motivi.
concordo tanto alla fine un termine generico come core, è per l'appunto generico.
Un ultima domanda, per curiosità: pensi che hanno fatto bene a fare causa ad AMD per questa stupidaggine? Alla fine i bench era disponibili, e solo uno sciocco (avrei molti aggettivi più azzeccati) poteva sperare che un prodotto da 150 euro potesse competere con una da 1000. AMD mica è una onlus?

[cdimauro]

Non conosco i termini precisi esposti nella causa, per cui non mi posso pronunciare.

Per me, come già detto, bisogna vedere le dichiarazioni che ha fatto AMD e se combaciano con quanto riportato nelle accuse.

Non c'entra se AMD sia ONLUS o meno, ma soltanto le sue dichiarazioni.

[bjt2]

Non credo ci siano particolari differenze con le altre istruzioni SSE/AVX: quelle x87 saranno mappate in qualche porta che mette a disposizione servizi simili.

Ai fini del consumo le x87 sono ottime, perchè sono scalari... E non hanno le FMAC. Per gli 80 bit dei long double probabilmente ci saranno delle unità separate anche a causa della migliore gestione delle eccezioni e dell'arrotondamento... Se non mi sbaglio i registri non sono neanche 80 bit, ma 112 bit...

Considera che ci sono anche le MOV (sia fra registri, sia con la memoria), che sono sempre istruzioni conteggiate come floating point, e sono pure molto frequenti (oltre a essere molto veloci), per cui si capisce perché l'IPC possa superare il 2.

Non ci avevo pensato... :) Meglio ancora per la mia stima... :) Se il codice più power hungry ha IPC 2.4 e alcune sono intere e alcune FMOV, ecco che la mia è una sovrastima... :) E anche AMD penso faccia così visto che le sue CPU non stanno quasi mai alla frequenza base anche con tutti i core occupati (con il cinebench ad esempio salta tra base e primo step di turbo con una frequenza media un po' superiore alla base...)

4 saranno il picco, per quanto hai già detto.

Dipende. Ci sono anche le istruzioni reciproco di divisioni e radice quadrata, che sono di gran lunga più veloci di quelle normali, e che un compilatore può benissimo utilizzare al loro posto.

Comunque il ragionamento che hai fatto mi è chiaro, ma riguarda soltanto l'unità FMAC ma, sebbene sia importante, non tiene conto di tutto il "contorno", che consuma anch'esso corrente.

Per questo rimango scettico sul prendere soltanto questo elemento per fare previsioni.

Vedi sopra

Comunque non ha più senso parlare di unità intera e unità FPU: da tempo c'è una pipeline che si "forca" sfruttando le varie porte a disposizione.

Di fatto l'unità intera e l'FPU sono state smembrate e/o moltiplicate, e il carico di lavoro viene smistato sulle varie porte specializzate.


Questo su INTEL... Su AMD è dal k7 che la FPU ha uno scheduler, porte e pipeline separato...

Pensa a un'applicazione Python che dev'essere eseguita: smisteresti TUTTE le operazioni in virgola mobile a uno o più core della GPU integrata? Anche con la versione più evoluta ed efficiente dell'HSA, prestazionalmente sarebbe un suicidio.

Idem se fossero più istanze di applicazioni Python a girare in parallelo su più core (cosa che succede nei server, generalmente).

Puoi spingere quanto vuoi: in certi (molti) calcoli l'FPU tradizionale rimane irraggiungibile.

L'unica, come dicevo, è portare interi blocchi di codice da far girare sulla GPU, ma solo se ciò ha senso e mostra realmente dei risultati migliori.

Ti sei risposto da solo... :) Avendo sia CPU normali che "core" GPU, il codice poco parallelizzabile sarà scritto e compilato per girare sulla CPU e il codice paralellizzabile sulla GPU. Su CUDA è banale perchè per far eseguire il codice sulla GPU si deve farlo esplicitamente, mentre OpenCL per quanto ne so tratta CPU e GPU come un pool, anche se mi pare che si può specificare se un kernel può usare solo core GPU e/o CPU...

[cdimauro]

Ho visto che hai editato il precedente commento, per cui rispondo alle parti che hai aggiunto.
ma l'ipc basso non ha molto a che a vedere come il CMT....è come dire che le cpu SMT hanno sempre un ipc elevato....eppure il power6 è noto per avere un ipc molto basso nonostante il SMT4...ma in compenso viaggiava ad oltre 5GHz su un silicio, il 65nm, che ha dato non pochi problemi ad AMD.
è probabilmente vero il contrario: senza CMT bulldozer avrebbe un ipc ancora più basso.
O più alto? Perché il problema del CMT è che, come già detto, mette un tappo/tetto alle prestazioni eseguibili, a causa del numero di porte intere a disposizione.

Anche se il codice che gira nel tuo thread hardware potrebbe eseguire più istruzioni intere, alle fine si trova bloccato aspettando le due ALU e/o le due load/store si liberino...

Per il POWER6 il discorso è completamente diverso, visto che è orientato al puro multithreading / throughput.
Nell'architettura Intel è senz'altro vero. In quella AMD che presenta uno scheduler e porte dedicate alle pipeline FP, ho qualche riserva.
Perché?

[bjt2]

Perché?

AMD dal k7 è tornato al design a coprocessore, sfruttato al limite in BD con il CMT... Pipeline, scheduler e porte separate... Solo il ritiro è condiviso, ma mi pare che nell'architettura a coprocessore la CPU era il master e teneva tutti i flags e aspettava il coprocessore esterno che restituiva dati e/o eccezioni/stato, "ritirando" l'istruzione e sollevando eventuali eccezioni...

[tuttodigitale]

O più alto? Perché il problema del CMT è che, come già detto, mette un tappo/tetto alle prestazioni eseguibili, a causa del numero di porte intere a disposizione.
ma non è il CMT a mettere il tappo. Come ho detto tempo fa, non basta una terza ALU, per avere magicamente un ipc alto. Ma è l'architettura, TUTTA, equilibrata per quelle 2 ALU. Ricordo che un modulo CMT, è grande quanto un core Sandy Bridge, che a sua volta è grande quanto 2 core k10, quindi l'architettura Intel è oggettivamente molto complessa.

Ma nessuno vieta ad AMD di fare un CMT ad alto ipc..ma poi si sarebbe trovata di fatto, con un'architettura inefficiente, quale teoricamente sono quelle ad alte ipc con un solo thread attivo.

[tuttodigitale]

Anche se il codice che gira nel tuo thread hardware potrebbe eseguire più istruzioni intere, alle fine si trova bloccato aspettando le due ALU e/o le due load/store si liberino...
esattamente, se lo scheduler è stato progettato in modo da non permettere di estrarre un livello di parallelismo molto alto, è inutile avere la terza ALU, tanto più se non hai un altro thread da servire. Consumeresti solo energia...margine termico che potresti sfruttare per salire un poco di clock.

[cdimauro]

Ai fini del consumo le x87 sono ottime, perchè sono scalari... E non hanno le FMAC. Per gli 80 bit dei long double probabilmente ci saranno delle unità separate anche a causa della migliore gestione delle eccezioni e dell'arrotondamento...
No, sono mappate nelle stesse porte che si occupano di gestire le operazioni floating point. Ad esempio su Bulldozer le FADD, FSUB, FMUL, ecc. sono mappate indifferentemente sulle porte P0 o P1.
Se non mi sbaglio i registri non sono neanche 80 bit, ma 112 bit...
Questo dipende dall'implementazione interna. In teoria basterebbero 80 bit (16 di esponente e 64 di mantissa), ma ci sono anche dei bit aggiuntivi per ogni registro, e immagino che all'inizio della mantissa venga aggiunto il 65° bit (sempre a 1) per comodità.
Non ci avevo pensato... :) Meglio ancora per la mia stima... :) Se il codice più power hungry ha IPC 2.4 e alcune sono intere e alcune FMOV, ecco che la mia è una sovrastima... :)
Ma ricorda che l'FPU non è semplice come quella di quel circuito. Come vedi sopra, una porta deve gestire tante cose, incluse le vecchie istruzioni x87.
E anche AMD penso faccia così visto che le sue CPU non stanno quasi mai alla frequenza base anche con tutti i core occupati (con il cinebench ad esempio salta tra base e primo step di turbo con una frequenza media un po' superiore alla base...)
Beh, mi pare normale, visto che Cinebench stressa particolarmente l'FPU.
Questo su INTEL... Su AMD è dal k7 che la FPU ha uno scheduler, porte e pipeline separato...
Su questo ne hai parlato meglio dopo.
Ti sei risposto da solo... :) Avendo sia CPU normali che "core" GPU, il codice poco parallelizzabile sarà scritto e compilato per girare sulla CPU e il codice paralellizzabile sulla GPU.
Non è affatto detto. Anche se un problema è fortemente parallelizzabile, se il costo del trasferimento dell'esecuzione alla GPU è troppo elevato, diventa non conveniente.

Esempio: metti che devi ordinare un vettore. Se non ci sono molti elementi, la CPU può farlo molto prima del roundtrip CPU->GPU->CPU, e usare immediatamente i dati elaborati.
Su CUDA è banale perchè per far eseguire il codice sulla GPU si deve farlo esplicitamente,
Con Cilk+ o le pragma dedicate è di gran lunga più semplice fare eseguire codice a Xeon Phi o alla GPU integrata. :fiufiu: :D
mentre OpenCL per quanto ne so tratta CPU e GPU come un pool, anche se mi pare che si può specificare se un kernel può usare solo core GPU e/o CPU...
Sì, esatto.
AMD dal k7 è tornato al design a coprocessore, sfruttato al limite in BD con il CMT... Pipeline, scheduler e porte separate... Solo il ritiro è condiviso, ma mi pare che nell'architettura a coprocessore la CPU era il master e teneva tutti i flags e aspettava il coprocessore esterno che restituiva dati e/o eccezioni/stato, "ritirando" l'istruzione e sollevando eventuali eccezioni...
Anche con quest'implementazione, AMD non è affatto tornata al design a coprocessore (che comunque ha registri suoi, anche per i suoi flag. Ci sono, però, istruzioni apposite per copiare i flag dell'FPU nel registro AX della CPU, caricabili successivamente nel registro dei flag della CPU per eseguire poi saldi condizionali. Comunque si tratta di operazioni che rallentano l'esecuzione, ovviamente, anche se a partire da un processore c'è stata una semplificazione che fa risparmiare qualcosa).

Col coprocessore la CPU doveva inviare l'opcode all'FPU, ed eventualmente presentare sul bus pure l'indirizzo di memoria dal quale leggere o scrivere il dato referenziato.

L'FPU continuava quindi a lavorare, e lo stesso poteva fare la CPU. Quest'ultima doveva poi sincronizzarsi con un'istruzione FWAIT prima di inviare una nuova istruzione all'FPU (l'FWAIT, comunque, non è sempre necessaria: dipende dall'istruzione).

La CPU si occupava anche delle eccezioni che venivano eventualmente segnalate dall'FPU, e quest'ultima ha un apposito registro per memorizzare l'istruzione fallace.

Non mi pare che il modello sia lo stesso di quello adottato da AMD per il K7 e i più nuovi processori.

Inoltre pipeline e porte dedicate mi sembra le abbiano pure i processori Intel, per cui la differenza sarebbe rappresentata dal solo scheduler dedicato.
ma non è il CMT a mettere il tappo. Come ho detto tempo fa, non basta una terza ALU, per avere magicamente un ipc alto. Ma è l'architettura, TUTTA, equilibrata per quelle 2 ALU. Ricordo che un modulo CMT, è grande quanto un core Sandy Bridge, che a sua volta è grande quanto 2 core k10, quindi l'architettura Intel è oggettivamente molto complessa.
Ma lo è anche quella di AMD col CMT. "Semplicemente" le risorse (transistor) sono state distribuite in maniera diversa.
Ma nessuno vieta ad AMD di fare un CMT ad alto ipc..ma poi si sarebbe trovata di fatto, con un'architettura inefficiente, quale teoricamente sono quelle ad alte ipc con un solo thread attivo.
Avrebbe dovuto sprecare molte più risorse, quando un modello SMT consente di gestire mediamente meglio, e in maniera più semplice, tutti gli scenari: quello ST e quello MT.
esattamente, se lo scheduler è stato progettato in modo da non permettere di estrarre un livello di parallelismo molto alto, è inutile avere la terza ALU, tanto più se non hai un altro thread da servire. Consumeresti solo energia...margine termico che potresti sfruttare per salire un poco di clock.
Se lo scheduler ha due sole porte a disposizione per macroALU/thread hardware, non è che possa fare miracoli: è quello che lo limita, anche se lo scheduler potrebbe smistare più istruzioni.

[bjt2]

No, sono mappate nelle stesse porte che si occupano di gestire le operazioni floating point. Ad esempio su Bulldozer le FADD, FSUB, FMUL, ecc. sono mappate indifferentemente sulle porte P0 o P1.

Si, lo so che sono mappate sulle stesse porte, ma c'è un Mux ed è usata una pipeline separata... E' di pochi anni il brevetto AMD per fare con una sola unità FADD, FMUL e FMAC con una sola unità e dei bypass... Ho il terrore che prima fosse tutto duplicato!

Questo dipende dall'implementazione interna. In teoria basterebbero 80 bit (16 di esponente e 64 di mantissa), ma ci sono anche dei bit aggiuntivi per ogni registro, e immagino che all'inizio della mantissa venga aggiunto il 65° bit (sempre a 1) per comodità.

Ma ricorda che l'FPU non è semplice come quella di quel circuito. Come vedi sopra, una porta deve gestire tante cose, incluse le vecchie istruzioni x87.

Certo. :) Ma non funziona tutto contemporaneamente. E sul 14nm LPP il leakage è bassissimo (1/6 del 28nm HPP) e quindi transistors in idle consumano pochissimo... E un modulo XV sul 28mn HPP è stato postato qui che consuma 4.5W a 2.7GHz... Quindi un core Zen a 3GHz probabilmente consumerà 4-5W in media...

Beh, mi pare normale, visto che Cinebench stressa particolarmente l'FPU.

Ma non è un powerhog. In ogni istante ci sono almeno 1 pipeline FPU e una intera che si girano i pollici e quindi non consumano corrente. Da cui la possibilità di andare in turbo...

Non è affatto detto. Anche se un problema è fortemente parallelizzabile, se il costo del trasferimento dell'esecuzione alla GPU è troppo elevato, diventa non conveniente.

Esempio: metti che devi ordinare un vettore. Se non ci sono molti elementi, la CPU può farlo molto prima del roundtrip CPU->GPU->CPU, e usare immediatamente i dati elaborati.

Con HSA non c'è nessun trip da fare... la GPU ha persino accesso alle tabelle di paginazione. Il buffer è in RAM e la GPU se lo va a prendere... L'hanno persino implementato nelle GPU discrete più recenti (anche se li i dati transitano per il bus pciex e non c'è un accesso diretto)... AMD ha fatto un gran lavoro da questo punto di vista: spazio di memoria unificato e scambio di puntatori... Resta comunque il problema che i "core" GPU sono molto più lenti e quindi se i problema non è molto parallelizzabile si usa la CPU... Persino Matlab, da qualche anno, ha una euristica per decidere se una operazione matriciale la deve fare su una CPU o su tutti i core... Ad esempio una addizione di due matrici, che è limitata dalla banda RAM, non viene splittata... Ma una EXP si...

Con Cilk+ o le pragma dedicate è di gran lunga più semplice fare eseguire codice a Xeon Phi o alla GPU integrata. :fiufiu: :D

Anche CUDA non è male... :D

Anche con quest'implementazione, AMD non è affatto tornata al design a coprocessore (che comunque ha registri suoi, anche per i suoi flag. Ci sono, però, istruzioni apposite per copiare i flag dell'FPU nel registro AX della CPU, caricabili successivamente nel registro dei flag della CPU per eseguire poi saldi condizionali. Comunque si tratta di operazioni che rallentano l'esecuzione, ovviamente, anche se a partire da un processore c'è stata una semplificazione che fa risparmiare qualcosa).

Col coprocessore la CPU doveva inviare l'opcode all'FPU, ed eventualmente presentare sul bus pure l'indirizzo di memoria dal quale leggere o scrivere il dato referenziato.

L'FPU continuava quindi a lavorare, e lo stesso poteva fare la CPU. Quest'ultima doveva poi sincronizzarsi con un'istruzione FWAIT prima di inviare una nuova istruzione all'FPU (l'FWAIT, comunque, non è sempre necessaria: dipende dall'istruzione).

La CPU si occupava anche delle eccezioni che venivano eventualmente segnalate dall'FPU, e quest'ultima ha un apposito registro per memorizzare l'istruzione fallace.

Non mi pare che il modello sia lo stesso di quello adottato da AMD per il K7 e i più nuovi processori.

Dimenticavo FWAIT! :doh: Daltronde all'ITIS facevo solo il codice x86 intero... :fiufiu:

Inoltre pipeline e porte dedicate mi sembra le abbiano pure i processori Intel, per cui la differenza sarebbe rappresentata dal solo scheduler dedicato.

INTEL ha 4 porte dedicate alle istruzioni elaborative ma su ognuna (o quasi) sono allocate sia istruzioni INT che FPU... Se leggi nel thread si è sempre detto che INTEL può fare 4 istruzioni tra int e FP (4+0, 1+3, 2+2, ecc, ed è da vedere gli incastri con le porte, ad esempio una certa istruzione può essere instradata solo in una porta e quindi obbligare altre istruzioni che usano quella porta, anche quelle che fanno cose diverse e quindi non usano la stessa pipeline, ad aspettare), mentre AMD con i suoi scheduler separati, 4+4 (oltre alle AGU, simili per entrambi) è più libera di smistare le istruzioni e estrarre parallelismo... E' per questo che sospetto che l'SMT su CPU AMD faccia guadagnare più di intel: ci sono più porte. Se ho un thread con calcoli interi e uno con calcoli FP, teoricamente potrei perdere pochissimo...

[tuttodigitale]

Ma lo è anche quella di AMD col CMT. "Semplicemente" le risorse (transistor) sono state distribuite in maniera diversa.
esattamente...con lo stesso numero di transistor AMD ha ottenuto 2 core (4ALU + 4 AGU)...e teoricamente (ma anche in pratica :D ), avere a parità di numero di stadi la possibilità frequenze più alte.

quando parlo di complessità, mi riferisco al livello di ipc che si sono prefissati in casa di AMD...perchè poi è notevolmente complesso trovare le migliori soluzioni per fare lo stesso lavoro (ne più nè meno) con il minor numero di risorse.


Se lo scheduler ha due sole porte a disposizione per macroALU/thread hardware, non è che possa fare miracoli: è quello che lo limita, anche se lo scheduler potrebbe smistare più istruzioni.
se viene limitato, da buon progettista limiti anche lo scheduler. E questo vale per tutti gli altri componenti della CPU.

[cdimauro]

Si, lo so che sono mappate sulle stesse porte, ma c'è un Mux ed è usata una pipeline separata... E' di pochi anni il brevetto AMD per fare con una sola unità FADD, FMUL e FMAC con una sola unità e dei bypass... Ho il terrore che prima fosse tutto duplicato!

Certo. :) Ma non funziona tutto contemporaneamente.
Devi vedere le cose da un'altra prospettiva. Quella FPU con quell'FMAC è semplicissima e consuma pochissimo quando, invece, per eseguire quest'operazione e avere esattamente lo stesso throughput su un processore x86 devi scomodare un bel po' di logica in più: selezionare la porta, quale parte di quella porta, quale fra le tantissime istruzioni eseguire, prelevare i registri o una parte di essi, eseguire finalmente l'operazione vera e propria, e infine salvare il risultato sul registro o una parte di esso...
E sul 14nm LPP il leakage è bassissimo (1/6 del 28nm HPP) e quindi transistors in idle consumano pochissimo... E un modulo XV sul 28mn HPP è stato postato qui che consuma 4.5W a 2.7GHz... Quindi un core Zen a 3GHz probabilmente consumerà 4-5W in media...
Vedremo, perché su come scali il processo LPP mi pare ci siano non pochi dubbi, come s'è discusso prima.
Ma non è un powerhog. In ogni istante ci sono almeno 1 pipeline FPU e una intera che si girano i pollici e quindi non consumano corrente. Da cui la possibilità di andare in turbo...
Perché, anche volendo, non si possono tenere impegnate tutte le porte. :p
Con HSA non c'è nessun trip da fare... la GPU ha persino accesso alle tabelle di paginazione. Il buffer è in RAM e la GPU se lo va a prendere... L'hanno persino implementato nelle GPU discrete più recenti (anche se li i dati transitano per il bus pciex e non c'è un accesso diretto)... AMD ha fatto un gran lavoro da questo punto di vista: spazio di memoria unificato e scambio di puntatori... Resta comunque il problema che i "core" GPU sono molto più lenti e quindi se i problema non è molto parallelizzabile si usa la CPU... Persino Matlab, da qualche anno, ha una euristica per decidere se una operazione matriciale la deve fare su una CPU o su tutti i core... Ad esempio una addizione di due matrici, che è limitata dalla banda RAM, non viene splittata... Ma una EXP si...
Non sono stato chiaro. Il roundtrip riguarda il fatto che la CPU deve contattare la GPU per smistarle il lavoro da fare, aspettare che questa finisca l'elaborazione, e finalmente poter accedere ai dati.
Anche CUDA non è male... :D
Così facile? (https://software.intel.com/en-us/articles/getting-started-with-compute-offload-to-intelr-graphics-technology)

Così (https://software.intel.com/en-us/articles/how-to-offload-computation-to-intelr-graphics-technology), per esempio. ;)
Dimenticavo FWAIT! :doh: Daltronde all'ITIS facevo solo il codice x86 intero... :fiufiu:
Idem. Ma un po' di anno dopo le FPU si sono diffuse. :D
INTEL ha 4 porte dedicate alle istruzioni elaborative ma su ognuna (o quasi) sono allocate sia istruzioni INT che FPU... Se leggi nel thread si è sempre detto che INTEL può fare 4 istruzioni tra int e FP (4+0, 1+3, 2+2, ecc, ed è da vedere gli incastri con le porte, ad esempio una certa istruzione può essere instradata solo in una porta e quindi obbligare altre istruzioni che usano quella porta, anche quelle che fanno cose diverse e quindi non usano la stessa pipeline, ad aspettare), mentre AMD con i suoi scheduler separati, 4+4 (oltre alle AGU, simili per entrambi) è più libera di smistare le istruzioni e estrarre parallelismo...
A me pare l'esatto contrario, in particolare con codice single threaded.

Intel non ha tutte le ALU mappate su porte che possono eseguire operazioni dell'FPU: ne ha una completamente libera, e un'altra con un piccolo vincolo (solo operazioni vettoriali sugli interi, che però con codice vettoriale possono benissimo essere smistate sulle prime due porte, tenendo libera questa), come si può vedere dallo schema di Haswell (http://www.anandtech.com/show/6355/intels-haswell-architecture/8).

Ecco gli schemi di Bulldozer (http://www.anandtech.com/show/2872), PileDriver (http://www.anandtech.com/show/5831/amd-trinity-review-a10-4600m-a-new-hope), Steamroller (http://www.anandtech.com/show/6201/amd-details-its-3rd-gen-steamroller-architecture), ed Excavator (http://wccftech.com/amd-carrizo-apu-architecture-hot-chips/) (quasi, in questo caso: ci sono solo le differenze da Steamroller, che però non incidono sul discorso delle porte).

Anche l'ultima soluzione di AMD su applicazioni single-threaded rimane limitata dal fatto di poter eseguire fino a 4 operazioni, ma vincolate nella scelta fra 2 AGLU + 2 Load/Store + 3 FPU (da 128-bit massimo ciascuna).

Su multithread le cose vanno molto meglio, perché hai la possibilità di eseguire più istruzioni (ma solo a partire da Steamroller), perché ne vengono decodificate 4 + 4 = 8, però comunque con 3 sole porte per le FPU (di cui solo 2 per operazioni a 128 bit) rimani limitato nelle scelte.

In buona sostanza, l'approccio CMT di AMD, suddividendo rigidamente certe porte/unità di calcolo, pone troppi vincoli.
E' per questo che sospetto che l'SMT su CPU AMD faccia guadagnare più di intel: ci sono più porte. Se ho un thread con calcoli interi e uno con calcoli FP, teoricamente potrei perdere pochissimo...
Più porte non significa che le potrai impegnare tutte, perché il limite rimane rappresentato dal numero di istruzioni decodificabili e/o "issuable" (non mi viene il termine italiano :(), che è pari a 4 per ciclo di clock.

Un design con meno porte, ma ben calibrate, può benissimo fare lo stesso lavoro. ;)
esattamente...con lo stesso numero di transistor AMD ha ottenuto 2 core (4ALU + 4 AGU)...e teoricamente (ma anche in pratica :D ), avere a parità di numero di stadi la possibilità frequenze più alte.
Ma con consumi più alti. ;)
quando parlo di complessità, mi riferisco al livello di ipc che si sono prefissati in casa di AMD...perchè poi è notevolmente complesso trovare le migliori soluzioni per fare lo stesso lavoro (ne più nè meno) con il minor numero di risorse.
Si vede che hanno preferito puntare tutto sul multithread, a prezzo di un IPC inferiore. Vedi anche sopra i discorsi con bjt2.

Però, come già detto, un'approccio del genere potrebbe andare bene in ambito server (e dipende sempre dagli obiettivi: Facebook & co. preferiscono soluzioni con un IPC elevato / ottime prestazioni su single-thread), ma non in quello desktop e mobile.
se viene limitato, da buon progettista limiti anche lo scheduler. E questo vale per tutti gli altri componenti della CPU.
Chiaro, ma il punto è un altro: se il codice (binario) consente di poter eseguire più istruzioni, non riesci però a farlo con scheduler e unità vincolate come quelle di cui discusse prima, perdendo prestazioni.

IMO hanno commesso grossi errori di valutazione col modello CMT.

[george_p]

IMO hanno commesso grossi errori di valutazione col modello CMT.

Ciò che scrivo da tempo anche io e in ogni caso evidentissimo sia dai risultati visti su strada sia dalla scelta di amd di tornare ad un approccio diverso, e quest'ultimo fatto dal 2012 praticamente a ridosso il debutto di BD.

[bjt2]

Devi vedere le cose da un'altra prospettiva. Quella FPU con quell'FMAC è semplicissima e consuma pochissimo quando, invece, per eseguire quest'operazione e avere esattamente lo stesso throughput su un processore x86 devi scomodare un bel po' di logica in più: selezionare la porta, quale parte di quella porta, quale fra le tantissime istruzioni eseguire, prelevare i registri o una parte di essi, eseguire finalmente l'operazione vera e propria, e infine salvare il risultato sul registro o una parte di esso...

Non mi è chiaro se quel consumo include anche il resto del circuito, ma se vedi le altre pagine, hanno costruito un test chip con le 4 FPU, per compararle e c'è uno schema dei circuiti di contorno che servono per farli funzionare...

Vedremo, perché su come scali il processo LPP mi pare ci siano non pochi dubbi, come s'è discusso prima.

Con due nodi più i finfet vs bulk tu pensi che non si riescano a guadagnare nemmeno 300MHz? Tenendo conto che non è detto che un core zen abbia un numero di transitors pari a un MODULO XV...

Perché, anche volendo, non si possono tenere impegnate tutte le porte. :p

Non ne sarei sicuro... Un powerhog virus io credo che possa essere scritto, almeno per XV che ha 8 decoder

Non sono stato chiaro. Il roundtrip riguarda il fatto che la CPU deve contattare la GPU per smistarle il lavoro da fare, aspettare che questa finisca l'elaborazione, e finalmente poter accedere ai dati.

Secondo le specifiche HSA i processi su CPU e GPU possono essere indipendenti e comunicare con le normali routine IPC. Inoltre i processi GPU hanno pari dignità di quelli CPU e possono creare altri processi CPU o GPU.

Così facile? (https://software.intel.com/en-us/articles/getting-started-with-compute-offload-to-intelr-graphics-technology)

Così (https://software.intel.com/en-us/articles/how-to-offload-computation-to-intelr-graphics-technology), per esempio. ;)

CUDA non funzioa a livello di blocchi logici, devi creare delle funzioni con un dato prefisso e devi scrivere istruzioni esplicite per spararle sulla GPU (e occuparti del trasferimento dati da e verso GPU) e usare il preprocessore nvidia che poi richiama uno dei compilatori supportati. Obbiettivamente così è più semplice. Ma immagino che per HSA si possa fare una cosa simile. Non ho idea di come sia il software... Non ho processori o GPU AMD e non ho mai approfondito.

Idem. Ma un po' di anno dopo le FPU si sono diffuse. :D

A me pare l'esatto contrario, in particolare con codice single threaded.

Intel non ha tutte le ALU mappate su porte che possono eseguire operazioni dell'FPU: ne ha una completamente libera, e un'altra con un piccolo vincolo (solo operazioni vettoriali sugli interi, che però con codice vettoriale possono benissimo essere smistate sulle prime due porte, tenendo libera questa), come si può vedere dallo schema di Haswell (http://www.anandtech.com/show/6355/intels-haswell-architecture/8).

Ecco gli schemi di Bulldozer (http://www.anandtech.com/show/2872), PileDriver (http://www.anandtech.com/show/5831/amd-trinity-review-a10-4600m-a-new-hope), Steamroller (http://www.anandtech.com/show/6201/amd-details-its-3rd-gen-steamroller-architecture), ed Excavator (http://wccftech.com/amd-carrizo-apu-architecture-hot-chips/) (quasi, in questo caso: ci sono solo le differenze da Steamroller, che però non incidono sul discorso delle porte).

Anche l'ultima soluzione di AMD su applicazioni single-threaded rimane limitata dal fatto di poter eseguire fino a 4 operazioni, ma vincolate nella scelta fra 2 AGLU + 2 Load/Store + 3 FPU (da 128-bit massimo ciascuna).

Su multithread le cose vanno molto meglio, perché hai la possibilità di eseguire più istruzioni (ma solo a partire da Steamroller), perché ne vengono decodificate 4 + 4 = 8, però comunque con 3 sole porte per le FPU (di cui solo 2 per operazioni a 128 bit) rimani limitato nelle scelte.

In buona sostanza, l'approccio CMT di AMD, suddividendo rigidamente certe porte/unità di calcolo, pone troppi vincoli.

Più porte non significa che le potrai impegnare tutte, perché il limite rimane rappresentato dal numero di istruzioni decodificabili e/o "issuable" (non mi viene il termine italiano :(), che è pari a 4 per ciclo di clock.

Un design con meno porte, ma ben calibrate, può benissimo fare lo stesso lavoro. ;)

Io mi riferivo a Zen, so benissimo che BD ha dei limiti. Zen dovrebbe avere 4 ALU, 2 AGU e 4 pipeline FPU. Le affermazioni sull'essere 6 wide mi fanno sperare che abbia 6 decoder, o forse, avendo probabilmente una cache L0 per le uops, può leggerne 6 alla volta e mettere in coda per l'esecuzione. Oppure il 6 wide si riferisce alle 4 ALU e 2 AGU... Si vedrà ad Hotchips ad Agosto... Comunque il vantaggio dei due scheduler INT e FP separati (e sembra anche per le operazioni L/S, perchè ho letto da qualche parte di scheduler multipli) è che, posto il limite di decodifica e/o issue dalla L0, si può far svuotare la coda anche con 10 uops ciclo... Un muxer oltre le 4 mops richiede un bit in più e quindi è più lento, ma se si divido i domini e faccio più mux fino a 4 porte risolvo il problema... L'idea di INTEL di coda unificata è ottima dal punto di vista della teoria delle code, ma si scontra con il fatto che oltre le 4 porte aumenti del 33% il ritardo (3 bit vs 2 bit) del muxer e quindi riduci il clock massimo. Quindi meglio più scheduler da 4 porte che un mega scheduler da 8 o 10 porte... Inoltre le porte multifunzione non mi piacciono...

EDIT: poi vedo quindi peggio ancora dallo schema di Haswell... Può fare 4 istruzioni INT e due delle 4 porte int possono fare le FPU, quindi 4+0, 3+1 o 2+2... Non può fare più di 2 istruzioni FP per ciclo?!?!? E se fai delle istruzioni SIMD intere o un branch o la divisione ti freghi la possibilità di 1 o 2 istruzioni FP?!?!?! E' una strage! Ecco perchè l'SMT non guadagna tanto...

Se Zen riuscirà a fare veramente 4 istruzioni FP + 4 int, per l'SMT sarebbe una manna! Altro che +25%... Ritratto il mio +30% e ritorno al mio +50/60% di un paio di mesi fa! Se INTEL con quelle limitazioni fa +25% Zen dovrebbe volare!

[S3lfman]

seguo!

[tuttodigitale]

Ma con consumi più alti. ;)
NI. Questo è vero se si opera con lo stesso Vcore, ovvero se si ottiene frequenze superiori pari alla riduzione della complessità dello stadio...ma è possibile anche avere frequenza superiore e vcore inferiori. Non è automatico dire chi consuma di più...
se la questione fosse così semplice, non ti pare che AMD avrebbe puntato fin da subito ad una soluzione SMT2, che da diversi anni è custodita nei loro cassetti? (dai tempi di k8)


Avevo nei post dietro, riportato i vantaggi di vcore offerti dai 32nm Bulk di Intel rispetto ai 28nm di GF. Quindi ancora oggi non sappiamo quanto sia davvero merito dell'architettura e quanto del silicio (non che la cosa sia piovuta dall'alto, visti gli enormi investimenti di Intel)...
Kaveri/Carrizo, girano con vcore pazzeschi (dovuto anche all'uso di transistor a più alta tensione di soglia)


Si vede che hanno preferito puntare tutto sul multithread, a prezzo di un IPC inferiore. Vedi anche sopra i discorsi con bjt2.

Però, come già detto, un'approccio del genere potrebbe andare bene in ambito server (e dipende sempre dagli obiettivi: Facebook & co. preferiscono soluzioni con un IPC elevato / ottime prestazioni su single-thread), ma non in quello desktop e mobile.
Nel MT, in verità k10, era ancora una signor architettura, considerando le ridotte dimensioni, l'ipc e le frequenze non proprio risibili che era in grado di raggiungere.

Bulldozer e derivati migliorano, a livello di architettura, proprio le prestazioni ST: non si può non considerare l'altissima frequenza di clock che un architettura del genere teoricamente è in grado di raggiungere anche a scapito dell'efficienza.

Poi sui problemi del silicio, se non bastasse llano, c'è la testimonianza del cambio di roadmap...dal 10 core Piledriver siamo passati ad 8 core.:rolleyes:m per non parlare del fatto che solo il modello di punta BD doveva avere un TDP di 125W e il 10-15% di prestazioni in più del power7+ sul predecessore (e la stessa IBM riporta che il contributo del silicio per tali miglioramenti è del 6%, il 94% alle tecnologie implementate..)

[paolo.oliva2]

NI. Questo è vero se si opera con lo stesso Vcore, ovvero se si ottiene frequenze superiori pari alla riduzione della complessità dello stadio...ma è possibile anche avere frequenza superiore e vcore inferiori. Non è automatico dire chi consuma di più...
se la questione fosse così semplice, non ti pare che AMD avrebbe puntato fin da subito ad una soluzione SMT2, che da diversi anni è custodita nei loro cassetti? (dai tempi di k8)


Avevo nei post dietro, riportato i vantaggi di vcore offerti dai 32nm Bulk di Intel rispetto ai 28nm di GF. Quindi ancora oggi non sappiamo quanto sia davvero merito dell'architettura e quanto del silicio (non che la cosa sia piovuta dall'alto, visti gli enormi investimenti di Intel)...
Kaveri/Carrizo, girano con vcore pazzeschi (dovuto anche all'uso di transistor a più alta tensione di soglia)


Nel MT, in verità k10, era ancora una signor architettura, considerando le ridotte dimensioni, l'ipc e le frequenze non proprio risibili che era in grado di raggiungere.

Bulldozer e derivati migliorano, a livello di architettura, proprio le prestazioni ST: non si può non considerare l'altissima frequenza di clock che un architettura del genere teoricamente è in grado di raggiungere anche a scapito dell'efficienza.

Poi sui problemi del silicio, se non bastasse llano, c'è la testimonianza del cambio di roadmap...dal 10 core Piledriver siamo passati ad 8 core.:rolleyes:m per non parlare del fatto che solo il modello di punta BD doveva avere un TDP di 125W e il 10-15% di prestazioni in più del power7+ sul predecessore (e la stessa IBM riporta che il contributo del silicio per tali miglioramenti è del 6%, il 94% alle tecnologie implementate..)

Per l'ultima parte, c'è anche da considerare che AMD/GF consideravano cosa fatta e praticamente a costo ZERO il passaggio dal 32nm SOI al 22nm SOI (per il fatto che il SOI, a differenza del Bulk, richiede solamente la sostituzione della parte litografia e non di tutti i macchinari).
Mi sembra ovvio che il progetto Buldozer nel suo insieme ha messo l'ancora per quanto riguarda la potenza MT (intesa come n° di core massimo a parità di TDP sullo stesso die) al 32nm SOI pure al di sotto delle aspettative, e per APU al 28nm Bulk GF che indubbiamente è distante anni luce dal 22nm/14nm Intel.

Ti vorrei chiedere una cosa che non mi è chiara... qual'è il rapporto di incidenza sulla frequenza massima di un PP silicio in rapporto all'FO4?
Facendo un esempio, un 6700K ha Vcore superiori a 1,3V per 4GHz, e se un BD con FO4 17 fosse realizzato sullo stesso silicio, quanto si potrebbe alzare la frequenza massima e quanto potrebbe l'abbassamento del Vcore alla stessa frequenza? C'è qualche formula? Quello che vorrei dire è che un BD forse potrebbe girare a 5GHz def con il suo FO4 17 rispetto ad un core Intel con FO4 diverso, ed ovviamente essendo la potenza ST data da IPC * frequenza, un +33% di frequenza ammortizzerebbe parecchio la differenza di IPC (rapportando BD nel 32nm SOI a 4GHz max def, è ovvio che con meno frequenza = meno potenza ST, che però ERRONEAMENTE la si vuole additare in esclusiva all'IPC).

P.S.
Oggi mi sono preso 3 RX 480 (tutte le altre VGA defunte, grazie alla tamb equatoriale), poi farò una prova di OC e nel contempo una prova di Vcore minimo per valutare l'intuizione di Free Gordon.

[tuttodigitale]

Ti vorrei chiedere una cosa che non mi è chiara... qual'è il rapporto di incidenza sulla frequenza massima di un PP silicio in rapporto all'FO4?

sono inversamente proporzionali...il FO4 dell'architettura determina insieme al gate delay offerto dal silicio ad un determinato vore (in pico-secondi :eek: ), il tempo minimo necessario per stabilizzare i segnali dentro uno stadio.

se ipotizziamo, che il FO4 di BD lordo fosse del 25% più corto di Skylake (e imho lo è), significa un +33% di clock massimi TEORICI..
Ovviamente è da illusi pensare che si possa consumare uguale.

[bjt2]

sono inversamente proporzionali...il FO4 dell'architettura determina insieme al gate delay offerto dal silicio ad un determinato vore (in pico-secondi :eek: ), il tempo minimo necessario per stabilizzare i segnali dentro uno stadio.

se ipotizziamo, che il FO4 di BD lordo fosse del 25% più corto di Skylake (e imho lo è), significa un +33% di clock massimi TEORICI..
Ovviamente è da illusi pensare che si possa consumare uguale.

Dipende dal numero di transistors. Non avendo unità a 256 bit, un modulo BD potrebbe avere meno transistors di un core Skylake e quindi potrebbe consumare uguale o di meno...

[tuttodigitale]

Dipende dal numero di transistors. Non avendo unità a 256 bit, un modulo BD potrebbe avere meno transistors di un core Skylake e quindi potrebbe consumare uguale o di meno...
e sul piatto c'è da mettere diverse feature. :cool:

[cdimauro]

Non mi è chiaro se quel consumo include anche il resto del circuito, ma se vedi le altre pagine, hanno costruito un test chip con le 4 FPU, per compararle e c'è uno schema dei circuiti di contorno che servono per farli funzionare...
Ma si tratta sempre di un sistema di gran lunga più semplice rispetto a uno x86.

Sia chiaro che qui non mi riferisco al famigerato "legacy", che rimane ben confinato in determinati parametri di area occupata, e consumi.
Con due nodi più i finfet vs bulk tu pensi che non si riescano a guadagnare nemmeno 300MHz?
Sono processi produttivi completamente diversi. E io, in ogni caso, non ne ho la minima idea.
Tenendo conto che non è detto che un core zen abbia un numero di transitors pari a un MODULO XV...
:mbe: Ma prima non s'era detto che erano simili?
Non ne sarei sicuro... Un powerhog virus io credo che possa essere scritto, almeno per XV che ha 8 decoder
Lì inciderebbe di più, ma in ogni caso non potresti mai e poi mai tenere impegnate tutte le porte/unità di calcolo a disposizione, anche soltanto per il fatto che XV ne ha ben più di 8.
Secondo le specifiche HSA i processi su CPU e GPU possono essere indipendenti e comunicare con le normali routine IPC. Inoltre i processi GPU hanno pari dignità di quelli CPU e possono creare altri processi CPU o GPU.
Sì, ma il punto è: qual è il costo nell'utilizzare la GPU? Sicuramente non sarà di pochi cicli di clock.
CUDA non funzioa a livello di blocchi logici, devi creare delle funzioni con un dato prefisso e devi scrivere istruzioni esplicite per spararle sulla GPU (e occuparti del trasferimento dati da e verso GPU) e usare il preprocessore nvidia che poi richiama uno dei compilatori supportati. Obbiettivamente così è più semplice. Ma immagino che per HSA si possa fare una cosa simile. Non ho idea di come sia il software... Non ho processori o GPU AMD e non ho mai approfondito.
Sì, HSA non si sostituisce a strumenti come CUDA, OpenCL, o le pragma di Intel. Ma è uno strumento che possono utilizzare.
Io mi riferivo a Zen, so benissimo che BD ha dei limiti.
OK, scusami, ma pensavo ti riferissi a BD et similia, visto che stavamo parlando di questi processori in questo contesto.
Zen dovrebbe avere 4 ALU, 2 AGU e 4 pipeline FPU. Le affermazioni sull'essere 6 wide mi fanno sperare che abbia 6 decoder, o forse, avendo probabilmente una cache L0 per le uops, può leggerne 6 alla volta e mettere in coda per l'esecuzione. Oppure il 6 wide si riferisce alle 4 ALU e 2 AGU...
Propendo per un decoder a 4 vie, mentre IMO il 6-wide che appare soltanto nelle slide del CERN è da attribuire all'unità di issue/scheduling.
Si vedrà ad Hotchips ad Agosto...
Bene. Manca poco allora. Quanta sofferenza. :D
Comunque il vantaggio dei due scheduler INT e FP separati (e sembra anche per le operazioni L/S, perchè ho letto da qualche parte di scheduler multipli) è che, posto il limite di decodifica e/o issue dalla L0, si può far svuotare la coda anche con 10 uops ciclo... Un muxer oltre le 4 mops richiede un bit in più e quindi è più lento, ma se si divido i domini e faccio più mux fino a 4 porte risolvo il problema... L'idea di INTEL di coda unificata è ottima dal punto di vista della teoria delle code, ma si scontra con il fatto che oltre le 4 porte aumenti del 33% il ritardo (3 bit vs 2 bit) del muxer e quindi riduci il clock massimo. Quindi meglio più scheduler da 4 porte che un mega scheduler da 8 o 10 porte...
Intanto bisogna vedere SE e quanto l'uso di un mux a 3 bit incida sul famigerato FO4.

Poi ci sono un altro paio di considerazioni da fare. Intanto non è detto che si debba impiegare per forza un mux. Poi avere scheduler separati complica l'unità di issue, quella di retire, ed eventuali meccanismi tipo l'LSD di Intel o la cache L0.
Inoltre le porte multifunzione non mi piacciono...
Come mai?
EDIT: poi vedo quindi peggio ancora dallo schema di Haswell... Può fare 4 istruzioni INT e due delle 4 porte int possono fare le FPU, quindi 4+0, 3+1 o 2+2... Non può fare più di 2 istruzioni FP per ciclo?!?!?
No: quello è il massimo. Ma sono FP a 256 bit l'una. ;)
E se fai delle istruzioni SIMD intere o un branch o la divisione ti freghi la possibilità di 1 o 2 istruzioni FP?!?!?! E' una strage! Ecco perchè l'SMT non guadagna tanto...
Ehm... no. :) Prima di arrivare a usare le porte condivise per le operazioni FP devi passare da quelle più semplici di Int+Branch o Int+VecInt.

L'unico problema concreto capita con la divisione intera, che però capita molto raramente, per cui è trascurabile il fatto che si trovi nella porta più grossa/complessa.
Se Zen riuscirà a fare veramente 4 istruzioni FP + 4 int, per l'SMT sarebbe una manna! Altro che +25%... Ritratto il mio +30% e ritorno al mio +50/60% di un paio di mesi fa! Se INTEL con quelle limitazioni fa +25% Zen dovrebbe volare!
Intanto vedi sopra. Poi il decoder di Zen non è 4 + 4, ma ce n'è solo uno da massimo 4 istruzioni decodificate per ciclo di clock.

Infine devi tenere conto anche la tipologia di codice eseguito. Le porte non sono disposte a caso, ma IMO gli ingegneri di Intel avranno certamente tenuto conto di quanto e come vengano utilizzate dal codice reale.

Detto in altri termini, parlare astrattamente di 4 istruzioni FP + 4 Int lascia il tempo che trova, quando il codice che viene realmente eseguito si comporta e sfrutta le unità di calcolo in maniera diversa. ;)

[cdimauro]

NI. Questo è vero se si opera con lo stesso Vcore, ovvero se si ottiene frequenze superiori pari alla riduzione della complessità dello stadio...ma è possibile anche avere frequenza superiore e vcore inferiori. Non è automatico dire chi consuma di più...
Vero, avevo dimenticato il vcore.
se la questione fosse così semplice, non ti pare che AMD avrebbe puntato fin da subito ad una soluzione SMT2, che da diversi anni è custodita nei loro cassetti? (dai tempi di k8)
Beh, con BD credo che avessero fatto delle previsioni completamente diverse, che per loro magari erano ben superiori all'SMT2 di cui parli.

Solo che poi, però, non si sono avverate.
Avevo nei post dietro, riportato i vantaggi di vcore offerti dai 32nm Bulk di Intel rispetto ai 28nm di GF. Quindi ancora oggi non sappiamo quanto sia davvero merito dell'architettura e quanto del silicio (non che la cosa sia piovuta dall'alto, visti gli enormi investimenti di Intel)...
In sintesi, i 32nm Bulk di Intel sarebbero molto più vantaggiosi dei 28nm di GF?
Nel MT, in verità k10, era ancora una signor architettura, considerando le ridotte dimensioni, l'ipc e le frequenze non proprio risibili che era in grado di raggiungere.

Bulldozer e derivati migliorano, a livello di architettura, proprio le prestazioni ST: non si può non considerare l'altissima frequenza di clock che un architettura del genere teoricamente è in grado di raggiungere anche a scapito dell'efficienza.
E siccome le prestazioni vengono fuori dal prodotto fra frequenza ed efficienza (IPC), qualcosa è andato storto.

D'altra parte con le macroalu disposte con quei vincoli, l'IPC non poteva che essere basso.

E le frequenze non puoi tirarle su quanto vuoi, perché aumenti i consumi (a parità di vcore, ovviamente).
Poi sui problemi del silicio, se non bastasse llano, c'è la testimonianza del cambio di roadmap...dal 10 core Piledriver siamo passati ad 8 core.:rolleyes:m per non parlare del fatto che solo il modello di punta BD doveva avere un TDP di 125W e il 10-15% di prestazioni in più del power7+ sul predecessore (e la stessa IBM riporta che il contributo del silicio per tali miglioramenti è del 6%, il 94% alle tecnologie implementate..)
Sì, di questo ne avevi già parlato quando replicavi a Ren.

[paolo.oliva2]

sono inversamente proporzionali...il FO4 dell'architettura determina insieme al gate delay offerto dal silicio ad un determinato vore (in pico-secondi :eek: ), il tempo minimo necessario per stabilizzare i segnali dentro uno stadio.

se ipotizziamo, che il FO4 di BD lordo fosse del 25% più corto di Skylake (e imho lo è), significa un +33% di clock massimi TEORICI..
Ovviamente è da illusi pensare che si possa consumare uguale.

Quidi in teoria a tutt'oggi potremmo avere:

Zen con un range dal -10% al -15% di IPC inferiore ad Intel.

Il 14nm FinFet GF ~-15% come qualità rispetto a quello Intel, con il PP da verificare perchè quello Intel non sembrerebbe riuscito bene per le frequenze massime (almeno in accoppiata con l'FO4 Intel)

Zen con un range di frequenze def superiore dal +20% al +35% rispetto alle frequenze def Intel (praticamente valutando l'FO4 di Zen ~BD con una approssimazione PP 14nm GF inferiore/migliore del PP 14nm Intel).

SMT ~+25% e >+30%.

Le riflessioni di Bjt2 sulla potenzialità SMT di Zen io le trovo coerenti semplicemente perchè a tutt'oggi considerando esclusivamente la parte ST di Zen, concordo che la potenza ST aumenterebbe, ma bisogna considerare l'insieme. La discussione sulle frequenze massime di Zen si basa principalmente sul fatto che Zen se avesse lo stesso FO4 di BD si dubita sul >+40% di IPC su XV, e quindi con un FO4 ~= ad Intel, Zen non potrebbe avere frequenze superiori ad Intel.
Facciamo un passo indietro... allora. Se BD come XV sul 28nm arriva a frequenze di 4,3GHz in turbo, mi pare ASSOLUTAMENTE CERTO che il passaggio al 14nm GF non solo porterebbe ad un -50% e superiore del TDP a parità di transistor, ma anche ad un aumento delle frequenze massime.

Il mio ragionamento è semplicissimo... dal punto di vista efficienza, a parità di silicio, in MT il CMT (XV) non ha una efficienza inferiore all'SMT.
---
(considerando che il 14nm GF permetterebbe un XV X16 e se un 6900K andrebbe in MT tanto quanto due 8350, e due XV X8 andrebbero il +20% di due 8350, mi sembra ovvio che un XV X16 sarebbe più vicino ad un 6950X di quanto lo sarebbe verso un 6900K. Fermo restando che PD è 2 architetture addietro di XV e PD ha meno set di istruzioni native rispetto a XV)
---
Certo, in ST Zen avrebbe +>40% di IPC, ma guardiamo la cosa nel dettaglio.
Nei forum si legge di frequenze Zen addirittura inferiori a quelle Intel.
Quindi, se Intel per un X8 arriva a 3,5GHz come massimo, saremmo già a -20% rispetto alla frequenza BD XV sul 28nm Bulk GF, il che porterebbe Zen a SOLAMENTE +12% su XV sull'ST (100 + 40% Zen = 140, -20% = 112)
In questo solamente +12%, va incluso:
- 14nm GF NON migliore in frequenza massima rispetto al 28nm Bulk GF
- Tutte le modifiche apportate in Zen circa implementazione cache L0, cache più veloci e cache inclusive che sicuramente se implementate in BD XV ne aumenterebbero l'IPC.
---
Ad esempio BD perdeva nel saltello dei TH da core a core semplicemente perchè se il TH si spostava da un modulo ad un altro, di fatto il core dell'altro modulo doveva aspettare che i dati si spostavano dalla L2 del modulo es 1, alla L3 e di qui alla L2 del modulo facente parte il core a cui è spostato il TH.
---

Io non capisco l'interno dei proci... ma intuitivamente mi sembra che sarebbe stato molto più semplice cercare di aumentare ulteriormente l'IPC di BD/XV e magari potenziarne l'FP per far si che XV con il suo FO4 e frequenze * IPC uguagliassero Zen e nel contempo sfruttare l'MT dato dalla maggiore efficienza del CMT vs SMT. Ma è ovvio che questo discorso è valido a patto che l'SMT di Zen abbia le stesse potenzialità dell'SMT Intel, perchè se risultasse > del 30%, è ovvio che Zen SMT risulterebbe migliore di XV CMT.

[Free Gordon]

Ragazzi, da ignorantone vi porterei a considerare una cosa che forse vi è sfuggita: l'esordio dei 14nm GF non è dei migliori, le RX480 salendo di tensione e frequenze (1500mhz), hanno consumi che sfiorano le vecchie Hawaii sui 28nm..

Se queste sono le premesse...
anche se i transistor di Zen saranno diversi, anche se l'architettura sarà straottimizzata per avere consumi bassi... (è un'ipotesi), non aspettiamoci che GF possa rivaleggiare faccia a faccia con le fonderie Intel.

Già non riesce a farlo ora con TSMC (e i suoi 16nm), perdendo qualcosina in efficienza rispetto a loro.

Certo, i costi per die resteranno magari bassi.. e con tensioni basse i consumi saranno anche ottimi.

Ma rendiamoci conto già da ora, che GF non sarà il partner che farà spiccare il volo a Zen. Perlomeno non nel 2016... :)

Se Zen lo farà, lo farà essenzialmente grazie ad un'architettura perfettamente ritagliata sui punti di forza di quel processo (primo fra tutti credo la densità) e grazie all'architettura interna molto all'avanguardia.
O perlomeno è quello che spero... :oink: :oink: :oink:

[tuttodigitale]

Facciamo un passo indietro... allora. Se BD come XV sul 28nm arriva a frequenze di 4,3GHz in turbo, mi pare ASSOLUTAMENTE CERTO che il passaggio al 14nm GF non solo porterebbe ad un -50% e superiore del TDP a parità di transistor, ma anche ad un aumento delle frequenze massime.
forse 50% è tanto...
PS le 10.5T, vengono chiamate Ultra high-Performance Library...un indizio? :cool:

[capitan_crasy]

Ragazzi, da ignorantone vi porterei a considerare una cosa che forse vi è sfuggita: l'esordio dei 14nm GF non è dei migliori, le RX480 salendo di tensione e frequenze (1500mhz), hanno consumi che sfiorano le vecchie Hawaii sui 28nm..

Se queste sono le premesse...
anche se i transistor di Zen saranno diversi, anche se l'architettura sarà straottimizzata per avere consumi bassi... (è un'ipotesi), non aspettiamoci che GF possa rivaleggiare faccia a faccia con le fonderie Intel.

Già non riesce a farlo ora con TSMC (e i suoi 16nm), perdendo qualcosina in efficienza rispetto a loro.

Certo, i costi per die resteranno magari bassi.. e con tensioni basse i consumi saranno anche ottimi.

Ma rendiamoci conto già da ora, che GF non sarà il partner che farà spiccare il volo a Zen. Perlomeno non nel 2016... :)

Se Zen lo farà, lo farà essenzialmente grazie ad un'architettura perfettamente ritagliata sui punti di forza di quel processo (primo fra tutti credo la densità) e grazie all'architettura interna molto all'avanguardia.
O perlomeno è quello che spero... :oink: :oink: :oink:

Gordon con tutto il rispetto sei tu che sei il deluso e questo lo si vedeva post addietro quando davi previsioni fin troppe ottimistiche su questa GPU.
Visto da uno (io me;) ) che ha sempre vissuto nella fascia media (anche perchè la svalutazione delle schede enthusiasm o direttamente inferiori è un qualcosa di sconvolgente:rolleyes: ) Polaris forse è la migliore GPU di AMD/ATI di sempre al prezzo dichiarato di 200 dollari.
Polaris sostituisce Tonga e mediamente va come Hawaii (a volte di più di una 390) consumando molto meno e considera che la versione a 4GB sul mercato tedescoso la trovavi a 219/229 euro.
Inoltre te lo dico ancora una volta non puoi confrontare le CPU con le GPU e anche se hanno lo stesso silicio non sono direttamente paragonabili soprattutto quando una di essa non è ancora (ma forse no:D ) in fase di pre-produzione...

[bjt2]

Ma si tratta sempre di un sistema di gran lunga più semplice rispetto a uno x86.

Sia chiaro che qui non mi riferisco al famigerato "legacy", che rimane ben confinato in determinati parametri di area occupata, e consumi.

Sono processi produttivi completamente diversi. E io, in ogni caso, non ne ho la minima idea.

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

:mbe: Ma prima non s'era detto che erano simili?

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

Lì inciderebbe di più, ma in ogni caso non potresti mai e poi mai tenere impegnate tutte le porte/unità di calcolo a disposizione, anche soltanto per il fatto che XV ne ha ben più di 8.

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

Sì, ma il punto è: qual è il costo nell'utilizzare la GPU? Sicuramente non sarà di pochi cicli di clock.

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

Sì, HSA non si sostituisce a strumenti come CUDA, OpenCL, o le pragma di Intel. Ma è uno strumento che possono utilizzare.

OK, scusami, ma pensavo ti riferissi a BD et similia, visto che stavamo parlando di questi processori in questo contesto.

Propendo per un decoder a 4 vie, mentre IMO il 6-wide che appare soltanto nelle slide del CERN è da attribuire all'unità di issue/scheduling.

Daltronde anche uno degli ultimi POWER ha 16 pipeline, ma è un issue 10, nel senso che può avviare max 10 uop per ciclo sulle 16 pipeline...

Bene. Manca poco allora. Quanta sofferenza. :D

Intanto bisogna vedere SE e quanto l'uso di un mux a 3 bit incida sul famigerato FO4.

Ma anche solo per il fan out superiore, 8 vs 4, per definizione aumenta il FO4... Poi un decoder a 3 bit ha più porte di uno a 2 bit... Ricordo che il FO4 suppone 4 gates a valle... Se diventano 8, il FO4 equivalente cresce...

Poi ci sono un altro paio di considerazioni da fare. Intanto non è detto che si debba impiegare per forza un mux. Poi avere scheduler separati complica l'unità di issue, quella di retire, ed eventuali meccanismi tipo l'LSD di Intel o la cache L0.

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

Come mai?

Perchè mischiare int e fp porta problemi nell'SMT

No: quello è il massimo. Ma sono FP a 256 bit l'una. ;)

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

Ehm... no. :) Prima di arrivare a usare le porte condivise per le operazioni FP devi passare da quelle più semplici di Int+Branch o Int+VecInt.

L'unico problema concreto capita con la divisione intera, che però capita molto raramente, per cui è trascurabile il fatto che si trovi nella porta più grossa/complessa.

Ovviamente immaginavo che dietro il posizionamento delle pipeline ci fosse stato un attento studio, anche simulativo, del tipo: ho 8 porte, il software è composto da questo mix di istruzioni... Trova il posizionamento ottimale... Sono problemi di ottimizzazione che si fanno a Ricerca operativa... Algoritmi di ottimizzazione depht first, breadth first... Ecc... Ricordi vaghi dell'università... :D

Intanto vedi sopra. Poi il decoder di Zen non è 4 + 4, ma ce n'è solo uno da massimo 4 istruzioni decodificate per ciclo di clock.

Io spero che siano di più... AMD ha già avuto esperienza con il primo BD di soli 4 decoder per 2 thread, senza cache L0... O la cache L0 è in grado di sparare 8 mops per ciclo, oppure ci vogliono 8 decoder per sperare di eguagliare XV in MT... Ricordo che il P4 aveva pochi decoder (2 mi pare) affidandosi alla cache L0...

Infine devi tenere conto anche la tipologia di codice eseguito. Le porte non sono disposte a caso, ma IMO gli ingegneri di Intel avranno certamente tenuto conto di quanto e come vengano utilizzate dal codice reale.

Vedi sopra... :)

Detto in altri termini, parlare astrattamente di 4 istruzioni FP + 4 Int lascia il tempo che trova, quando il codice che viene realmente eseguito si comporta e sfrutta le unità di calcolo in maniera diversa. ;)

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

[bjt2]

Ragazzi, da ignorantone vi porterei a considerare una cosa che forse vi è sfuggita: l'esordio dei 14nm GF non è dei migliori, le RX480 salendo di tensione e frequenze (1500mhz), hanno consumi che sfiorano le vecchie Hawaii sui 28nm..

Se queste sono le premesse...
anche se i transistor di Zen saranno diversi, anche se l'architettura sarà straottimizzata per avere consumi bassi... (è un'ipotesi), non aspettiamoci che GF possa rivaleggiare faccia a faccia con le fonderie Intel.

Già non riesce a farlo ora con TSMC (e i suoi 16nm), perdendo qualcosina in efficienza rispetto a loro.

Certo, i costi per die resteranno magari bassi.. e con tensioni basse i consumi saranno anche ottimi.

Ma rendiamoci conto già da ora, che GF non sarà il partner che farà spiccare il volo a Zen. Perlomeno non nel 2016... :)

Se Zen lo farà, lo farà essenzialmente grazie ad un'architettura perfettamente ritagliata sui punti di forza di quel processo (primo fra tutti credo la densità) e grazie all'architettura interna molto all'avanguardia.
O perlomeno è quello che spero... :oink: :oink: :oink:

Scusami... Ma le Hawaii a 28nm avevano quel consumo a 1500MHz? No! Perchè non ci arrivavano nemmeno! E' chiaro che se sali in frequenza consumi di più... In questo consiste avere un nuovo processo: poter salire di più a parità di potenza...

[paolo.oliva2]

Ragazzi, da ignorantone vi porterei a considerare una cosa che forse vi è sfuggita: l'esordio dei 14nm GF non è dei migliori, le RX480 salendo di tensione e frequenze (1500mhz), hanno consumi che sfiorano le vecchie Hawaii sui 28nm..

Se queste sono le premesse...
anche se i transistor di Zen saranno diversi, anche se l'architettura sarà straottimizzata per avere consumi bassi... (è un'ipotesi), non aspettiamoci che GF possa rivaleggiare faccia a faccia con le fonderie Intel.

Già non riesce a farlo ora con TSMC (e i suoi 16nm), perdendo qualcosina in efficienza rispetto a loro.

Certo, i costi per die resteranno magari bassi.. e con tensioni basse i consumi saranno anche ottimi.

Ma rendiamoci conto già da ora, che GF non sarà il partner che farà spiccare il volo a Zen. Perlomeno non nel 2016... :)

Se Zen lo farà, lo farà essenzialmente grazie ad un'architettura perfettamente ritagliata sui punti di forza di quel processo (primo fra tutti credo la densità) e grazie all'architettura interna molto all'avanguardia.
O perlomeno è quello che spero... :oink: :oink: :oink:

:D.

Io mica mi faccio pretese assurde... a me BASTA e AVANZA la fotocopia della RX 480.

Il 14nm GF della RX 480 non ha certo perso in frequenza rispetto al silicio precedente. Benissimo, allora vuol dire che se l'FO4 di Zen è lo stesso di BD e BD con XV sul 28nm GF arriva a 4,3GHz, allora Zen non dovrebbe avere una frequenza inferiore... ma se proprio la vogliamo pensare inferiore, da 4,3GHz la strada è lunga per arrivare già sotto i 4GHz, figuriamoci a 3,5GHz o ancora peggio 3GHz.

Non ho visto un aumento a dismisura del prezzo per mmq sul 14nm, quindi sulla stessa linea, dal 28nm BULK GF, che in BR vede 3,2 milioni di transistor su 245mmq di silicio, un Zen che al 1000% avrà meno transistor ed una superficie die di certo non superiore, secondo me avrà un rapporto prezzo/prestazioni sulla linea dell'8350, e mi fa ben sperare visto che un BR è max 150$.

Ora... AMD UFFICIALMENTE riporta che Zen X8+8 avrà una potenza doppia rispetto ad un 8350. Oggi quanto spendi per avere quella potenza? 1000€, o un 5960X o un 6900K. Zen secondo te costerà 1000€? Per me sarebbe già un totale 500€, figurati. Vuoi che una mobo AM4 sia pure la top della top costerà quanto una 2011 V3? Neppure lontanamente.
Fai la somma... vuoi un processore che va più di un 6900K (vedi 6950X) e pagarlo 1800€, oppure ti accontenteresti di un Zen alias 5960X marcato AMD a 500€ risparmiando almeno un 30% sul costo della mobo? Sulla base RX 480 non c'è ASSOLUTAMENTE nulla per essere pessimisti. Se il 14nm GF avesse lo stesso prezzo che Intel applica al suo 14nm, la RX 480 costerebbe sopra i 1000€

P.S.
Per dichiarazioni ufficiali, entrambe di AMD, IPC >+40% su XV e Zen X8+8 = +100% di un 8350, Zen non può avere una frequenza DEF su tutti i core inferiore a 3,7GHz.

[Free Gordon]

Gordon con tutto il rispetto sei tu che sei il deluso e questo lo si vedeva post addietro quando davi previsioni fin troppe ottimistiche su questa GPU.


Ti dirò...non sono particolarmente deluso dalle prestazioni (mi aspettavo qualcosa in più della 980, invece va' quasi in pari alla 980 ref. in condizioni favorevoli) quanto dai consumi...

I consumi, vuoi per molti motivi non ancora compresi a fondo, sono davvero troppo alti...

Faccio un discorso a spanne...me ne rendo conto...ma se le premesse sono queste, GF non credo proprio abbia in mano qualcosa di paragonabile ad Intel, quindi Zen parte già un pò svantaggiato. Poi migliorerà...ne sono certo, in quello sono bravi :) ma...per i primi Zen, le mie aspettative sono un pò ridimensionate.

Mentre per quel che riguarda la RX480, non è reale ciò che dici: è una scheda che fa quel che deve fare, nè più nè meno. Non rivoluziona nulla, nè a livello performance nè a livello costi (ha esattamente il costo della scheda che và a sostituire, la 380..)

Guarda quì... ;)

https://tpucdn.com/reviews/AMD/HD_7850_HD_7870/images/perfrel.gif

La 7850 (250$) era a ridosso della top di gamma precendente 6970 (369$).. ;)
Stessa situazione attuale, cambio pp e generazione nuova. ;) (anzi, con le HD700 c'era anche stato il salto a GCN, con tutti i problemi driver del caso).

Un pò come la RX480 oggi nei confronti della 390X...anzi, nel caso della 7850 forse persino un pò meglio.

Per quanto riguarda l'incremento prestazionale pari fascia, idem:
6850:62% (179$)
7850: 87%. ---> 40% di incremento. ;)
Più o meno quello che c'è oggi sulle 2 380 Tonga.. (anch'esse 199 e 229$ come Polaris10)

La RX480 fa esattamente ciò che deve fare, niente di più niente di meno. ;)

Il marketing che hanno messo su stavolta, è stato ottimo...e il tempismo anche :D ma non la vedo nè male nè bene. E' una buona scheda che fa quel che deve.

NON è certamente la nuova 5850. ;) Imho, alla luce dei fatti a metà 2016, quella resta sempre la 290 liscia o la 7870 ghz. I veri must buy di AMD di questi anni.
Cmq per me fine OT. ;)

[Free Gordon]

Fai la somma... vuoi un processore che va più di un 6900K (vedi 6950X) e pagarlo 1800€, oppure ti accontenteresti di un Zen alias 5960X marcato AMD a 500€ risparmiando almeno un 30% sul costo della mobo?

Guarda...si avverasse questa ipotesi (nei 125W di TDP), sarei il primo a festeggiare e stappare bottiglie di Champagne per l'occasione.
Non sarebbe il mio procio, io ripiegherei su una versione da 300€ o meno.. ma sarebbe la rinascita che attendiamo tutti da tempo...senza dubbio. ;)

[bjt2]

:D.

Io mica mi faccio pretese assurde... a me BASTA e AVANZA la fotocopia della RX 480.

Il 14nm GF della RX 480 non ha certo perso in frequenza rispetto al silicio precedente. Benissimo, allora vuol dire che se l'FO4 di Zen è lo stesso di BD e BD con XV sul 28nm GF arriva a 4,3GHz, allora Zen non dovrebbe avere una frequenza inferiore... ma se proprio la vogliamo pensare inferiore, da 4,3GHz la strada è lunga per arrivare già sotto i 4GHz, figuriamoci a 3,5GHz o ancora peggio 3GHz.

Non ho visto un aumento a dismisura del prezzo per mmq sul 14nm, quindi sulla stessa linea, dal 28nm BULK GF, che in BR vede 3,2 milioni di transistor su 245mmq di silicio, un Zen che al 1000% avrà meno transistor ed una superficie die di certo non superiore, secondo me avrà un rapporto prezzo/prestazioni sulla linea dell'8350, e mi fa ben sperare visto che un BR è max 150$.

Ora... AMD UFFICIALMENTE riporta che Zen X8+8 avrà una potenza doppia rispetto ad un 8350. Oggi quanto spendi per avere quella potenza? 1000€, o un 5960X o un 6900K. Zen secondo te costerà 1000€? Per me sarebbe già un totale 500€, figurati. Vuoi che una mobo AM4 sia pure la top della top costerà quanto una 2011 V3? Neppure lontanamente.
Fai la somma... vuoi un processore che va più di un 6900K (vedi 6950X) e pagarlo 1800€, oppure ti accontenteresti di un Zen alias 5960X marcato AMD a 500€ risparmiando almeno un 30% sul costo della mobo? Sulla base RX 480 non c'è ASSOLUTAMENTE nulla per essere pessimisti. Se il 14nm GF avesse lo stesso prezzo che Intel applica al suo 14nm, la RX 480 costerebbe sopra i 1000€

P.S.
Per dichiarazioni ufficiali, entrambe di AMD, IPC >+40% su XV e Zen X8+8 = +100% di un 8350, Zen non può avere una frequenza DEF su tutti i core inferiore a 3,7GHz.

Se, come penso io, l'efficienza dell'SMT AMD è superiore a quella INTEL, e quindi nell'ordine del 40-60%, le affermazioni di IPC=+40% e MT +100% non sono incompatibili con una frequenza più bassa, sui 3.5GHz... Perchè la prima non nomina la frequenza e la seconda può essere raggiunta con un clock inferiore all'8350 se l'efficienza SMT è superiore a quella INTEL...

[Free Gordon]

Scusami... Ma le Hawaii a 28nm avevano quel consumo a 1500MHz? No! Perchè non ci arrivavano nemmeno! E' chiaro che se sali in frequenza consumi di più... In questo consiste avere un nuovo processo: poter salire di più a parità di potenza...

Da 28nm TSMC a 14nm GF sono saliti su un chip un pò più piccolo di Hawaii, da 1050mhz a 1265!

215mhz... :rolleyes:

Sono il 20% in frequenza....per restare in un consumo accettabile (praticamente consuma come la 970 a 28nm... :stordita: ).

Anche questo non è il passo avanti che ci si aspettava.

Chiaro che sul discorso consumi, GCN ha delle grandi responsabilità... (non la sto criticando, sto solo giudicando obiettivamente l'aspetto dei consumi).

Credo che le RX480 siano delle buone schede... (probabilmente prenderò una NITRO Sapphire :D ) ma dato questo esordio, il pp di GF non mi ispira fiducia alcuna... :D

[tuttodigitale]

Da 28nm TSMC a 14nm GF sono saliti su un chip un pò più piccolo di Hawaii, da 1050mhz a 1265!

215mhz... :rolleyes:

Sono il 20% in frequenza....per restare in un consumo accettabile (praticamente consuma come la 970 a 28nm... :stordita: ).

Anche questo non è il passo avanti che ci si aspettava.

Chiaro che sul discorso consumi, GCN ha delle grandi responsabilità... (non la sto criticando, sto solo giudicando obiettivamente l'aspetto dei consumi).

Credo che le RX480 siano delle buone schede... (probabilmente prenderò una NITRO Sapphire :D ) ma dato questo esordio, il pp di GF non mi ispira fiducia alcuna... :D
in effetti qualcosa sembra essere successo è molto strano che AMD abbia cannato le specifiche Pci Express...resta il fatto che è la prima VGA a 14nm che ha una buona disponibilità....magari sono vcore sparati alti per avere le rese migliori.

PS 20% di FMAX, se fossero confermati, non sono pochi anzi. :cool: Pensa che da rv790 (55nm) a Barts (40nm), siamo passati da 850 a 900 MHz.

GCN non credo che sia l'architettura la responsabile del debacle....la Fury aveva un'efficienza piuttosto alta...
https://tpucdn.com/reviews/AMD/RX_480/images/perfwatt_2560_1440.png

vedrai che le ottimizzazioni del caso, saranno efficaci su Vega.


La RX480 fa esattamente ciò che deve fare, niente di più niente di meno. ;)

con la concorrente che sta tirando un pò troppo la corda sui prezzi, non era assolutamente scontato

[bjt2]

Da 28nm TSMC a 14nm GF sono saliti su un chip un pò più piccolo di Hawaii, da 1050mhz a 1265!

215mhz... :rolleyes:

Sono il 20% in frequenza....per restare in un consumo accettabile (praticamente consuma come la 970 a 28nm... :stordita: ).

Anche questo non è il passo avanti che ci si aspettava.

Chiaro che sul discorso consumi, GCN ha delle grandi responsabilità... (non la sto criticando, sto solo giudicando obiettivamente l'aspetto dei consumi).

Credo che le RX480 siano delle buone schede... (probabilmente prenderò una NITRO Sapphire :D ) ma dato questo esordio, il pp di GF non mi ispira fiducia alcuna... :D

Non sono esperto di GPU, ma quanto consuma Hawaii a 1050MHz? Più o meno di questa 480? E che prestazioni ha? Poi se a parità di SP e frequenza ha maggiori prestazioni, allora quelle SP saranno sfruttate di più... Bisogna vedere il complesso...

[paolo.oliva2]

Se, come penso io, l'efficienza dell'SMT AMD è superiore a quella INTEL, e quindi nell'ordine del 40-60%, le affermazioni di IPC=+40% e MT +100% non sono incompatibili con una frequenza più bassa, sui 3.5GHz... Perchè la prima non nomina la frequenza e la seconda può essere raggiunta con un clock inferiore all'8350 se l'efficienza SMT è superiore a quella INTEL...

Ma io sinceramente ho "sposato" la tua ipotesi di un SMT "superiore" per Zen, semplicemente perchè se AMD ha scelto Zen a XV (spendendoci soldi e tempo) vuol dire che Zen è preferibile a XV, vuoi per numero transistor, vuoi per potenze).
Come ho detto addietro, Zen andrebbe tanto quanto XV in MT (e poi solamente di un +2-3%) SOLAMENTE se a parità di frequenza operativa (3,7GHz sul 28nm Bulk ma 4GHz o più su un PP silicio migliore del 28nm Bulk GF) ed in ST il +40% sempre a parità di frequenza turbo (4,3GHz almeno). Già un -10% di frequenza def e Turbo per Zen vs XV equivarrebbe ad una perdita di incremento IPC enorme (100 +40% = 140, -10% = 126 = come incremento IPC +26% e non più +40%, e con MT in cui l'SMT non uguaglierebbe quanto farebbe il modulo CMT con XV (126 +30% SMT = 163,8 vs 180 CMT).

Vedi Bjt2, io faccio solamente un discorso "logico" dal punto di vista rischio progettazione/produzione Zen vs XV.

AMD non può, razionalmente, buttarsi su una alternativa a BD/XV/CMT senza avere determinate garanzie. Il tuo discorso di un SMT "superiore" torna a brodo, perchè Zen è partito in stesura PRIMA che AMD avesse tutte le certezze di quale clock potrebbe dare il 14nm SAMSUNG, quindi:

con +40% di IPC Zen può permettersi ~-30% di frequenza rispetto a XV e quindi risultare comunque preferibile a XV (e considerando XV ~4,3GHz, un Zen a 3GHz turbo risulterebbe comunque UGUALE)

In MT, noi partiamo SEMPRE dall'incremento SMT di Intel, che è +30%. E' qui il problema, perchè Zen sarebbe simile a XV in MT (1 core Zen + SMT vs modulo XV) SOLAMENTE a parità di frequenza.... ma mentre nel desktop (ST) si "salverebbe" per l'incremento IPC, in MT questo non varrebbe SALVO l'SMT di Zen incrementi >+30% rispetto a quello Intel, appunto perchè 100 + 40% (IPC) + SMT >+30% pareggerebbe con XV a parità di frequenza, ma considerando l'incremento SMT >30% (35%, 40%, 45%, 50%), a Zen proporzionalmente basterebbe via via una frequenza inferiore appunto per pareggiare con CMT/XV.

Infine, anche se da slide "commerciali", Zen dovrebbe avere 3,7GHz def ALMENO per pareggiare con due 8350 (facendo +40% di IPC e SMT +30%), ma avrebbe oltre +20% di frequenza def rispetto ad un 6900K, e già +200MHz rispetto a quella turbo del 6900K, mi sembra che ci sia qualche cosa che non torni (AMD fa la campagna pubblicitaria di Zen sull'MT (Zen = 2 * 8350, Zen Opteron X32+32, non spara incrementi ST), mentre se abbassassimo le frequenze def e turbo di Zen rispetto a XV, comunque Zen otterrebbe comunque maggior ST e MT nel caso di un SMT2 (migliore di SMT).

Ci sarebbe anche un'altra congettura... ai vari brand (tipo Mac) AMD DEVE aver fatto vedere la potenzialità di Zen come architettura e non di certo un Zen raffreddato ad azoto funzionante a 6GHz, quindi io credo probabile che Zen fatto vedere a frequenze migliorabili sia risultato più che soddisfacente, il che non è collegabile unicamente a solo +40% di IPC. Poi conta che avere quasi +50% di core (Intel X22 vs AMD X32), combacerebbero se Zen riuscirebbe a diminuire la frequenza perchè l'SMT percentualmente renderebbe meglio... quindi teoricamente agli 1,7GHz di un X22 Intel AMD potrebbe proporre un Zen a 1,5GHz (minor frequenza, miglior curva rendimento TDP) proprio perchè la potenza complessiva dei 2 TH risulterebbe simile.

[Ale55andr0]

GCN non credo che sia l'architettura la responsabile del debacle....la Fury aveva un'efficienza piuttosto alta...
o

grazie alle hbm e al relativo memory controller che ha permesso di risparmiare transistor rispetto quello delle gddr5 standard

[tuttodigitale]

edito
era una battuta, non vorrei che poi si facessero dei ragionamenti,

http://news.mynavi.jp/articles/2015/12/28/processing/images/037.jpg
http://news.mynavi.jp/articles/2015/12/28/processing/images/038.jpg

[tuttodigitale]

grazie alle hbm e al relativo memory controller che ha permesso di risparmiare transistor rispetto quello delle gddr5 standard
adesso non esageriamo...su una scheda da 300W, quale è la Fury, non è possibile che il merito sia tutta delle HBM.
se le informazioni fornite da AMD sono esatte, una r9 390x, consumerebbe "solo" 20W in meno con le HBM..aumento dell'efficienza 300/280 del 7%. C'è da dire che nonostante il 4 MC HBM siano grandi quanto 3/4 dei 8 MC da 64 bit di Hawaii, e nonostante che il chip abbia prestazioni FP64 notevolmente più basse, le prestazioni di Fiji per transistor sono significativamente inferiori...
la causa pare essere il pixel fill-rate limitato...Fiji potenzialmente poteva avere un'efficienza ancora superiore.

La gestione della potenza tra la r9 380x e la fury x, è completamente diversa, a giudicare dai picchi
http://www.tomshw.it/consumi-r9-fury-x-gaming?gallery=67764&image=1
http://www.tomshw.it/gallerie/consumi-gaming-r9-380x-72068?gallery=72068&image=1

quella di Polaris rassomiglia parecchio a quello di Tonga.
www.tomshw.it/gallerie/consumi-gaming-r9-380x-72068?gallery=72068&image=1

e ben diversa da quella della gtx1080
http://www.tomshw.it/gallerie/gtx-1080-canali-in-gaming-77027?gallery=77027&image=1

c'è molto spazio per l'ottimizzazione....

[paolo.oliva2]

edito
era una battuta, non vorrei che poi si facessero dei ragionamenti,

http://news.mynavi.jp/articles/2015/12/28/processing/images/037.jpg
http://news.mynavi.jp/articles/2015/12/28/processing/images/038.jpg

Io faccio fatica a capire.
Cioè (nella prima slide)... un quad-core (non so quale né con quale FO4) con solamente +0,08V incrementa la frequenza di 260MHz o, meglio, circa di +17%.

Ora... a seconda dell'FO4 la frequenza varia al medesimo Vcore, quindi 1,44GHz a 0,72V potrebbero pure passare a 2GHz allo stesso Vcore e il +17% di 2GHz corrisponderebbe a 400MHz e non 260MHz (facendo un esempio a spannella).

Con le librerie 10.5T potrebbe migliorare qualche cosa...

Purtroppo quello che manca a tutt'oggi sarebbe un bel screen CPU-Z di Zen a X Vcore e X frequenza :sofico: e poi da lì un OC a X Vcore e X frequenza ... allora si che sarebbe un metro incontestabile.

Per me è relativo quale Vcore avrà Zen a def, quanto invece il margine di overvolt sul Vcore def e l'incremento di frequenza ad ogni step di Vcore rimanendo dentro al raffreddamento aria/liquido.

Zen potrebbe avere anche 1,1V a def ed essere 95W ma poi scoppiare a 1,2V nel TDP e guadagnare un nulla di frequenza, come pure essere 125W a 1,1V ma rientrare nei 140W a 1,2V e reggere un overvolt sino a 1,3/1,35V.

[Ren]

Finalmente hanno chiarito le possibilità di scelta del LPP.

http://news.mynavi.jp/articles/2015/12/28/processing/images/034.jpg

Si perde in densità, ma si guadagna quel fantomatico 10% in performance (dichiarato tempo fa).

Bisogna vedere sul campo come si comporta...

[Ren]

Il settore HPC sta diventando troppo affollato. (azzi di intel).

Eccovi un piccolo clone di haswell by broadcom :asd:

http://n.mynv.jp/articles/2015/12/28/processing/images/015l.jpg

[tuttodigitale]

Io faccio fatica a capire.

L'ho postata perchè innanzitutto l'ho trovata:D
Quello che volevo sottolineare, che a livello di dimensioni, nell'adottare le HDL (9T) o le HPL (10.5T) è praticamente ininfluente. La differenza è inferiore al 11% nel caso in esame...se contiamo il maggior quantitativo di SRAM, che non beneficia delle librerie ad alta densità, le differenze almeno a livello di modulo sono insignificanti...A questo punto credo anche i vantaggi offerte nelle soluzioni a bassa frequenza siano risibili per contenere il consumo.
IMHO, si va dritto di librerie Ultra-High-Performance (speriamo che non lo siano solo le librerie :cool: )


Zen potrebbe avere anche 1,1V a def ed essere 95W ma poi scoppiare a 1,2V nel TDP e guadagnare un nulla di frequenza, come pure essere 125W a 1,1V ma rientrare nei 140W a 1,2V e reggere un overvolt sino a 1,3/1,35V.

Penso che ricavare qualcosa di davvero significativo in termini di prestazioni oltre i 1,1V sia a dir poco utopitisco. I grafici sul gate delay di Intel e TSMC, mostrano questo.

Se ZEN vuole superare i 4 GHz in turbo boost, deve quanto meno raggiungerli a 1,1V...e il FO4 ridotto può venire in soccorso. ovviamente imho

Il leakage nei FINFET è tenuto sottocontrollo anche con temperature di giunzione elevate. Questo è un elemento interessante...


Zen potrebbe avere anche 1,1V a def ed essere 95W ma poi scoppiare a 1,2V nel TDP e guadagnare un nulla di frequenza, come pure essere 125W a 1,1V ma rientrare nei 140W a 1,2V e reggere un overvolt sino a 1,3/1,35V.
non credo che i consumi esplodano. i Finfet sembrano mantenere sotto controllo il leakage (avevo postato un grafico dove i 22/14 nm finfet si comportavano decisamente meglio dei 32nm all'aumentare del vcore mantenendo stabile il clock) anche con tensioni elevate, ma la contropartita, è che la reattività del transistor aumenta in maniera assai blanda...quindi in un certo senso per avere un overclock significativo potrebbe essere necessario alzare e di molto il vcore.

[tuttodigitale]

Finalmente hanno chiarito le possibilità di scelta del LPP.

http://news.mynavi.jp/articles/2015/12/28/processing/images/034.jpg

Si perde in densità, ma si guadagna quel fantomatico 10% in performance (dichiarato tempo fa).

Bisogna vedere sul campo come si comporta...

Aspetta il 10% (che poi in questo link diventa 15% http://www.samsung.com/semiconductor/about-us/news/24581/) è riferito all'uso delle stesse librerie...
sul livello di integrazione dice che è addirittura migliorato
In addition, use of fully-depleted FinFET transistors brings enhanced manufacturing capabilities to overcome scaling limitations.

hanno modificato il transistor, che ora in tutte le versioni (dal HVT al sLVT) ha una corrente di pilotaggio decisamente maggiore....

[Ren]

Io faccio fatica a capire.
Cioè (nella prima slide)... un quad-core (non so quale né con quale FO4) con solamente +0,08V incrementa la frequenza di 260MHz o, meglio, circa di +17%.

Ora... a seconda dell'FO4 la frequenza varia al medesimo Vcore, quindi 1,44GHz a 0,72V potrebbero pure passare a 2GHz allo stesso Vcore e il +17% di 2GHz corrisponderebbe a 400MHz e non 260MHz (facendo un esempio a spannella).

La prima slide è il test design 9T. I risultati del 10.5t sono nella seconda slide.

[tuttodigitale]

Il settore HPC sta diventando troppo affollato. (azzi di intel).

Eccovi un piccolo clone di haswell by broadcom :asd:

http://n.mynv.jp/articles/2015/12/28/processing/images/015l.jpg

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

Insomma, le similutidini sono molte, sembra di vedere Sandy Bridge...è identico
http://cdn.arstechnica.net/wp-content/uploads/2010/09/sandybridge-uarch.png

[Ren]

Aspetta il 10% (che poi in questo link diventa 15% http://www.samsung.com/semiconductor/about-us/news/24581/) è riferito all'uso delle stesse librerie...
sul livello di integrazione dice che è addirittura migliorato
In addition, use of fully-depleted FinFET transistors brings enhanced manufacturing capabilities to overcome scaling limitations.

hanno modificato il transistor, che ora in tutte le versioni (dal HVT al sLVT) ha una corrente di pilotaggio decisamente maggiore....

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

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

[Ren]

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

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


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

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

Manca solo il qualcomm Hydra con il Kryo pompato.

[cdimauro]

Ma infatti io ho parlato di consumo della sola FPU ed ho moltiplicato per 4 in altri miei post il consumo della FPU per stimare il consumo del core...
Sì, lo so: ne abbiamo già parlato. Ma già ci sono parecchi dubbi sull'uso dell'FPU Neon, e qui IMO è ancora peggio, visto che quel sistema ha un'FPU molto più semplice perfino di Neon.
La verità è che ci sono tante incognite... Dalle misure ad occhio sulle foto del die di Zen, si è stimato da 150 a 250mmq il die di 8 Zen. Come vedi è una forbice piuttosto ampia. Siccome sappiamo che l'IPC ST è +40% e quello MT dovrebbe essere pari o poco superiore, si è supposto che in AMD non sappiano fare miracoli e che quindi il numero di transistors di un core Zen sia pari a quello di un modulo XV... Ma la L2 è inferiore e mancano 2 AGU e, forse, 4 decoder... Quindi il dubbio viene...
Beh, i transistor sono utilizzati in maniera diversa. E' vero che XV ha una cache L2 molto più grandi e 4+4 decoder, però Zen ha pure 4 porte per operazioni FP a 128 bit, mentre XV ne ha solo 2 di questo tipo.

Quanto alle dimensioni, dovrebbe essere possibile ricavare l'area di un modulo XV e quella di un core Zen e fare le dovute proporzioni. In genere lo fanno siti come Chip Architect.
Ma non parlavo delle unità singole attaccate alle porte, ovviamente, ma alle singole porte. XV ne ha 2+2ALU, 2+2AGU e 4FPU. Considerando che ha 8 decoder e che una MOP può anche avere una uop ALU+AGU, è possibile scrivere un powerhog virus con sole istruzioni registro-registro con throughput 1...
Se con una uop riesci a impegnare sia un'ALU sia un'AGU, allora sì: con 8 uop riesci a usare tutte le porte.
A quanto ho capito, CPU e GPU sono paritarie. E' come se la GPU fosse una grossa CPU SMT che accetta n thread (con n dipendente dalla GPU) che possono accedere liberamente alla memoria, anche virtuale, e quindi, a parte la diversa ISA, possono comunicare con i processi GPU e CPU con le normali funzioni per l'IPC... Paritarie nel senso che processi CPU e GPU possono creare e comunicare con altri processi CPU e GPU... Non conosco i dettagli, ma sembra interessante...
Sì, questo mi era chiaro. Il punto è che senza conoscere la latenza dell'offloading, non puoi sapere se sia conveniente o meno smistare un'operazione alla GPU o fargli fare il lavoro alla CPU.
Ultimamente si usano molto la sintetizzazione... Ricordo vagamente le lezioni sulla minimizzazione delle porte logiche per una data funzione... Il mux sarà implementato con il minimo delle porte (ad esempio un mux a 6 vie avrà meno porte di uno 8 vie anche se ha sempre 3 bit), ma penso ci voglia sempre un mux...
Io credo che se ne possa fare a meno. :)

Preciso che, però, non so come Intel abbia implementato il tutto nei suoi processori.
Perchè mischiare int e fp porta problemi nell'SMT
Non vedo perché: alla fine è compito dello scheduler smistare opportunamente le operazioni alle giuste porte, tenendo conto delle priorità che ho esposto prima.
Lo so... Ma sul codice legacy vedi che Zen (e anche BD) possono avere un vantaggio...
Tu stesso hai riportato prima un IPC di 2,4 nell'uso di codice floating point intensivo. Non di sole FADD/FMUL/FMAC/FMA vive l'FPU, ma anche di FMOV, FLOAD, FSTORE, ecc... e persino istruzioni "intere". ;)

Detto in altri termini, è difficile impegnare tutte e 4 le porte FP a 128 bit allo stesso momento.
Io spero che siano di più... AMD ha già avuto esperienza con il primo BD di soli 4 decoder per 2 thread, senza cache L0...
Anche i precedenti processori Intel facevano lo stesso, ma facendo uso dell'LSD (non quello che pensi :D).
O la cache L0 è in grado di sparare 8 mops per ciclo, oppure ci vogliono 8 decoder per sperare di eguagliare XV in MT...
Mi sembrano numeri troppo elevati, e poi funzionerebbe soltanto nei cicli, per l'appunto.
Ricordo che il P4 aveva pochi decoder (2 mi pare) affidandosi alla cache L0...
Non so se erano 2, ma il P4 non aveva alcuna cache codice L1: tutte le istruzioni venivano decodificate e memorizzate nella trace cache (tipo cache L0), ed è stato proprio questa la causa dei suoi problemi di prestazioni (oltre alla microscopica cache L1 dati).
E' ovvio che le 4+2+4 unità di Zen non saranno simmetriche... Ma più porte mi fanno sperare per meno vincoli e più potenziale IPC...
Sulla carta. Però ricorda sempre che stiamo parlando di processori out-of-order, ed è per questo che in un altro commento dicevo che un processore con meno porte potrebbe benissimo avere prestazioni simili a uno che ne ha di più. ;)

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

Potenza dell'esecuzione OoO. ;)

[tuttodigitale]

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

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

Manca solo il qualcomm Hydra con il Kryo pompato.
è da denuncia si....dicono che sarà la CPU ARM più veloce del mondo....quando lo sanno anche i sassi che è il fratello maggiore di ZEN :cool:

[tuttodigitale]

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

Se non ricordo male adesso hanno un CPP molto simile al TSMC16. (peccato, ma fa niente)
non dicono niente, ma pubblicizzano un SoC da smartphone. Poi mi pare difficile che oltre ad omettere il minor livello di integrazione rincarano la dose, facendo pensare che questa sia pure migliorata...poi si parla anche di minor consumi....e le librerie a più alte prestazioni sono penalizzanti da questo punto di vista.

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

[Ren]

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

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

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

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

Su carta il TSMC16 era peggio del 14LPE.:doh:

[tuttodigitale]

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

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


Se con una uop riesci a impegnare sia un'ALU sia un'AGU, allora sì: con 8 uop riesci a usare tutte le porte.
in teoria da un MOP possono uscire fino a 3uop...tuttavia è raro che questo avvenga.


Vi presento ZEN:
http://images.anandtech.com/doci/7910/Cyclone.png
scherzo.


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

Potenza dell'esecuzione OoO. ;)
ecco che il limite delle 2 ALU in XV non sembra così opprimente :cool:

[Ren]

Vi presento ZEN:
http://images.anandtech.com/doci/7910/Cyclone.png
scherzo.

Secondo le teorie Desdenboy aggiungerei :sofico:

Cyclone la clonazione.:sofico:

[bjt2]

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

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

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

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

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

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

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

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

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

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

Io credo che se ne possa fare a meno. :)

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

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

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

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

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

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

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

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

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

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

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

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

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

Potenza dell'esecuzione OoO. ;)

Certo... :D :cool:

[bjt2]

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

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

[tuttodigitale]

Secondo le teorie Desdenboy aggiungerei :sofico:

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

[bjt2]

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

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

[tuttodigitale]

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

[paolo.oliva2]

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

[digieffe]

... qualche novità qui ? (https://youtu.be/x2EruMTGbiU)

[cdimauro]

lo abbiamo fatto su questo sito...purtroppo ci manca un dato fondamentale il livello di integrazione della L2...se ipotizziamo il 70%, come Polaris, sono 250mmq.
Anche Polaris ha cache L1 e L2. Supponendo che siano simili a quelle di Zen, si potrebbe prendere una di queste per cercare di effettuare una misura più precisa.
in teoria da un MOP possono uscire fino a 3uop...tuttavia è raro che questo avvenga.
Dovrebbe essere per istruzioni con modalità d'indirizzamento della memoria a 3 operandi.

Comunque il meccanismo delle MOP -> più uop è simile a quello che c'è nelle CPU Intel.
Vi presento ZEN:
http://images.anandtech.com/doci/7910/Cyclone.png
scherzo.
:) E' sicuramente l'ARM più performante, per lo meno in single core/thread, ma è anche il motivo per cui non c'è da spaventarsi da quest'architettura:

Tested: Why the iPad Pro really isn't as fast a laptop (http://www.pcworld.com/article/3006268/tablets/tested-why-the-ipad-pro-really-isnt-as-fast-a-laptop.html)

:cool:
ecco che il limite delle 2 ALU in XV non sembra così opprimente :cool:
Non è così semplice il discorso. Se l'OoO bastasse a risolvere tutti i problemi di dipendenze & schedulazione, sarebbe sufficiente un decoder a 1 via e un backend OoO.

Ovviamente tutto dipende molto dalla tipologia di codice eseguito.

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

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

Se passiamo al codice non FP, allora cominciano i guai, perché non è più così semplice e lineare, e diverse volte sei pure costretto a ripopolare la pipeline. Qui anche la latenza troppo elevata di certe istruzioni crea non pochi problemi, perché impegna per troppo tempo le unità d'esecuzione, e l'unità di retire è lì che aspetta bloccando risorse che devono essere liberate per altre istruzioni.
riguardo il checkpoint. questa unità, è presente anche nelle CPU IBM: In sostanza questa unità determina se si sono verificati errori. L'unità genera ECC Quando questo si verifica, la matrice del checkpoint viene utilizzato per riavviare l'esecuzione, che quindi è in grado di risolvere problemi transitori, fino al cambio, credo inevitabile di CPU. In sostanza è un meccanismo di ridondanza orientata al mercato data-center.
Allora non porta alcun contributo a livello puramente prestazionale.

[cdimauro]

Beh, semplice o no, se raddoppiamo la mia stima, abbiamo il consumo di 4 pipeline a 128 bit che è il caso peggiore che potrebbe mai incontrare la FPU Zen (powerhog virus di 4 FMAC)
Io ormai aspetto qualche mese e mi levo ogni dubbio. :fagiano:
Se non mi sbaglio le altre 2 porte della FPU di BD/XV possono fare le istruzioni SSE intere, che comprendono comunque moltiplicazione e divisione... Quindi non è che le altre 2 pipeline occupino poi molto meno spazio...
Mi pare che quelle 2 porte siano relegate a codice legacy: MMX e x87.
E lo hanno fatto... :D I numeri che ho dato sono così vaghi perchè non ci sono notizie su quanto possa occupare la L3 e quindi fare le proporzioni...
Vedi sopra: e usare la L1 o la L2?
Potenza delle MOP AMD... :cool: :D Una MOP AMD può contenere fino a 3 uops!
ALU+AGU+MEM (!!!) Infatti molte istruzioni, anche reg+mem/reg sono implementate con una MOP e sono fastpath single... I decoder AMD sono di una VIULEEEENZA impressionante... :D
Beh, anche quelli Intel operano similmente. Lì non si parla di MOP, ma di uop "fused", che in fase di esecuzione vengono suddivise in 2 (non mi pare che si arrivi a 3, ma adesso non ho tempo per controllare) uop più semplice da dare in pasto alle rispettive porte.

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

Esempio: 4 e 1 per la MOV, e ben 7 e 1 per la ADD.
Beh, immagino che qualunque scomposizione in thread debba tenere conto della granularità del parallelismo e della latenza di creazione thread... :D Sappiamo che su windows, rispetto a linux creare processi è una tragedia greca! :D Meglio i thread... Eppure a occhio sembra che Windows 10 è migliorato: quando avevo windows 7 e ricaricavo 40 schede su chrome, con una estensione che si chama "reload all", il PC (mouse compreso) scattava e quasi si impiantava per qualche secondo mentre i 40 processi venivano creati... Ora con windows 10 la situazione è molto migliorata...
Quindi l'offloading ha senso se il working set ha una certa dimensione.
Hai ragione: a parità di porte la soluzione di INTEL è meglio, ma ovviamente su INTEL sono 4 totali, contro 4+4, quindi, a meno di disastri di AMD nello scheduler, l'efficienza dell'SMT dovrebbe essere superiore...
Dipende da quante uop (e non MOP o fused-uop) si possono inviare alle porte.
Non con 2 thread... :cool: Immagina un processo FP intensive con un IPC spec fp-like (non ho idea di quale sia l'IPC di cinebench ad esempio) e con multithreading spinto... Due processi con IPC 2.4 sicuramente con le porte di INTEL ci vanno stretti... Sulle porte AMD ci vanno larghi... Anche se le unità INTEL sono a 256 bit, quindi in caso di AVX2 si potrebbe pareggiare...
Vedi sopra la mia risposta a tuttodigitale.

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

[bjt2]

... qualche novità qui ? (https://youtu.be/x2EruMTGbiU)

http://forums.anandtech.com/showpost.php?p=38350842&postcount=2166

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

[bjt2]

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

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

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

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

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

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

[cdimauro]

Per l'alta latenza non ci avevo fatto caso... Se ti riferisci a BD, potrebbe anche essere dovuta al fatto che ha un FO4 basso e quindi molti stadi...
No, finora ho confrontato Steamroller (perché di Excavator non ho informazioni, ma comunque è sostanzialmente identico per i discorsi che stiamo facendo) e Haswell (ma Broadwell funziona all'incirca allo stesso modo).
Per quanto riguarda le uops "issuabili": a quanto ho capito in AMD le AGU sono attaccate alle unità di L/S, quindi una MOP viene al più splittata in 2 pezzi: ALU e AGU+MEM.
Confermo. Lo scheduler (per gli interi) può accettare al massimo 2 MOP, e una MOP viene divisa in 1 o 2 uop. Non esiste nessuna MOP che venga divisa in 3 uop (anche per l'FPU).

Quindi è simile ad Intel (1 fused-uop = 2 uop).
Ovviamente se il dato deve essere letto da memoria, l'operazione non può partire subito, viceversa se il dato deve essere scritto, l'operazione ALU può partire e viene ritirata quando il dato è stato calcolato e scritto... E una uop mem può anche essere Read/Modify/Write...
Sì, ed è in quest'ultimo caso che la latenza risulta elevata. Finché dalla memoria si legge non ci sono problemi, ma non appena diventa sorgente e destinazione, si aggiungono almeno 6 cicli di clock.
Comunque l'alta latenza non è poi tanto disastrosa. Quello che conta è il numero di decoder occupati, perchè spesso si è limitati da questo... AMD da tempo fa il fetch di 32 bytes alla volta e INTEL fino a qualche generazioni fa era a 16. ora hanno recuperato... Quindi il collo di bottiglia era il decoding. Per INTEL non era tanto grave, perchè tanto con codice non ottimizzato, spesso non si raggiungeva il limite teorico delle 4-1-1-1 uop in decodifica, quindi i 16 bytes/ciclo non erano quasi mai un problema, ma con la uop fusion e altri miglioramenti, immagino che quella iniziava a essere una limitazione pesante...
In realtà ho visto che perfino Skylake continua ad avere il limite di 16 byte/ciclo per il fetch, e il decoder può decodificare al massimo 4 istruzioni per ciclo (e non 6 come pensavo). Come le precedenti microarchitetture, insomma. Le modifiche introdotte in Skylake riguardano altre cose.

E' soltanto AMD che ha avuto il bisogno di eseguire il fetch di 32 byte/ciclo, divisi in 16 byte/ciclo per ogni thread hardware.
Ad ogni modo AMD con le sue MOP molto potenti, può spesso decodificare 4 istruzioni per ciclo... O anche 2, vista la genialata delle fastpath double...
Il fastpath double è necessario perché le istruzioni vettoriali a 256 bit vengono suddivise in 2 MOP per poter essere eseguite.

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

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

E' in quest'ultimo caso che c'è un vantaggio rispetto ai processori Intel, perché questi ultimi richiedono 2 fused-uop (e quindi generano 2+2 uop; mentre AMD soltanto 2), ma al prezzo di una maggiore latenza (almeno 1 ciclo di clock).
Invece, almeno fino a qualche generazione fa, INTEL appena incontrava una istruzione con più di 1 uop, doveva passare al microcodice, scendendo a una istruzione/ciclo in decodifica, contro le 2 di AMD...
Questo non mi risulta. Sono andato a controllare, e a partire dal PentiumPro è presente il classico schema 4-1-1, mentre a partire dal Core2 c'è il nuovo 4-1-1-1.

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

[bjt2]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[cdimauro]

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

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]

Allora non porta alcun contributo a livello puramente prestazionale.
non porterebbe alcun contributo. Il fatto che oltre checkpoint, non sappiamo altro. Potresti aver ragione. :cool:


:) 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 (http://www.pcworld.com/article/3006268/tablets/tested-why-the-ipad-pro-really-isnt-as-fast-a-laptop.html)

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

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]

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.


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 :D


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/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html
pagina 32

[Ren]

32byte fetch in Bobcat

http://image.slidesharecdn.com/bobcathotchipsfinal8210-110531163511-phpapp01/95/bobcat-hotchips-final-8-2-10-7-728.jpg?cb=1306859804

Decoder e micro-op

http://image.slidesharecdn.com/bobcathotchipsfinal8210-110531163511-phpapp01/95/bobcat-hotchips-final-8-2-10-9-728.jpg?cb=1306859804

[tuttodigitale]

http://forums.anandtech.com/showpost.php?p=38350842&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]

non porterebbe alcun contributo. Il fatto che oltre checkpoint, non sappiamo altro. Potresti aver ragione. :cool:
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? :D
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.
da skylake c'è il 4-1-1-1-1 :D

5 istruzioni per ciclo

http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-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.
32byte fetch in Bobcat

http://image.slidesharecdn.com/bobcathotchipsfinal8210-110531163511-phpapp01/95/bobcat-hotchips-final-8-2-10-7-728.jpg?cb=1306859804

Decoder e micro-op

http://image.slidesharecdn.com/bobcathotchipsfinal8210-110531163511-phpapp01/95/bobcat-hotchips-final-8-2-10-9-728.jpg?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]

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

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

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

http://techreport.com/r.x/centrino-atom/instruction-type-mix.gif
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]

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]

SI... :D 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. :D

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.
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. ;)
http://techreport.com/r.x/centrino-atom/instruction-type-mix.gif
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. :D
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 :D).

Dunque ho anch'io i miei (forti) dubbi, ma sulle affermazioni di AnandTech.
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! :D

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]

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/the-apple-iphone-6s-and-iphone-6s-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]

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:eek: ) ?

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]

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? :D Paura? :sofico:
Per quanto mi sforzi mi pare un poco improbabile che AMD non sia in grado di fare molto meglio di Apple :read:

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 :D (c'è di mezzo anche il fatto che 9 volte su 10, non vengono customizzate)

[tuttodigitale]

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

[george_p]

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

Ma K12 non doveva uscire prima di Zen?

La K di Keller presumo, e il 12 è l'anno del suo ritorno in amd :D

[tuttodigitale]

Ma K12 non doveva uscire prima di Zen?
esattamente. Inizialmente doveva uscire k12 il q4 2016 e ZEN nel 2017. Per entrambi i progetti il primo tape-out risale a un anno fa.


La K di Keller presumo, e il 12 è l'anno del suo ritorno in amd :D
io sono tra quelli che pensa che l'arrivo di keller, che dal 2004 è nel mondo ARM, seppur orientato al low-power, abbia molto a che vedere con k12.:cool:

la K ha caratterizzato per moltissimi anni le cpu di AMD....e sono andate tutte piuttosto bene...scaramanzia? (hanno targato ZEN 32 core Naples, per coerenza ci sta :ciapet: )

[george_p]

esattamente. Inizialmente doveva uscire k12 il q4 2016 e ZEN nel 2017. Per entrambi i progetti il primo tape-out risale a un anno fa.


io sono tra quelli che pensa che l'arrivo di keller, che dal 2004 è nel mondo ARM, seppur orientato al low-power, abbia molto a che vedere con k12.:cool:

la K ha caratterizzato per moltissimi anni le cpu di AMD....e sono andate tutte piuttosto bene...scaramanzia? (hanno targato ZEN 32 core Naples, per coerenza ci sta :ciapet: )

Ma la K torna solo con arm e non con processori X86 (o sto confondendo con SkyBridge?), in Zen Naples sarebbe coerente con cosa? Mi sfugge...

[Phopho]

forse un ritorno ai nomi delle città per il core come con i mitici Athlon 64 X2?

[capitan_crasy]

Ma la K torna solo con arm e non con processori X86 (o sto confondendo con SkyBridge?), in Zen Naples sarebbe coerente con cosa? Mi sfugge...

La lettera K è la sigla che indica i processori AMD da tempi immemori, dal K10 però era una cosa più per gli addetti ai lavori che per le grandi masse.
K8 erano gli AMD64, K10 erano i processori della famiglia Stars, K15 sono i Bulldozer e ZEN avrà la sigla K17.

[george_p]

La lettera K è la sigla che indica i processori AMD da tempi immemori, dal K10 però era una cosa più per gli addetti ai lavori che per le grandi masse.
K8 erano gli AMD64, K10 erano i processori della famiglia Stars, K15 sono i Bulldozer e ZEN avrà la sigla K17.

Ahhh vedi che non ci ha mai lasciati Keller :sofico:

[cdimauro]

l'acquisizione per soli 300 milioni di euro dovrebbe far riflettere sul differente know-how tra PASemi ed AMD.
I soldi non sono né l'unico parametro né sono determinanti per lo sviluppo di un progetto.

La storia di NexGen mi sembra sia piuttosto eloquente. :read:
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? :D Paura? :sofico:
E di cosa? Quel link non l'ho certo portato per caso. :sborone:
Per quanto mi sforzi mi pare un poco improbabile che AMD non sia in grado di fare molto meglio di Apple :read:
Al momento è Apple che ha dimostrato di fare meglio di tutte le aziende che da anni competono in ambito ARM, e che sono di qualche ordine di grandezza più grandi di AMD.

Ed è anche l'unica che ha presentato un design realmente innovativo, che non ha nulla a che spartire con quello degli altri, che sono derivazioni dirette dei core "stock" sviluppati da ARM.

:read: :read: :read:

L'unica eccezione è rappresentata da nVidia, che col suo Project Denver ha però scelto una strada molto diversa (anche perché quella x86 le era preclusa in partenza causa mancanza di licenze, per cui è stata costretta a dirottare su ARM).
Sui sintetici di quel tipo, ho sempre espresso le mie perplessità...finchè non si capisce bene cosa faccia sembrano davvero inutili, e fuorvianti...
Sui sintetici sono d'accordo anch'io, ed è per questo che sono contrario a robaccia come Geekbench, o Dhrystone, ecc.

Ma quelli utilizzati nel link sono per lo più non sintetici: fanno uso di applicazioni reali, simulando dei carichi di lavoro (come riportato anche nei documenti).

Dunque sono di gran lunga più attendibili.
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 :D (c'è di mezzo anche il fatto che 9 volte su 10, non vengono customizzate)
Appunto per questo non vedo di cosa dovrei aver paura. :sborone:
jim keller era il vice presidente del PASemi, ed è stato per 4 anni...
Come vedi, anche una piccola azienda può possedere un know-how di tutto rispetto. ;)
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 :cool: ).
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...)
O che le risorse non erano sufficienti per portare avanti entrambi i progetti. :O
esattamente. Inizialmente doveva uscire k12 il q4 2016 e ZEN nel 2017. Per entrambi i progetti il primo tape-out risale a un anno fa.

io sono tra quelli che pensa che l'arrivo di keller, che dal 2004 è nel mondo ARM, seppur orientato al low-power, abbia molto a che vedere con k12.:cool:
AMD aveva assolutamente bisogno di rilanciarsi in ambito x86, e questo penso sia pacifico.

Ma IMO sarà stato lui, una volta tornato a lavorare lì, a suggerire ad AMD di investire anche su ARM.

@paolo.oliva2: in estrema sintesi, le discussioni basate su numeri avulse dal contesto lasciano il tempo che trovano, perché poi nel mondo reale le CPU macinano algoritmi costituiti da una certa mistura di istruzioni, per cui le prestazioni nel mondo reale possono essere molto diverse da quelle che si potrebbe aspettare guardando soltanto qualche freddo dato.

[paolo.oliva2]

Secondo me Keller é ritornato nel momento in cui si prospettava per AMD la disponibilità di un nuovo silicio, prima era perfettamente inutile, perché l"efficienza architetturale (accorpando Keller ad un miglioramento prestazioni/consumo), qualsiasi sia, non può nulla rispetto a 2 o più nodi di differenza. Viceversa, il risparmio di Watt a die a parità di transistor nel passaggio dal 28nm al 14nm è enorme (praticamente un raddoppio dei core e più a parità di Watt) ed ancor più rispetto al 32nm SOI.

[george_p]

Secondo me Keller é ritornato nel momento in cui si prospettava per AMD la disponibilità di un nuovo silicio, prima era perfettamente inutile, perché l"efficienza architetturale (accorpando Keller ad un miglioramento prestazioni/consumo), qualsiasi sia, non può nulla rispetto a 2 o più nodi di differenza. Viceversa, il risparmio di Watt a die a parità di transistor nel passaggio dal 28nm al 14nm è enorme (praticamente un raddoppio dei core e più a parità di Watt) ed ancor più rispetto al 32nm SOI.

Naturalmente sono nessuno per dire cose di cui non ho mai visto ne sentito di persona ma... un bel grosso ma ce lo metto ...Keller è tornato in amd nel 2012, nemmeno un anno dal debutto di BD e della calciorotazione di Meyer.

Penso sia stata AMD a chiamarlo ma magari anche no.

Fatto sta che Keller serviva prima di tutto per dirigere un team in fase di progettazione, non è che appena un silicio risulta idoneo in azienda si impegnano a cercare ingegneri... per aspettare poi quanto con la fase di progettazione prima e quella di testing sul silicio poi?? Anni e perdere l'occasione di piazzare subito un buon prodotto su silicio adeguato?
avere invece pronti svariati progetti quando il silicio è idoneo è molto più conveniente.

[Phopho]

sono 2 soluzioni rischiose... bisogna vedere quale lo è meno.
se aspetti un buon silicio per progettarci sopra è possibile arrivare in ritardo al lancio del prodotto.
se progetti in attesa di un buon silicio rischi invece di investire un sacco di soldi senza avere la prospettiva di ritorno dell'investimento.
in teoria una via di mezzo sarebbe la cosa più sensata e forse è anche ciò che ha fatto AMD visto che non aveva mezzi finanziari della madonna per supportare un R&D senza avere prospettive concrete.