[Thread Ufficiale] Aspettando ZEN

[Free Gordon]

Originariamente inviato da digieffe

in base ai grafici con dei conti un po' accurati
per pareggiare serve
freq. base 3.4-3.5
turbo all core 3.7
turbo single core 3.9

Imho con un PP più raffinato (speriamo in GF ), ce la possono anche fare a prendere quei clock in 100W.

Sarebbe davvero bono..........

[paolo.oliva2]

Originariamente inviato da digieffe

in base ai grafici con dei conti un po' accurati
per pareggiare serve
freq. base 3.4-3.5
turbo all core 3.7
turbo single core 3.9

Io intando prendo per buono che in OC RS/DU Zen a @3,9GHz ci dovrebbe stare, e questo non mi sembra poco.

Per il fatto che mi sembra si era esposto -5/-10% in MT, ammesso e concesso che i bench siano veritieri, a Zen basterebbe un +5/+10% di clock.

Ora... sull'X4 mi sembra remota la cosa, ma su X8 vs 6900K, ci siamo, perchè a quei clock Zen avrebbe +9% di clock def, il turbo tutti i core non lo considero perchè bisognerebbe sapere il funzionamento, e 3,9GHz di frequenza massima sarebbe un +6% rispetto ai 3,7GHz massimi del 6900K... Cioè, Zen sarebbe alla pari al 6900K, non certo verso il 6850K.

[shellx]

Originariamente inviato da Roland74Fun

Ma di cosa state a parlare?
Avranno rilevanza per il pubblico queste cose?

Proprio oggi all'ora di pranzo sul pullman per tornare dal lavoro, vicino a me parlavano due ragazzotti di seconda o terza superiore.
Uno ha detto:
"Il ragazzo di mia sorella si è preso in offerta al madiawalk un PC i7, e c'ha pure la scheda GT! ora tutti i giochi gli vanno appalla!!!"
E'altro.
"Secondo me ha sbagliato. Ho letto su internet che stanno per uscire dei nuovi computer dei cinesi, mi pare si chiamino ZED o forse... ZEN, che dovrebbero andare al doppio dell'i7 e costare la metà!"....

Ecco il livello!
E voi state a farvi le pippe sul soi e sul bulk.....

E non potevi intervenire con un: "ehm scusate, siete due bimbi ignorantelli, approfondite prima cosa è amd e cosa intel in caso contrario compratevi una playstation (dove dentro c'è processore amd quello che voi chiamate cinese)" E te ne andavi con aria soddisfatta di aver umiliato e rovinato la giornata a due ragazzini.

[digieffe]

Originariamente inviato da paolo.oliva2

Io intando prendo per buono che in OC RS/DU Zen a @3,9GHz ci dovrebbe stare, e questo non mi sembra poco.

Per il fatto che mi sembra si era esposto -5/-10% in MT, ammesso e concesso che i bench siano veritieri, a Zen basterebbe un +5/+10% di clock.

Ora... sull'X4 mi sembra remota la cosa, ma su X8 vs 6900K, ci siamo, perchè a quei clock Zen avrebbe +9% di clock def, il turbo tutti i core non lo considero perchè bisognerebbe sapere il funzionamento, e 3,9GHz di frequenza massima sarebbe un +6% rispetto ai 3,7GHz massimi del 6900K... Cioè, Zen sarebbe alla pari al 6900K, non certo verso il 6850K.

se fossero veritieri, siamo più a -10% (probabilmente -13% in alcuni ambiti) che a -5%. Quindi il +10% di frequenza servirà tutto, ammesso che ci sarà.

ho fatto considerazioni un po' diverse: ritengo il turbo all core la cosa più importante, in quanto, il 6900k gira praticamente sempre tra i 3.4 ed i 3.5 su tutti i core (escluso carichi particolari). Ne consegue, quindi, che Zen dovrà necessariamente girare a 3.7 su tutti i core con la maggiorparte dei carichi, altrimenti sarà ben sotto.

in base ai dati esposti, non trovo giusto paragonare le freq. di zen a quelle del 6900k ma solo allo stesso ES di zen. Cioè 3.5 vs 3.150 base, 3.7 vs 3.3 turbo all core, 3.9 vs 3.5 turbo single core, in media hai un +~10% ad ogni binning

[digieffe]

intel sostituirà l'architettura core?

Even Intel is studying a new x86 uArch. clicca qui

[stefanonweb]

Intanto ziobepi:

Originariamente inviato da ziobepi

Segnalo anche l'uscita dei primi bench gaming per Zen.
http://www.overclock.net/t/1619110/c...zen-benchmarks
In perfetto accordo con le mie previsioni direi.

Spero di resistere alla tentazione 7700K,
per riuscirci devo convincermi di aspettare la piattaforma -x

[Pozhar]

Originariamente inviato da stefanonweb

Intanto ziobepi:

Deve ringraziare la moderazione lassista, perché se era per me già l'avevo bannato da tempo.

[capitan_crasy]

Originariamente inviato da Pozhar

Deve ringraziare la moderazione lassista, perché se era per me già l'avevo bannato da tempo.

Il problema è che questo cialtrone è già stato bannato molte volte su questo forum; quel nick è solo l'ennesimo clone...

[Gioz]

Originariamente inviato da Pozhar

Deve ringraziare la moderazione lassista, perché se era per me già l'avevo bannato da tempo.

quando tornerà attivo gianni1879 probabilmente si troverà 1 miliardo di segnalazioni

[digieffe]

Originariamente inviato da capitan_crasy

Il problema è che questo cialtrone è già stato bannato molte volte su questo forum; quel nick è solo l'ennesimo clone...

giusto per curiosità come li riconoscete?

[paolo.oliva2]

Originariamente inviato da digieffe

intel sostituirà l'architettura core?

Even Intel is studying a new x86 uArch. clicca qui

Fa prima AMD a fare la prox architettura post Zen.

This new uArch will be ready in 2019-2020.

Non ho capito sta frase...

The next Intel uArch will be very similar to the approach used by AMD with Zen – perfect balance of power consumption/performance/price – quindi danno per buoni i rumors dei prezzi? Perchè non c'è null'altro sui prezzi...

[bjt2]

Originariamente inviato da capitan_crasy

Il problema è che questo cialtrone è già stato bannato molte volte su questo forum; quel nick è solo l'ennesimo clone...

E da quanto dura sto clone? Saranno almeno un paio di anni che lo sento nominare...

[sgrinfia]

Originariamente inviato da shellx

E non potevi intervenire con un: "ehm scusate, siete due bimbi ignorantelli, approfondite prima cosa è amd e cosa intel in caso contrario compratevi una playstation (dove dentro c'è processore amd quello che voi chiamate cinese)" E te ne andavi con aria soddisfatta di aver umiliato e rovinato la giornata a due ragazzini.

E perché mai doveva farlo ?, nel ignoranza si vive meglio

[cdimauro]

Originariamente inviato da Veradun

Niente più che rumors/speculazioni del tutto non confermate. E il fatto che entro fine anno vogliano presentare Raven Ridge mi fa pensare che un design nativo 4c sia quello da inserire nel progetto APU, non da proporre come CPU, anche perché vorrebbe dire fare una sovrapposizione di prodotto francamente del tutto inutile.

Quindi il design 4c ci sarebbe, ma riservato alle APU. Makes sense: AMD non ha molte risorse per sviluppare tanti progetti.

E d'altra parte mi pare che tutti i processori Intel da 4 o meno core integrino una GPU (ma non mi va di controllarli uno per uno ).

Originariamente inviato da paolo.oliva2

Io penso una cosa... che Intel ha vinto per un semplice motivo... perchè quando ha saputo che AMD vendeva le FAB, ha investito sul silicio.

Paolo, ancora? Ma perché ti devi inventare cose di sana pianta?

Intel investe sul silicio da quand'è nata!!!

Io concordo al 1000000% che BD abbia contribuito a perdere nella potenza ST rispetto a qualsiasi altra architettura al suo posto, ma dobbiamo pure considerare che la massima potenza ST Intel l'ha grazie ai suoi core, indubbiamente, ma grazie al silicio ha consentito alla sua architettura di annullare le frequenze superiori di BD, e questo per certo ha contribuito ad aumentarla e far risaltare ancor più la pecca di BD.

Sandy Bridge era a 32 nm, come BD.
Il 2600K era a 3,4Ghz di base e 3,8Ghz di Turbo. 4C/8T (SMT). In 95W.
L'FX-8150 era a 3,6Ghz di base e 4,2Ghz di Turbo. 4C/8T (CMT). In 125W.
Ecco i test: il confronto fra i due, in diversi casi, mi pare impietoso, e non è certo questione di frequenze, ma soprattutto di efficienza, e qui il il silicio c'entra ben poco.

Originariamente inviato da bjt2

Buono a sapersi. Avevo pensato che fossero microcodificate sia perchè l'algoritmo è iterativo e al massimo si sentiva dire che era di tipo radix 16 (4 bit alla volta), sia perchè spesso non sono pipelined e bloccano la pipe per tutto il tempo di esecuzione... Meglio così... Si spera che prima o poi qualcuno le faccia fully pipelined (se sai qualcosa, ogni informazione è benvenuta... ).

Ormai sono fuori.

BTW sembra che quelli di instxlat64 abbiano zen, perchè hanno fatto prove con AIDA per calcolare le latenze e dicono che sono tutte sbagliate quelle che avevano ipotizzato dalle patch di gcc... In arrivo il chart aggiornato: https://twitter.com/InstLatX64/statu...40863748685824 versione 1.5 con la colonna di Zen lasciata intenzionalmente bianca: https://twitter.com/InstLatX64/statu...00676373032966

Visto. Devono rifare i conti. Ma a questo punto se le patch di GCC sono sbagliate, i binari che verranno fuori non saranno ben ottimizzati per Zen.

Solo che non capisco perché si ostinino a riportare differenze fra ALU a 32 e 64 bit per i processori Intel: sia il manuale di Agner sia quello di Intel riportano informazioni ben diverse, e nessuna differenza fra 32 e 64 bit (per lo meno per le operazioni "intere" più comuni).

https://youtu.be/Ln9WKPEHm4w?t=17m56s Forse è troppo ad alto livello, ma in Zen tra il mux e la uop queue c'è lo stack memfile che filtra le operazioni e la microcode rom che invece le espande. Da questo diagramma invece sembra che l'architettura intel sia piuttosto standard e la microcode rom potrebbe stare vicino o subito dopo i decoder...

Se prendi il manuale delle ottimizzazioni di Intel, c'è lo schema di Skylake che mostra come la micro-op queue riceva uop da: decoder, uROM, e uop cache. Come Zen.

Chiaro che Zen ha pure lo stack mem in mezzo, ma in linea di massima fanno esattamente le stesse cose.

Può anche darsi che il tizio si sia espresso male.

E' quel che penso.

In bocca al lupo per il tuo lavoro... Di cuore...

Grazie!

E' anche il mio sogno, di progettare una CPU, ci penso spesso... Ti auguro di realizzarlo...

Se hai esperienza con RTL / VHDL / Verilog e hai già implementato qualche architettura, potremmo "fare comitiva", come si dice dalle mie parti.

Della mia architettura ho già definito in maniera precisa l'ISA e la relativa opcode table. Ovviamente non serve implementare tutto in una volta (c'è troppa carne al fuoco), ma si può partire da un subset minimale, per poi espanderlo.

L'ho realizzata in modo che certe parti (FPU, MMX, SSE, AVX 1&2/AVX-512/AVX-1024 ) si possano inserire o rimuovere molto facilmente. Idem per la modalità a 32 o 64 bit, e anche i vari register set sono scalabili a piacere (16 o 32 GPR; 16/32/64/128 VecR; 0/8/16 MaskR). Diverse altre cose (istruzioni) sono organizzate in gruppi che si possono aggiungere o rimuovere; fra queste c'è il legacy (segmentazione, address size, tutte le vecchie istruzioni x86), che è confinato in precise zone. E infine le numerose modalità d'indirizzamento hanno una certa regolarità / semplicità, e si possono aggiungere o togliere a piacere.

Anche io ho parecchie idee e una in particolare AMD finalmente l'ha realizzata, anche se in "scala ridotta". Sto parlando del PTE coalescing... In Zen 8 pagine contigue possono essere memorizzate in una sola TLB entry di pagina 4k, senza intervento del SO (ovviamente in memoria la page table non cambia). Io avevo pensato a una cosa senza limiti, ma 2 registri con pagina iniziale e finale in modo che il range potesse essere illimitato... Ma già una compressione 8:1 è notevole...

Credo che l'ISA proposta lo scorso anno da Agner Fog abbia qualcosa di simile, visto che non utilizza la paginazione, ma implementa una sorta di segmentazione dello spazio d'indirizzamento (virtuale), in modo da evitare di usare la TLB a priori.

Se vuoi dargli un'occhiata, trovi tutto qui: ForwardCom

In particolare, dall'abstract su Efficient memory management:

"he number of memory sections that a running process or thread has access to is so small that it all can be contained in a memory map inside the CPU chip. This is very different from most common systems that have very large page tables. A large page table requires fixed-size memory pages in order to make table lookup simple. But if we can keep the number of table entries small then it is feasible to have variable-size table entries. The ForwardCom design has the goal of keeping all code or data that a process has access to contiguous and to avoid memory fragmentation as much as possible. This makes it possible to replace the huge multi-level page tables and translation-lookaside-buffers of current systems with a small on-chip memory map."

Ma STM non è stata acquisita e non è più italiana?

No, è ancora italiana. Ma ha diversi investitori che ne posseggono le azioni, e la controllano.

Che io sappia blender non fa schedulazione sulla CPu, quindi il codice dovrebbe essere lo stesso...

OK, quindi codice generico per qualunque processore.

Originariamente inviato da bjt2

Sono andato a scorrere il pdf di agner fog, alla sezione AMD più nuova (Steamroller).http://www.agner.org/optimize/instruction_tables.pdf

Effettivamente quasi tutte le DIV hanno 1 o 2 MOP, tranne la 8 e 16 bit che quindi è microcodificata. Le SQRT hanno più di 2 mop quindi anche queste lo sono.

No, hanno al massimo 2MOP. Controlla bene.

Alcune routine di push e pop (per i flag) che dovrebbero essere usate in tutte le ISR sono microcodificate, ma qui, ovviamente sono usate pochissimo, perchè le interruzioni non sono poi così frequenti.

In realtà i flag sono automaticamente conservati quando una ISR viene chiamata. Per cui non si devono salvare e ripristinare.

Comunque AMD richiede troppe MOP & cicli di clock per PUSHF/POPF/LAHF/SAHF. Intel è messa di gran lunga meglio, e non usa microcodice, a parte per la POPF (per ovvie ragioni), che comunque richiede di gran lunga meno uop rispetto ad AMD.

Ci siamo scordati tre classi di istruzioni che possono non essere così rare e che sono microcodificate: le istruzioni di locking (per tutti i semafori, quindi usate spesso nel SO ma anche in codice utente, se multitasking/threading), le istruzioni di crittografia, usate spesso nei software a cui serve (quindi penso a VPN, driver del file system nel caso sia criptato, browser quando si usa l'https) e le istruzioni stringa. Se supponiamo che memcpy sia implementato con REP MOVxx, allora potrebbe essere anche usata spesso. E avere in uop cache solo il placeholder alla routine potrebbe essere vantaggioso...

C'è da dire che Intel è messa molto meglio di AMD per quanto riguarda crittografia e REPs.

Soltanto in quest'ultimo caso vengono generate diverse uop, ma sono decisamente poche, e specialmente se i dati sono allineati in memoria.

Comunque riguardo a REP e lock, bisogna anche considerare quanto verranno utilizzate in loop.
Nel primo caso ben poco, perché in genere trasferisci (o riempi) zone di memoria, e vai avanti col codice. Dunque "cachare" le uop non ha senso.

I lock in genere si trovano in mezzo a loop, ma il loop è piccolo e con la finalità di aggiudicarsi la risorsa. Una volta che la risorsa è stata presa, non torni nuovamente in quel loop, ma continui con la sezione critica che farà tutt'altro..
Quindi in questo caso la uop cache viene usata pochissimo, e poi non serve più.

Questo per sottolineare come non si possa pensare "sui massimi sistemi", tenendo conto della feature di per sé, ma bisogna calare sempre il tutto nel mondo reale, e vedere in che modo funzionano le cose, e in che modo / misura possa incidere una particolare feature.

Originariamente inviato da Grizlod®

Sembra abbiano un sample di quelli apparsi su Geekbench 4 quest'estate (quindi non ultimissima revisione).
Dal grafico (interpretazione personale) sembra sia sprovvisto di AVX 512, in quanto hanno messo un trattino (-), tanto come in µop-cache ed L3 size per Excavator e Bristol Ridge, non lasciando il campo in blanc.

Si sa già che Zen non avrà le AVX-512. Come non le ha Skylake, se non in versione server.

Già adesso deve suddividere le istruzioni AVX a 256 bit in 2 parti a 128 bit per eseguirle nelle sue FPU a 128 bit, che non è certo il massimo.

Potrebbe anche fare lo stesso con la AVX-512, spezzandolo in 4 parti a 128 bit, ma non è certo molto efficiente. E comunque non basterebbe, perché le AVX-512 richiedono diverse altre cose per il loro funzionamento (registri di maschera, e supporto per il mascheramento delle lane per l'appunto. Compressed offset a 8 bit. E credo ci sia altra roba), complicando l'implementazione.

Originariamente inviato da digieffe

in base ai dati esposti, non trovo giusto paragonare le freq. di zen a quelle del 6900k ma solo allo stesso ES di zen. Cioè 3.5 vs 3.150 base, 3.7 vs 3.3 turbo all core, 3.9 vs 3.5 turbo single core, in media hai un +~10% ad ogni binning

Il 6900K ha 3,2Ghz di base, che è simile al 3,15 di Zen. SE questo leak risultasse vero, ovviamente.

Originariamente inviato da digieffe

intel sostituirà l'architettura core?

Even Intel is studying a new x86 uArch. clicca qui

Non so se la sostituirà, con qualcosa di ridisegnato da zero.

Eliminare parti dell'ISA è già possibile, ma finora non l'ha mai fatto. Col codice a 64 bit che è ormai molto diffuso, e che usa quasi sempre le SSE2 (che sono il requisito minimo per x64), l'FPU x87 non è quasi mai utilizzata. Inoltre non ho mai trovato codice MMX (ma non ho disassemblato molte applicazioni: solo alcune molto comuni).

Per cui rimuovere MMX ed FPU x86, specialmente fra 3-4 anni, potrebbe essere fattibile.

[bjt2]

Originariamente inviato da paolo.oliva2

Fa prima AMD a fare la prox architettura post Zen.

This new uArch will be ready in 2019-2020.

Non ho capito sta frase...

The next Intel uArch will be very similar to the approach used by AMD with Zen – perfect balance of power consumption/performance/price – quindi danno per buoni i rumors dei prezzi? Perchè non c'è null'altro sui prezzi...

Beh, se la prima infornata avrà 3.5-3.6 base, metti le seconde infornate, metti il 14nmHP, metti il 7nm GF, metti Zen+ con ulteriori migliorie e l'SMT4, hai voglia a strada che deve fare INTEL per recuperare... Prevedo che già sul 14nm si arrivi a superare i 4GHz base (magari solo sull'HP) e sul 7nm qualcosina in più... Poi un po' di IPC in più con zen+

[george_p]

Originariamente inviato da tuttodigitale

francamente questa non la capisco....
i core bulldozer sono come k10 piccoli molto piccoli, la metà di SB, oltre ad avere le pipeline più lunghe....c'è un motivo se AMD aveva dei quad core SR (KAVERI) da 2,1GHz base 19W vs dual core SB da 1,8GHz 17W....la "sfortuna" di AMD è che il 28nm bulk è nato quando Intel era già da tempo sui finfet...processo che ha permesso di guadagnare un ulteriore 30-40% di efficienza ad Intel..

il fatto che AMD non sia passato interamente alla produzione sul bulk potrebbe essere legata ai motivi contrattuali con GF (avevo letto qualcosa su bitsandchips)

Scusa ma nemmeno io capisco la tua risposta al quote del mio post.

[bjt2]

Originariamente inviato da cdimauro

Ormai sono fuori.

Beh, a memoria, ho ricordi vaghi che le unità non erano fully pipelined. Ora mi ricordo che basta vedere le tabelle del PDF di Agner Fog e guardare la colonna del 1/throughput. Se è dello stesso ordine di grandezza della latenza (o qualche ciclo meno) allora non è pipelined, perchè vuol dire che deve terminare tutta l'esecuzione prima di poterne fare un'altra (e ovviamente blocca tutta la pipeline)

Originariamente inviato da cdimauro

Visto. Devono rifare i conti. Ma a questo punto se le patch di GCC sono sbagliate, i binari che verranno fuori non saranno ben ottimizzati per Zen.

Beh, penso che una volta pubblicate le informazioni di instlat86, tempo un paio di giorni e ci sarà la nuova patch...

Originariamente inviato da cdimauro

Solo che non capisco perché si ostinino a riportare differenze fra ALU a 32 e 64 bit per i processori Intel: sia il manuale di Agner sia quello di Intel riportano informazioni ben diverse, e nessuna differenza fra 32 e 64 bit (per lo meno per le operazioni "intere" più comuni).

Penso che sia per un fatto di uniformità: nel manuale di Fog ci sono tante CPU, comprese low power, knight xxx, mi pare anche il pentium 4 e magari per loro la distinzione ha senso.

Originariamente inviato da cdimauro

Se prendi il manuale delle ottimizzazioni di Intel, c'è lo schema di Skylake che mostra come la micro-op queue riceva uop da: decoder, uROM, e uop cache. Come Zen.

Chiaro che Zen ha pure lo stack mem in mezzo, ma in linea di massima fanno esattamente le stesse cose.

Ok, credo che anche quella gif che postai giorni fa dica lo stesso. ovviamente i documenti ufficiali fanno ancora più testo

Originariamente inviato da cdimauro

Se hai esperienza con RTL / VHDL / Verilog e hai già implementato qualche architettura, potremmo "fare comitiva", come si dice dalle mie parti.

VHDL l'ho studiato all'università (e anche il dimensionamento dei MOS), ma non ricordo granchè...

Originariamente inviato da cdimauro

Della mia architettura ho già definito in maniera precisa l'ISA e la relativa opcode table. Ovviamente non serve implementare tutto in una volta (c'è troppa carne al fuoco), ma si può partire da un subset minimale, per poi espanderlo.

L'ho realizzata in modo che certe parti (FPU, MMX, SSE, AVX 1&2/AVX-512/AVX-1024 ) si possano inserire o rimuovere molto facilmente. Idem per la modalità a 32 o 64 bit, e anche i vari register set sono scalabili a piacere (16 o 32 GPR; 16/32/64/128 VecR; 0/8/16 MaskR). Diverse altre cose (istruzioni) sono organizzate in gruppi che si possono aggiungere o rimuovere; fra queste c'è il legacy (segmentazione, address size, tutte le vecchie istruzioni x86), che è confinato in precise zone. E infine le numerose modalità d'indirizzamento hanno una certa regolarità / semplicità, e si possono aggiungere o togliere a piacere.

Ma è una specie di subset/superset di x86? Le mie elugubrazioni erano più per una CISC (ovviamente con motore RISC) completamente ortogonale dove ogni operando aveva il tipo annesso ed erano automaticamente emesse le uop di conversione se il tipo dei vari operandi era diverso. Istruzioni a 0-4 operandi, dove ogni operando aveva campi di bit per tipo, modo indirizzamento e dati, avevo anche calcolato i bit ecc...

Originariamente inviato da cdimauro

Credo che l'ISA proposta lo scorso anno da Agner Fog abbia qualcosa di simile, visto che non utilizza la paginazione, ma implementa una sorta di segmentazione dello spazio d'indirizzamento (virtuale), in modo da evitare di usare la TLB a priori.

Se vuoi dargli un'occhiata, trovi tutto qui: ForwardCom

In particolare, dall'abstract su Efficient memory management:

"he number of memory sections that a running process or thread has access to is so small that it all can be contained in a memory map inside the CPU chip. This is very different from most common systems that have very large page tables. A large page table requires fixed-size memory pages in order to make table lookup simple. But if we can keep the number of table entries small then it is feasible to have variable-size table entries. The ForwardCom design has the goal of keeping all code or data that a process has access to contiguous and to avoid memory fragmentation as much as possible. This makes it possible to replace the huge multi-level page tables and translation-lookaside-buffers of current systems with a small on-chip memory map."

Già dall'abstract vedo che mi ha copiato l'indirizzamento... Anche a me è sempre stata antipatica la paginazione e pensavo di dividere in range lo spazio, il tutto da mettere in registri interni del processore... La PTE coalescing è l'adattamento della mia idea alla paginazione, senza modificare i SO correnti, quindi con granularità 4KB, ma limite di 8 pagine alla volta...
Suggerirei ad AMD di modificare le TLB in modo da mettere pagina iniziale e finale e quindi non limitarsi a range di 8 pagine...

Originariamente inviato da cdimauro

No, hanno al massimo 2MOP. Controlla bene.

Qualcuna ce n'è:
Ad esempio:
Pag 67:
DIV r8/m8 9 17-22 13-17 EX0
DIV r16/m16 7 15-25 15-25 EX0
IDIV r8/m8 9 17-22 13-17 EX0
IDIV r16/m16 7 14-25 14-24 EX0

9 e 7 MOPs

Pag 68:
Varie istruzioni di shift rotazione (non riesco ad incollare...)

Pag 69-75
Molte istruzioni di mascheramento e floating point...

Originariamente inviato da cdimauro

In realtà i flag sono automaticamente conservati quando una ISR viene chiamata. Per cui non si devono salvare e ripristinare.

Giusto! Sono BOCCIATO!

Originariamente inviato da cdimauro

Comunque AMD richiede troppe MOP & cicli di clock per PUSHF/POPF/LAHF/SAHF. Intel è messa di gran lunga meglio, e non usa microcodice, a parte per la POPF (per ovvie ragioni), che comunque richiede di gran lunga meno uop rispetto ad AMD.

Immagino...

Originariamente inviato da cdimauro

C'è da dire che Intel è messa molto meglio di AMD per quanto riguarda crittografia e REPs.

Soltanto in quest'ultimo caso vengono generate diverse uop, ma sono decisamente poche, e specialmente se i dati sono allineati in memoria.

Beh, se vedi quelle poco efficienti sono le legacy... Ce ne sono altre che hanno una uop per ogni 16 bytes, più un setup... Meglio non si può fare (con bus a 128 bit... Ovviamente intel ha il bus doppio...)

Originariamente inviato da cdimauro

Comunque riguardo a REP e lock, bisogna anche considerare quanto verranno utilizzate in loop.
Nel primo caso ben poco, perché in genere trasferisci (o riempi) zone di memoria, e vai avanti col codice. Dunque "cachare" le uop non ha senso.

I lock in genere si trovano in mezzo a loop, ma il loop è piccolo e con la finalità di aggiudicarsi la risorsa. Una volta che la risorsa è stata presa, non torni nuovamente in quel loop, ma continui con la sezione critica che farà tutt'altro..
Quindi in questo caso la uop cache viene usata pochissimo, e poi non serve più.

Hai ragione. Il contributo è minimo. Ma almeno in AMD non hai uop cache pollution perchè è una sola uop. In INTEL, se non usi questo trucco, quando incontri qualche mostro di questo ti può svuotare parte della cache uop.

Originariamente inviato da cdimauro

Questo per sottolineare come non si possa pensare "sui massimi sistemi", tenendo conto della feature di per sé, ma bisogna calare sempre il tutto nel mondo reale, e vedere in che modo funzionano le cose, e in che modo / misura possa incidere una particolare feature.

Si sa già che Zen non avrà le AVX-512. Come non le ha Skylake, se non in versione server.

Già adesso deve suddividere le istruzioni AVX a 256 bit in 2 parti a 128 bit per eseguirle nelle sue FPU a 128 bit, che non è certo il massimo.

Potrebbe anche fare lo stesso con la AVX-512, spezzandolo in 4 parti a 128 bit, ma non è certo molto efficiente. E comunque non basterebbe, perché le AVX-512 richiedono diverse altre cose per il loro funzionamento (registri di maschera, e supporto per il mascheramento delle lane per l'appunto. Compressed offset a 8 bit. E credo ci sia altra roba), complicando l'implementazione.

Beh, se i 4 decoder possono sparare 4 puntatori alla rom per ciclo, non è che impatta molto: vai di microcodice e via... Forse è per questo che l'hanno fatto questa genialata...

Originariamente inviato da cdimauro

Non so se la sostituirà, con qualcosa di ridisegnato da zero.

Eliminare parti dell'ISA è già possibile, ma finora non l'ha mai fatto. Col codice a 64 bit che è ormai molto diffuso, e che usa quasi sempre le SSE2 (che sono il requisito minimo per x64), l'FPU x87 non è quasi mai utilizzata. Inoltre non ho mai trovato codice MMX (ma non ho disassemblato molte applicazioni: solo alcune molto comuni).

Per cui rimuovere MMX ed FPU x86, specialmente fra 3-4 anni, potrebbe essere fattibile.

Non mi toccare la FPU x87! Già ora 64 bit mi stanno stretti... E anche 80... Power 9 avrà i 128 bit, anche se leggendo il reference manual (si! ho fatto la pazzia di leggerlo tutto! ) per questa versione è tutto o quasi in trap, ossia emulazione software, ma hanno gettato le basi per una futura versione hardware. D'altronde anche gli 80 bit su x87 sono più lenti e sulle CPU di bassa potenza (mi pare ad esempio le bobcat e jaguar) addirittura la denormalizzazione è demandata a routine di microcode ROM...

[Gioz]

Originariamente inviato da bjt2

VHDL l'ho studiato all'università (e anche il dimensionamento dei MOS), ma non ricordo granchè...

quando studiavo io non c'erano neanche i fondi per avere qualcosa in laboratorio, per cui nell'esame di logiche programmabili in cui venne trattato l'argomento ricordo di aver fatto dei progetti con il software di simulazione della xilinx (mi pare simulando la programmazione della spartan 3) incappando in un bug che non c'era modo di verificare fisicamente.
ti auguro di aver avuto modo di studiarlo meglio di quanto abbia potuto fare io qualora potesse/dovesse mai servirti.

[bjt2]

Originariamente inviato da Gioz

quando studiavo io non c'erano neanche i fondi per avere qualcosa in laboratorio, per cui nell'esame di logiche programmabili in cui venne trattato l'argomento ricordo di aver fatto dei progetti con il software di simulazione della xilinx (mi pare simulando la programmazione della spartan 3) incappando in un bug che non c'era modo di verificare fisicamente.
ti auguro di aver avuto modo di studiarlo meglio di quanto abbia potuto fare io qualora potesse/dovesse mai servirti.

Non ricordo il software ma era un simulatore, dove potevi mettere gli oscilloscopi virtuali in vari punti e vedere i segnali ecc...

[tuttodigitale]

Originariamente inviato da bjt2

Le dichiarazioni di AMD sono di un core Zen che consuma quanto un core XV a parità di clock... Poichè un core XV non esiste, possiamo solo dedurre che 2 core zen consumano quanto un XV monomodulo, oppure un CCX Zen consuma quanto 2 moduli XV (quadcore).

la mia chiave di lettura è proprio questa...
consumo::= 2 core ZEN 14nm = 1 Modulo XV 28nm

ma il primo è su finfet...(-35/55% rispetto al 28nm)
2core ZEN = 1 modulo XV +55% (caso -35%) , ovvero sarebbe da paragonare : ZEN x8/16t vs XV 12 core CMT
2 core ZEN = 1 modulo XV +120% (caso -55%), ovvero sarebbe da paragonare : ZEN x8/16t vs XV 18 core CMT

quando paolo.oliva, dice che per misurare il reale beneficio dell'architettura ZEN, a netto dei finfet, bisognerebbe paragonarlo ad un ipotetico XV con lo stesso numero di thread non ha tutti i torti.

Originariamente inviato da bjt2

Zen potrebbe consumare quanto un modulo XV già sul 28nm.

mi pare difficile, assai difficile da credere che ZEN X4 @3GHz possa consumare 35W sui 28nm.

Originariamente inviato da bjt2

Scendendo di 2 nodi e passando al finfet, si guadagna ben più del -50% (metà).

mi sono mantenuto basso....
la verità, può anche non piacere per chi vede il progetto BD nato male ed evoluto peggio, che stando a quanto dichiarato da AMD, ZEN a parità di frequenza, thread e watt migliorerebbe mediamente l'efficienza nel MT del 15% (caso pessimistico -35%), ma potrebbe portare guadagni pari a 0% se non addirittura una leggerissima regressione, se consideriamo che le gpu hanno visto più che dimezzato i consumi a parità di frequenza, di quanto possibile con XV...

in sostanza i progressi resi pubblici fino ad oggi, sembrerebbero praticamente solo merito dei finfet e non di ZEN...."aspettando le prove nel ST"

Originariamente inviato da george_p

Scusa ma nemmeno io capisco la tua risposta al quote del mio post.

dicevi che ZEN dovesse essere molto più efficiente di XV anche sui 28nm, dando la colpa al CMT... i core non sono tutti uguali...non hanno lo stesso consumo (e ahimè neppure le stesse prestazioni)