[Thread Ufficiale] Aspettando ZEN

[george_p]

Originariamente inviato da tuttodigitale

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.


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


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"


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)

Più che altro intendo che Zen ha dalla sua un ipc maggiore rispetto a quanto aveva BD appena uscito. Ma soprattutto BD aveva un ipc ben inferiore alla sua precedente.
Quindi, oggi con il silicio adeguato anche se non eccellente possiamo disporre di un buon ipc alla stessa frequenza di thuban e BD, mica noccioline.

Quindi un pò per logica mi viene da pensare che se Zen davvero raggiunge queste frequenze con otto core a 95 w di tdp sul 14 perché non dovrebbe come esacore anche a 125 sul 32 o sul 28nm?

Semplice logica, e visto che tanto speculazione per speculazione.

Poi, gli ingegneri di Zen hanno progettato l'architettura basandosi sui pp più piccoli di 28. Ma ciò che conta è che hanno aumentato di nuovo l'ipc mentre in BD hanno riportato indietro di 4 anni all'epoca.

[Grizlod®]

Originariamente inviato da george_p

Più che altro intendo che Zen ha dalla sua un ipc maggiore rispetto a quanto aveva BD appena uscito. Ma soprattutto BD aveva un ipc ben inferiore alla sua precedente.
Quindi, oggi con il silicio adeguato anche se non eccellente possiamo disporre di un buon ipc alla stessa frequenza di thuban e BD, mica noccioline.

Quindi un pò per logica mi viene da pensare che se Zen davvero raggiunge queste frequenze con otto core a 95 w di tdp sul 14 perché non dovrebbe come esacore anche a 125 sul 32 o sul 28nm?

Semplice logica, e visto che tanto speculazione per speculazione.

Poi, gli ingegneri di Zen hanno progettato l'architettura basandosi sui pp più piccoli di 28. Ma ciò che conta è che hanno aumentato di nuovo l'ipc mentre in BD hanno riportato indietro di 4 anni all'epoca.

Non credo ci sarebbe stato lo stesso quantitativo di L3 e forse neppure l'HW per l'SMT.

Inoltre, maggior area, quindi minor resa sul wafer ed anche problemi a salire in OC.

IMO interessantissima la feature dell' overclock automatico rilevando la temperatura (*), ed in ambito server, se non ricordo male, il minichip ARM di cifratura.

* pensando alla stragrande maggioranza di utenti che neppure ci pensano o neanche ne hanno mai sentito parlare.

[paolo.oliva2]

Originariamente inviato da tuttodigitale

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.

Comunque la si gira, se XV dal 32nm (ipotetico) al 14nm raddoppierebbe i core, è ovvio che Zen li dimezzerebbe, quindi più di Zen X4+4 sul 32nm cosa ci scapperebbe? Anche perchè Zen, essendo a multipli di X4, o ci sta un X8 o ci sta X4, X6 non può esistere... nativamente. Sarebbe come ipotizzare un BD X9.

Ancora non è detta l'ultima parola per le frequenze finali e per il top magari con una selezione plus, stile 9590.

Comunque ancora non ho capito i reali margini (o limiti ) del 14nm... da 3,5GHz def a 3,9GHz Turbo, ci sono +500MHz, va bene che è un X8 e quindi il margine di TDP è molto (da X8 a X1 o X2...), ma in fin dei conti il margine è inferiore rispetto ad Intel, perchè comunque il funzionamento è 95W massimi, in Intel è 140W, eppure da frequenza def alla massima ci sarebbe sempre un range di 500MHz.

Comunque io sono convinto che AMD voglia piazzare Zen come 95W per far risaltare = TDP degli i7 X4, ma io ho un X8. Altrimenti, se volesse piazzare un Zen vs gli E Intel, avrebbe potuto impostare Zen 140W, se proprio il PP silicio facesse perdere efficienza, giocare la carta di 3 CCX.

Io spero, per AMD, che non faccia un procio né carne nè pesce. Cioè, se castri un X8 a 95W, si può correre il rischio di un TDP troppo basso per competere con gli E Intel, ma frequenze troppo inferiori agli i7 X4, rischierebbe di perdere in marketing, perchè Intel la promozione ai propri proci la sa fare e bene, li intorterebbe più che bene.
Se rinuncia a Zen X4 X86 nativo, la carta prezzo la gioca di sicuro.

[paolo.oliva2]

Originariamente inviato da bjt2

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+

Per quello che si è visto, penso più che AMD abbia fatto vedere dove Zen è più performante rispetto a che abbia giocato a nascondino facendo vedere meno potenzialità, ma alla fine, sembra equo un Zen +10% di frequenza e -10% di IPC, con risultato finale abbastanza simili... il che è una vittoria, considerando l'architettura Zen acerba e il 14nm GF inferiore a quello Intel.

Ora è tutta nelle mani AMD, se commercializzasse Zen ai prezzi dei rumors, non basterebbe GF e Samsung, dovrebbe far produrre anche a TSMC .

Certo che se promuovesse Zen con abbianata una RX 480, come ha fatto per gli i5... Lo sai che pensando male... il fatto di fare un pacchetto i5 + RX480, mi sa tanto di messaggio tipo "non calare troppo il prezzo dei proci ed io in cambio ti faccio vendere un tot di VGA in bandle ai miei proci...".

[george_p]

Originariamente inviato da Grizlod®

Non credo ci sarebbe stato lo stesso quantitativo di L3 e forse neppure l'HW per l'SMT.

Inoltre, maggior area, quindi minor resa sul wafer ed anche problemi a salire in OC.

IMO interessantissima la feature dell' overclock automatico rilevando la temperatura (*), ed in ambito server, se non ricordo male, il minichip ARM di cifratura.

* pensando alla stragrande maggioranza di utenti che neppure ci pensano o neanche ne hanno mai sentito parlare.

Speculazione personale la mia, e ogni progetto ha una sua storia dietro, se Keller e soci avessero lavorato al posto di Meyer avrebbero tirato fuori una cpu diversa da BD e Zen non sarebbe mai esistito.

Ciò che conta oggi è che Zen sia competitivo sul processo per il quale è stato progettato, tutto il resto è solo speculazione che non vedrà mai luce.

[bomkill]

[quote=paolo.oliva2

Certo che se promuovesse Zen con abbianata una RX 480, come ha fatto per gli i5... Lo sai che pensando male... il fatto di fare un pacchetto i5 + RX480, mi sa tanto di messaggio tipo "non calare troppo il prezzo dei proci ed io in cambio ti faccio vendere un tot di VGA in bandle ai miei proci...".[/QUOTE]

A questo non avevo pensato anche se sarebbe suicida per Amd tenere i prezzi allineati o poco inferiori a Intel,certo che un bundle zen+polaris/vega con un sostanziale sconto non sarebbe male

[fabius21]

Originariamente inviato da Grizlod®

IMO interessantissima la feature dell' overclock automatico rilevando la temperatura (*), ed in ambito server, se non ricordo male, il minichip ARM di cifratura.

* pensando alla stragrande maggioranza di utenti che neppure ci pensano o neanche ne hanno mai sentito parlare.

Il mio amico non mi permette di overcloccargli il suo q6600 ed ha un noctua girantesco

[cdimauro]

Originariamente inviato da bjt2

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)

Le DIV (intere) a 64 bit (e solo queste) non sono pipelined (su Broadwell e Skylake), e probabilmente anche le SQRT (SIMD; ma Skylake fa molto meglio di Broadwell, e sembra non pipelined solo la versione vettoriale a doppia precisione e a 256 bit) ma non il loro reciproco.

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

Sì, ma la cosa strana è che sarebbe dovuta essere AMD a fornire fin da principio la patch corretta: se non lo sa lei qual è la latenza (e throughput) delle sue istruzioni.

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.

Vedi sopra: l'unica ipotesi è che utilizzino le DIV per differenziare. E' l'unico caso in cui le versioni a 64 bit si comportano peggio (sembrano non pipelined, appunto) delle versioni con meno bit.

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

Azz. Pensavo di averti adescato, e m'è andata buca.

Ma è una specie di subset/superset di x86?

Superset, perché include tutte le istruzioni x86, più diverse altre (e parecchie altre modalità d'indirizzamento: ho perfino pre-post incremento e decremento, e l'aggiornamento del registro base. E altro ancora ).

Subset nell'implementazione, perché quasi tutte quelle legacy le ho relegate in un settore "low-performance": le eseguo, ma a velocità molto minore.

L'obiettivo è di garantire comunque l'esecuzione di qualunque tipo di istruzione, ma per il vecchiume c'è una penalità da pagare.

L'architettura è anche compatibile al 100% in assembly con x86 e x64, a patto di rimanere interamente a livello di sorgente. Ergo: niente uso di codice binario inserito nell'assembly (DB etc.) o facendo assunzioni sulla struttura degli opcode, ecc.

Quindi è possibile ricompilare tranquillamente quasi tutte le applicazioni x86 e x64 esistenti, e girano senza problemi (molto meglio. Densità nettamente migliore per codice a 64 bit, comparato a x64. E solo leggermente superiore con codice a 32 bit, comparato con x86). Fatta eccezione per quelle che ricadono nei casi di cui sopra (es: che fanno uso di JITer che generano ed eseguono dinamicamente codice macchina).

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

Troppo complicato, e non sarebbe abbastanza performante. Certo, nei soli casi in cui ha una conversione di tipo, guadagneresti, ma non sono casi comuni. Sicuramente non tali da giustificare una notevole complessità per implementare i tuoi core.

Da questo punto di vista ho preferito utilizzare un approccio più conservativo / tradizionale: l'ISA è molto simile alle attuali x64, ARM64, POWER.

Non è ortogonale, perché non potevo "ortogonalizzare" tutto, ma ritengo che da questo punto di vista sia un ottimo compromesso. Le eccezioni che i compilatori devono gestire sono poche, anche se alcune sono particolari.

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

Abbiamo le stesse idee. Io adoro la segmentazione per questo.

Ma mentre per codice e segmento di dati le dimensioni sono GENERALMENTE (vedi jiter et similia) statici, per l'heap e lo stack non è così: si espandono e contraggono. E la paginazione qui è veramente comoda.

Oltre al fatto che con la paginazione è più facile gestire la memoria virtuale (swap et similia) e fare altre cosucce interessanti.

Purtroppo non c'è una soluzione universale per tutto: segmentazione e paginazione hanno i loro pregi e difetti, e ha senso che esistano entrambe.

Comunque l'idea di accorpare le pagine è buona. Ma generalizzarla a qualunque dimensione (non solo 8 pagine alla volta) la vedo complicata a livello implementativo.

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

Sì, è vero. Ma prima ti rispondevo solo sulla SQRT.

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.

Non è un problema proprio per il contesto di cui parlavo prima: la cache verrebbe comunque ripulita immediatamente dopo l'uso, perché il processore farebbe altro.

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

AMD ha molti più casi di questo tipo (perché ha un massimo di 2MOP per istruzioni), ed è anche per questo che ha 4 decoder complessi. Per cui ha senso quest'approccio.

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

Tranquillo: non te li tocco i 128 bit. So bene quanto sia importante poter eseguire calcoli con una precisione più elevata.

Infatti l'unità SIMD della mia architettura è completamente ortogonale da questo punto di vista, e supporta float a 16/32/64/128 bit e interi a 8/16/32/64, in versione packed o scalare.

Questo proprio in previsione di supportare i settori HPC (128 bit) e machine learning / AI (16 bit spesso sono sufficienti qui).

E come densità di codice è leggermente inferiore ad AVX (che ha max 16 registri), ma meglio di AVX-512 (32 registri), ma usando 64 registri (fino a 128 con un altro meccanismo, comunque trasparente, ma che fa aumentare la dimensione delle istruzioni).



Buondì a tutti.

[Piedone1113]

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.

Come hai detto anche tu (ed io) non si reinventa la ruota.
X87 difficilmente verrà eliminata (a meno che non la si voglia emulare a livello hardware, ma poi il superPI non farà più testo), le MMX invece andrebbero eliminate e di netto (non credo che esistano software usciti da Vista in poi che abbiano un path esclusivo per MMX).
Certamente mettere mano ad un'architettura per rinnovarla profondamente (e poter quindi meglio sfruttare il silicio disponibile) equivale a riscriverla, tanto vale allora prendere tutto quello che si può adattare e ricreare il resto, aggiungere nuove implementazioni, riconcepire profondamente la cache L3 (che per la miniutarizzazione spinta di adesso e del prossimo futuro saranno sempre di dimensioni più imponenti) e predisporre per cache L4 (sperando che i dati non debbano passare per forza lungo tutta la gerarchia di cache).
Sinceramente sono certo che intel potrebbe presentare una cpu delle stesse prestazioni di un 6950 in meno di 70w sui 10 nm, amd con zen+ invece dovrebbe avere + 20% prestazioni a -30% consumi (e queste sono cose che ho visto nella palla di cristallo)

[bjt2]

Originariamente inviato da cdimauro

Le DIV (intere) a 64 bit (e solo queste) non sono pipelined (su Broadwell e Skylake), e probabilmente anche le SQRT (SIMD; ma Skylake fa molto meglio di Broadwell, e sembra non pipelined solo la versione vettoriale a doppia precisione e a 256 bit) ma non il loro reciproco.

Ecco, questo ero curioso di sapere...

Originariamente inviato da cdimauro

Sì, ma la cosa strana è che sarebbe dovuta essere AMD a fornire fin da principio la patch corretta: se non lo sa lei qual è la latenza (e throughput) delle sue istruzioni.

E scoprire così le sue carte? Naaaa! Sai perchè? Dalle latenze puoi scoprire se hanno alzato o abbassato il FO4. Siccome tutti quanti (tranne pochi come me ) davano clock nel range dei 3GHz base max, vuol dire che tutti si aspettavano un alto FO4, secondo il classico schema alta IPC=>alto FO4. Avendo le latenze, se sono alte, o comunque simili a BD, potevi scoprire le carte. In particolare se le latenze mostrassero un FO4 uguale o inferiore a BD, con la proiezione del +40% di IPC e un clock potenzialmente alto (almeno con il 14nm a regime), allora staresti mostrando le tue carte... Potenzialmente il FUD sparato da molta gente su clock disastrosi ha fatto il gioco di AMD e ora potrebbe fare una uscita a sorpresa. Io sono ancora convinto di almeno 3.5 base e almeno 4.5 turbomax più l'XFR. Se così fosse almeno nel breve termine non ci sarebbe neanche bisogno del 4 core, perchè kabylake ha 4.5Ghz di turbomax...

Originariamente inviato da cdimauro

Vedi sopra: l'unica ipotesi è che utilizzino le DIV per differenziare. E' l'unico caso in cui le versioni a 64 bit si comportano peggio (sembrano non pipelined, appunto) delle versioni con meno bit.

E' proprio quello che intendevo...

Originariamente inviato da cdimauro

Azz. Pensavo di averti adescato, e m'è andata buca.

Beh, sono sempre un ingegniiiiiere ancora nel pieno delle facoltà mentali (aka ancora niente alzheimer galoppante), quindi se mi dai un manuale lo dovrei capire...

Originariamente inviato da cdimauro

Superset, perché include tutte le istruzioni x86, più diverse altre (e parecchie altre modalità d'indirizzamento: ho perfino pre-post incremento e decremento, e l'aggiornamento del registro base. E altro ancora ).

Subset nell'implementazione, perché quasi tutte quelle legacy le ho relegate in un settore "low-performance": le eseguo, ma a velocità molto minore.

L'obiettivo è di garantire comunque l'esecuzione di qualunque tipo di istruzione, ma per il vecchiume c'è una penalità da pagare.

L'architettura è anche compatibile al 100% in assembly con x86 e x64, a patto di rimanere interamente a livello di sorgente. Ergo: niente uso di codice binario inserito nell'assembly (DB etc.) o facendo assunzioni sulla struttura degli opcode, ecc.

Quindi è possibile ricompilare tranquillamente quasi tutte le applicazioni x86 e x64 esistenti, e girano senza problemi (molto meglio. Densità nettamente migliore per codice a 64 bit, comparato a x64. E solo leggermente superiore con codice a 32 bit, comparato con x86). Fatta eccezione per quelle che ricadono nei casi di cui sopra (es: che fanno uso di JITer che generano ed eseguono dinamicamente codice macchina).

Quindi se ho capito bene, compatibilità solo a livello di assembly e quindi possibilità di JIT one to one con codice già compilato, con riprogettazione del formato istruzioni, immagino più efficiente e facile da decodificare. Ottima idea...

Originariamente inviato da cdimauro

Troppo complicato, e non sarebbe abbastanza performante. Certo, nei soli casi in cui ha una conversione di tipo, guadagneresti, ma non sono casi comuni. Sicuramente non tali da giustificare una notevole complessità per implementare i tuoi core.

Da questo punto di vista ho preferito utilizzare un approccio più conservativo / tradizionale: l'ISA è molto simile alle attuali x64, ARM64, POWER.

Non è ortogonale, perché non potevo "ortogonalizzare" tutto, ma ritengo che da questo punto di vista sia un ottimo compromesso. Le eccezioni che i compilatori devono gestire sono poche, anche se alcune sono particolari.

Ho dimenticato di dire che ho previsto anche un campo di bit per la numerosità. 0= scalare, 1=2 elementi, 2=4, 3=8 ecc e rendere tutto agnostico dalle implementazioni. Es implementazione economica con unità a 64 bit, che trappano per gli FP128 e fanno in una sola uop 1x64, 2x32 ecc e implementazioni high end magari a 256-512 bit, che fanno in un solo clock praticamente tutte le operazioni. Così hai un solo codice denso che gira a varie prestazioni sulle varie implementazioni.
Ma ovviamente la compatibilità con x86 è molto importante. Si può unire il meglio dei due mondi prevedendo TUTTE le istruzioni x86, più quelle che escono fuori dalle mie elugubrazioni, con la compatibilità assembly e la possibilità di fare JIT 1 to 1...

Originariamente inviato da cdimauro

Abbiamo le stesse idee. Io adoro la segmentazione per questo.

Ma mentre per codice e segmento di dati le dimensioni sono GENERALMENTE (vedi jiter et similia) statici, per l'heap e lo stack non è così: si espandono e contraggono. E la paginazione qui è veramente comoda.

Oltre al fatto che con la paginazione è più facile gestire la memoria virtuale (swap et similia) e fare altre cosucce interessanti.

Purtroppo non c'è una soluzione universale per tutto: segmentazione e paginazione hanno i loro pregi e difetti, e ha senso che esistano entrambe.

Ma la mia idea era di avere al posto delle TLB, un range di MTTR come i range register, per esempio 64/128 coppie dove hai indirizzo iniziale, finale, permessi e offset. In questo modo il SO si può organizzare anche per lo heap (in genere lo stack frame è preallocato, mi pare ci sia una opzione nel linker o compilatore e di default sia 4MB) e magari sul "segment fault" se i permessi del processo lo permettono, può spostare eventualmente qualcosa e allargare un range già esistente. Non è detto che devi per forza fare 1000 ranges... Diventerebbe una sorta di cache con 64/128 coppie di comparatori.
Ancora meglio invece di MTTRR da impostare a mano, fare una struttura di segment table (invece di page table) in memoria a 1 livello e nei TLB (che a questo punto possono anche essere 16-32 e solo di primo livello) mettere i range, che se il SO è intelligente, come ho detto sopra, possono essere veramente pochi e quindi praticamente non dover andare mai in memoria, tranne la prima volta. Magari al task switch in background possono anche essere caricati nel TLB i segmenti...

Originariamente inviato da cdimauro

Comunque l'idea di accorpare le pagine è buona. Ma generalizzarla a qualunque dimensione (non solo 8 pagine alla volta) la vedo complicata a livello implementativo.

Non è complicato: vedi sopra. Ora semplicemente Zen esclude i 3 bit bassi dal confronto. Con la mia idea deve fare due comparazioni in parallelo per ogni TLB e metterle in AND anzichè una. In pratica potrebbe anche non incrementare il FO4.

Originariamente inviato da cdimauro

Sì, è vero. Ma prima ti rispondevo solo sulla SQRT.

Non è un problema proprio per il contesto di cui parlavo prima: la cache verrebbe comunque ripulita immediatamente dopo l'uso, perché il processore farebbe altro.

AMD ha molti più casi di questo tipo (perché ha un massimo di 2MOP per istruzioni), ed è anche per questo che ha 4 decoder complessi. Per cui ha senso quest'approccio.

Tranquillo: non te li tocco i 128 bit. So bene quanto sia importante poter eseguire calcoli con una precisione più elevata.

Infatti l'unità SIMD della mia architettura è completamente ortogonale da questo punto di vista, e supporta float a 16/32/64/128 bit e interi a 8/16/32/64, in versione packed o scalare.

Questo proprio in previsione di supportare i settori HPC (128 bit) e machine learning / AI (16 bit spesso sono sufficienti qui).

E come densità di codice è leggermente inferiore ad AVX (che ha max 16 registri), ma meglio di AVX-512 (32 registri), ma usando 64 registri (fino a 128 con un altro meccanismo, comunque trasparente, ma che fa aumentare la dimensione delle istruzioni).



Buondì a tutti.

Interessante. Se non lo hai già fatto, potresti incominciare a scrivere il codice di una JIT x86->tuo formato magari sotto forma di libreria compatibile con i tool in commercio (non so se abbia più senso farlo a livello di assembler o linker), in modo da poter emettere il codice già a livello di compilazione...

[bjt2]

Originariamente inviato da Piedone1113

Come hai detto anche tu (ed io) non si reinventa la ruota.
X87 difficilmente verrà eliminata (a meno che non la si voglia emulare a livello hardware, ma poi il superPI non farà più testo), le MMX invece andrebbero eliminate e di netto (non credo che esistano software usciti da Vista in poi che abbiano un path esclusivo per MMX).
Certamente mettere mano ad un'architettura per rinnovarla profondamente (e poter quindi meglio sfruttare il silicio disponibile) equivale a riscriverla, tanto vale allora prendere tutto quello che si può adattare e ricreare il resto, aggiungere nuove implementazioni, riconcepire profondamente la cache L3 (che per la miniutarizzazione spinta di adesso e del prossimo futuro saranno sempre di dimensioni più imponenti) e predisporre per cache L4 (sperando che i dati non debbano passare per forza lungo tutta la gerarchia di cache).
Sinceramente sono certo che intel potrebbe presentare una cpu delle stesse prestazioni di un 6950 in meno di 70w sui 10 nm, amd con zen+ invece dovrebbe avere + 20% prestazioni a -30% consumi (e queste sono cose che ho visto nella palla di cristallo)

Tutte le estensioni hanno un bit nella CPUID che deve essere controlalto prima di iniziare. I software scritti correttamente semplicemente o terminano o usano un path 386/486 e quindi girano più lenti. ma se sono così vecchi, probabilmente erano progettati per CPU a 200-300MHz max e comunque volerebbero su CPU a 4Ghz. Analogamente l'x87, pochè ai tempi del 386 era un coprocessore opzionale, è fatto fin dalla fondamenta come trappabile con routine di emulazione software. Se ci sono software che usano qualche feature x87, si può avere una routine software. In realtà anche le CPU correnti fanno una cosa del genere, ma con microcodice: non sprecano area chip per cose oscure x87, ma c'è micorocodice. Ad esempio le funzioni trascendenti hanno microcodice di più di 200 uops!

[Ale55andr0]

http://wccftech.com/amd-ryzen-review-leaked/


Stessero così le cose, aggiungendo i 3.4+ ghz finali rispetto i 3.15 di questo presunto bench, a me andrebbe benissimo, se i prezzi fossero quelli in tabella...un affare colossale un sr7 a 350 cartoni di listino

[digieffe]

@bjt2

non puoi fare delle freq. di un 8 core le stesse di un 4 per via del tdp: pronosticai 3.2 base ma solo per il tdp di 95w, per un 125 3.7 base, aggiungo per un 140w 4.0 base limiti del silicio permettendo. è ovvio che un 4c nativo dovrà andare almeno 200mhz (4.4) in più di BR ma a quale tdp? non di certo 65w.
il problema resta il tdp e dove mura il silicio.

[.338 lapua magnum]

Originariamente inviato da Ale55andr0

http://wccftech.com/amd-ryzen-review-leaked/


Stessero così le cose, aggiungendo i 3.4+ ghz finali rispetto i 3.15 di questo presunto bench, a me andrebbe benissimo, se i prezzi fossero quelli in tabella...un affare colossale un sr7 a 350 cartoni di listino

prestazioni nulla da dire
quello che mi preoccupa è la tabella della lineup sr7 e sr7 BE (a 500€)
l'sr5 che dovrebbe essere quello più equilibrato tra freq e core, la sua variante BE, (se mai ci sarà) affianca il sr7 liscio con il prezzo?
sono rumors, però non ho intenzione di sganciare centoni in più per l'oc stile intel.
abituati troppo bene con gli fx tutti BE , però per me così non ci siamo.

[Roland74Fun]

Originariamente inviato da fatantony

Ahah! mi hai fatto rotolare dalle risate!
Quello che a me "preoccupa" di più è quando queste "dinamiche" (mi hanno detto, ho sentito, ho letto su internet, blabla) vengono applicate in campi un po' più "seri" dell'informatica...

Comunque MENO MALE che esistono posti come questo, in cui si discute (anche troppo, a volte) seriamente... Anche di SOI e Bulk

Tipo quelli, ho letto su facebbok che agli immigrati danno la casa i soldi le sigarette, l'iPhone, un pc Zen con 16 core, ed agli italiani nulla...

Per soi/bulk hai ragione. Non volevo dire che non é giusto parlarne ma che comunque l'utente di un pc normalmente non é competente od interessato a tali informazioni.

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.

Originariamente inviato da sgrinfia

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

No, non c'erano le basi per intavolare un discorso con gente del tipo Zen, sicuramente=Cina.

[paolo.oliva2]

Originariamente inviato da digieffe

- reale capacità produttiva. - insufficiente quasi certamente prezzo più alto

Mi è venuto in mente questo riflettendo sulle VGA.

Una RX 480 ha un die sui 250mmq, non ricordo bene se 220 o 280). E' prodotta sul 14nm, quindi a tutti gli effetti DEVE essere prodotta nelle stesse catene dove verrà prodotto Zen. La RX 480 io l'ho pagata 220€ al D-DAY, è ovvio che ad AMD, per il solo die, se avesse incassato solamente 150€, sarebbe già un miracolo.

Lo stesso wafer produrrebbe più die come Zen che come RX 480 (die Zen 170/180mmq, die RX 480 più grande), posso credere che il die Zen abbia una percentuale fallati superiore, un test/selezione più caro, e qualsivoglia, ma faccio fatica a ipotizzare che AMD occupi le catene per produrre 250mmq di die RX 480 che porta alle sue tasche 150€, e noi discutiamo che 170/180mmq di die Zen non possono essere venduti a meno di 600€ perchè altrimenti si intaserebbero le catene.

Non voglio dare l'impressione come se volessi imporre il mio pensiero, però credo che ci sia una differenza tra fattibilità ed impossibilità.
Una cosa è ipotizzare di pagare 50 una cosa che costa 100, un'altra è pagare 300 una cosa che costa 100 e che al momento ne costa 1000.

Per me, il prezzo finale di Zen è tutto relazionato su quanto AMD deciderà di fare cartello con Intel più che da effettivi costi.

[Roland74Fun]

Originariamente inviato da paolo.oliva2

....La RX 480 io l'ho pagata 220€ al D-DAY,

Ma dove? Ma come? Che versione é?

[capitan_crasy]

Originariamente inviato da Roland74Fun

Ma dove? Ma come? Che versione é?

Anch'io l'ho trovata a quel prezzo, ma la versione a 4GB...

[Roland74Fun]

Forse in Costa d'Avorio costano meno.

Dovevo andare lì per comprarla.

[capitan_crasy]

Originariamente inviato da Roland74Fun

Forse in Costa d'Avorio costano meno.

Dovevo andare lì per comprarla.

Io abito in Italia e per trovare i "veri" prezzi al lancio basta guardare il mercato tedesco, la media era di 50/70 euro in meno se paragonato al nostro...