[Thread Ufficiale] Aspettando ZEN

[tuttodigitale]

Originariamente inviato da cdimauro

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]

Originariamente inviato da bjt2

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.

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.

Originariamente inviato da bjt2

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.

Originariamente inviato da tuttodigitale

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.

Originariamente inviato da tuttodigitale

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]

Originariamente inviato da cdimauro

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!

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Anche CUDA non è male...

Originariamente inviato da cdimauro

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! Daltronde all'ITIS facevo solo il codice x86 intero...

Originariamente inviato da cdimauro

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]

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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]

Originariamente inviato da bjt2

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.

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

Così facile?

Così, per esempio.

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

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

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.

Ecco gli schemi di Bulldozer, PileDriver, Steamroller, ed Excavator (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.

Originariamente inviato da tuttodigitale

esattamente...con lo stesso numero di transistor AMD ha ottenuto 2 core (4ALU + 4 AGU)...e teoricamente (ma anche in pratica ), 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]

Originariamente inviato da cdimauro

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]

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

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

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

Così facile?

Così, 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.

Originariamente inviato da cdimauro

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

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.

Ecco gli schemi di Bulldozer, PileDriver, Steamroller, ed Excavator (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]

Originariamente inviato da cdimauro

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)

Originariamente inviato da cdimauro

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

Originariamente inviato da tuttodigitale

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

Originariamente inviato da paolo.oliva2

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 ), 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]

Originariamente inviato da tuttodigitale

sono inversamente proporzionali...il FO4 dell'architettura determina insieme al gate delay offerto dal silicio ad un determinato vore (in pico-secondi ), 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]

Originariamente inviato da bjt2

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.

[cdimauro]

Originariamente inviato da bjt2

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

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.

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]

Originariamente inviato da tuttodigitale

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

Originariamente inviato da tuttodigitale

sono inversamente proporzionali...il FO4 dell'architettura determina insieme al gate delay offerto dal silicio ad un determinato vore (in pico-secondi ), 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...

[tuttodigitale]

Originariamente inviato da paolo.oliva2

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?

[capitan_crasy]

Originariamente inviato da 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...

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 ) 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 ) in fase di pre-produzione...

[bjt2]

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

Bene. Manca poco allora. Quanta sofferenza.

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

Come mai?

Perchè mischiare int e fp porta problemi nell'SMT

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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