[Thread Ufficiale] Aspettando ZEN

[paolo.oliva2]

Originariamente inviato da Roland74Fun

Forse in Costa d'Avorio costano meno.
Dovevo andare lì per comprarla.

Io l'ho comprata in Italia, al lancio e ne ho comprate 3, ho cercato su trovaprezzi, guardato chi la proponeva a meno, ed acquistate.

[Athlon]

Originariamente inviato da bjt2

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

..

a questo punto faccio outing anche io con la mia """architettura"""

cioe' un FPGA all interno del core che viene di volta in volta programato con le istruzioni complesse piu' utilizate , ad esempio se si deve fare un encoding si puo' mettere nel FPGA la versione "hardware" del' algoritmo di encoding per avere le massime performace.

lo stesso si puo' fare per l' encription

se viene rilevato l'uso ripetuto di una istruzione complessa microprogrammata allora il processore configura il GA per eseguirla in hardware

[paolo.oliva2]

Originariamente inviato da capitan_crasy

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

Qui mi fai venire un dubbio... ma non posso dire nulla in proposito, perchè ancora non ho potuto avviare il sistema, in quanto montato la RX, avevo i monitor con la sola presa VGA, ho cercato l'adattatore, trovato, i sistemi non partivano ugualmente e rimane solamente le DDR3 (10 banchi nessuno funzia più, manco in SC, perquesto avevo pensato alle VGA, in quanto ne avevo 3, le probabilità di guasto erano più sulle VGA), quindi ancora nada.

Aspettiamo sto Zen... a seconda del prezzo o faccio tutto AM4/DDR4 o 1 solo sistema Zen e acquisto le DDR3.

[bjt2]

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

Non ho detto che il 4 core non salirà di più. Ho detto che per combattere il 4 core intel può bastare ryzen se arriva a 4.5+GHz di turbo...
E' chiaro che un 4c può cloccarsi di più. Ma solo se non è uno scarto.
Attualmente i 4c saranno probabilmente gli scarti dell'8c e quindi non credo che vadano a clock superiore... Ci vuole un 4c nativo o dobbiamo aspettare l'APU...

[okorop]

Originariamente inviato da paolo.oliva2

Io l'ho comprata in Italia, al lancio e ne ho comprate 3, ho cercato su trovaprezzi, guardato chi la proponeva a meno, ed acquistate.

io l'ho presa a novembre custom, la reference non potevo prenderla per via della porta dvi mancante......comunque buon prezzo

[paolo.oliva2]

Originariamente inviato da bjt2

Non ho detto che il 4 core non salirà di più. Ho detto che per combattere il 4 core intel può bastare ryzen se arriva a 4.5+GHz di turbo...
E' chiaro che un 4c può cloccarsi di più. Ma solo se non è uno scarto.
Attualmente i 4c saranno probabilmente gli scarti dell'8c e quindi non credo che vadano a clock superiore... Ci vuole un 4c nativo o dobbiamo aspettare l'APU...

http://cdn.wccftech.com/wp-content/u...on-and-TDP.jpg

Comunque è impressionante le performances vs consumi.
Nella figura sopra, non è tanto il consumo di Zen X8+8 vs 6900K X8+8, quanto il consumo a parità di elaborazione tra un Zen X8+8 e un 6700K.
Zen X8+8 93W, 6900K 96W sono simili, il 6700K 62W, ma rappresentano il consumo a parità di carico proporzionato ai TH massimi del procio, quindi sia Zen X8 che il 6900K, con un carico proporzionato a quello di un 6700K che sul 6700K produce 62W, sarebbero ambedue sicuramente sotto i 50W.

Quello che voglio dire, è che Zen avrà un consumo nettamente inferiore ad un 6700K/7700K, perchè comunque Zen X4 è 65W mentre un 6700K 95W, vuoi per l'iGPU assente, vuoi perchè il silicio perde efficienza a frequenze del 6700K.

Comunque io rimango dell'idea che la superiorità del 6700K (intesa in possibili frequenze superiori) lo sarà unicamente finchè i TH saranno fisici (cioè max 4TH come 4 i core fisici). Nel momento che il software potrà richiedere >4TH, un procio >4 core, risulterà sia più performante che molto più efficiente.

Cioè... un Zen X8+8 che lavora come X4 no SMT, il 6700K sarà più performante nel caso di frequenze/IPC superiori, ma sicuramente meno efficiente. Nel momento in cui utilizzeranno >4TH, il 6700K concederà il 30% di potenza per ogni TH basato su SMT vs un Zen X8 che ne concederà il 100% seppur a frequenze inferiori. Oltre gli 8 TH, Zen potrà concedere fino a 16TH con un consumo al max 50% superiore, ma che si dovrebbe tradurre simile al 100% superiore, quindi molto più efficiente.

[Gioz]

Originariamente inviato da paolo.oliva2

http://cdn.wccftech.com/wp-content/u...on-and-TDP.jpg

Comunque è impressionante le performances vs consumi.
Nella figura sopra, non è tanto il consumo di Zen X8+8 vs 6900K X8+8, quanto il consumo a parità di elaborazione tra un Zen X8+8 e un 6700K.
Zen X8+8 93W, 6900K 96W sono simili, il 6700K 62W, ma rappresentano il consumo a parità di carico proporzionato ai TH massimi del procio, quindi sia Zen X8 che il 6900K, con un carico proporzionato a quello di un 6700K che sul 6700K produce 62W, sarebbero ambedue sicuramente sotto i 50W.

è normale, il 6900K gira a frequenze molto più basse del 6700K, sono uno 4GHz base e l'altro 3.2GHz base.

[Emaximus]

Io sto aspettando di vedere qualche scheda madre top con l'x370 (si è già vista la giga x370 gaming k3 di preproduzione). So che all'evento "new horizon" come scheda hanno usato la msi tomahawk e che sembrerebbe avere 6 fasi (spero niente mosfet NIKOS). Mi piacerebbe vedere una crosshair VI formula sinceramente.

[Nui_Mg]

Originariamente inviato da Roland74Fun

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

Non ci si informa su Facebook, bastano le cronache/indagini delle tv locali (io sono sintonizzato, per quanto l'Italia, soprattutto su quelle veronesi/bresciane/milanesi) per scoprire che c'è moltissimo di vero: non gli danno lo smartphone perché molti "profughi" già ce l'hanno (chi anche più di uno), ma hanno gratuite le sim, gli alloggi (hotel, pensioni, ecc., tutta roba pagata dallo stato verso l'imprenditore locale che accetta; ah, mi sono dimenticato di menzionare pure i trasporti pubblici, di cui sono un grande intenditore visto che li prendo ogni giorno, cioè gratuità/totale impunibilità dai bus di superficie, alla metro e ai treni regionali), i pocket money, i pasti, accesso gratuito a tutte le infrastrutture ospedaliere (spesso anche il dentista). E' poi pur sempre vero che, e sono casi saltati alla ribalta pure nazionale, vi sono vari italiani in notevoli difficoltà che non hanno niente e che dormono in macchina, quando va bene.
Cose che, onestamente, non accadono oltre Alpi (o accadono in maniera minore, come in Germaia) e non per niente tutti gli immigrati che arrivano da noi non sono accettati oltre alpi (oppure lo sono ma vengono attentamente selezionati, per esempio la Merkel è molto più ben disposta verso i siriani perché hanno di più da offrire a livello di preparazione).
L'europa dice all'Italia "brava Italia, così civile, così accogliente, così umana, ecc. che va a salvare gli immigrati perfino non nelle acque italiane o internazionali, ma perfino in quelle libiche, abbiamo tutti da imparare dall'Italia" per poi all'atto pratico fare cosa? Rifiutare/bloccare qualsiasi immigrato provenga dalla stessa Italia tanto "leccata".
Tutte cose che ovviamente non mi invento e documentate perfino a livello informazione nazionale (che è certamente stra pro-accoglienza, pro-cattolica, pro-bla bla).
Non hai idea del ridere che ci siamo fatti a Monaco quando pochi giorni prima dell'apertura dell'expo a Milano un rumeno è stato ripreso (poi circolato a livello mondiale) che letteralmente cagava nella piazza frontale alla stazione centrale di Milano.
Oh, d'altronde se sono gli stessi italiani di Italia a volere così...

[Nui_Mg]

Originariamente inviato da Ale55andr0

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

Se quelli sono dati che si riveleranno veritieri, allora la situazione è più che rosea, considerando pure che siamo agli inizi come affinamento, un esa-core del genere sarebbe veramente grandioso, pensando anche alla mia fissa che dal package di Zen esce qualche linea usb 3.1 gen.2, quindi nativa (non richiederebbe driver appositi con le livecd), a differenza perfino di kabylake il cui south intel non ha usb 3.1 gen.2 (ma eventualmente sarà supportato solo a livello terzi da produttori di mobo, quindi funzionalità disponibili solo all'interno dell'ambiente win).

[Nui_Mg]

Originariamente inviato da Emaximus

Io sto aspettando di vedere qualche scheda madre top con l'x370 (si è già vista la giga x370 gaming k3 di preproduzione). So che all'evento "new horizon" come scheda hanno usato la msi tomahawk e che sembrerebbe avere 6 fasi (spero niente mosfet NIKOS). Mi piacerebbe vedere una crosshair VI formula sinceramente.

L'incognita per me è proprio questa: se sul procio pare ormai che vi sia bontà/competitività, un forte interrogativo rimane sulla bontà/qualità delle mobo che lo supporteranno, storicamente spesso inferiori (almeno quelle che ho avuto io all'epoca dell'athlon 64) alle controparti di piattaforma intel.

[paolo.oliva2]

Originariamente inviato da Gioz

è normale, il 6900K gira a frequenze molto più basse del 6700K, sono uno 4GHz base e l'altro 3.2GHz base.

Ma infatti io evidenzio il fatto che erroneamente si suppone che un X8 consumi il doppio di un X4, mentre non si valuta che a parità di dati elaborati, l'X8 consuma meno di un X4 perchè un X4 è più facile che lavori ad un'efficienza peggiore di un X8 semplicemente perchè si cerca potenza con la frequenza (che aumentando fa perdere efficienza) che con i core.

In pratica, io trovo alquanto sbagliato pensare ad un X4 come soluzione green, cosa che del resto era stata ampiamente sottolineata ai tempi di BD 125W. Oggi, siamo esattamente all'opposto, nel senso che con la miniaturizzazione odierna, alla ricerca di potenza la soluzione è aumentare il numero di core, non la frequenza. Massimizza ciò che dico... cosa cambierebbe in un X4 a 10nm? a 7nm? Avresti un X4 a 65W, 4,4GHz def con +5% di IPC rispetto ad un 7700k? Cosa avresti, invece con un X8? Le frequenze di un X4 odierne al TDP di un X4 odierno.

Oltretutto, spero che l'iGPU si possa disabilitare nel 6700K/7700K, perchè concordo con il fatto che un APU può far risparmiare i soldi di una discreta, ma questo punto cozza con il fatto di scegliere una frequenza/IPC core alta quando con l'iGPU dell'APU non potresti mai sfruttare la potenza dei core, perchè GPU limited.

[paolo.oliva2]

Originariamente inviato da Nui_Mg

Non ci si informa su Facebook, bastano le cronache/indagini delle tv locali (io sono sintonizzato, per quanto l'Italia, soprattutto su quelle veronesi/bresciane/milanesi) per scoprire che c'è moltissimo di vero: non gli danno lo smartphone perché molti "profughi" già ce l'hanno (chi anche più di uno), ma hanno gratuite le sim, gli alloggi (hotel, pensioni, ecc., tutta roba pagata dallo stato verso l'imprenditore locale che accetta; ah, mi sono dimenticato di menzionare pure i trasporti pubblici, di cui sono un grande intenditore visto che li prendo ogni giorno, cioè gratuità/totale impunibilità dai bus di superficie, alla metro e ai treni regionali), i pocket money, i pasti, accesso gratuito a tutte le infrastrutture ospedaliere (spesso anche il dentista). E' poi pur sempre vero che, e sono casi saltati alla ribalta pure nazionale, vi sono vari italiani in notevoli difficoltà che non hanno niente e che dormono in macchina, quando va bene.
Cose che, onestamente, non accadono oltre Alpi (o accadono in maniera minore, come in Germaia) e non per niente tutti gli immigrati che arrivano da noi non sono accettati oltre alpi (oppure lo sono ma vengono attentamente selezionati, per esempio la Merkel è molto più ben disposta verso i siriani perché hanno di più da offrire a livello di preparazione).
L'europa dice all'Italia "brava Italia, così civile, così accogliente, così umana, ecc. che va a salvare gli immigrati perfino non nelle acque italiane o internazionali, ma perfino in quelle libiche, abbiamo tutti da imparare dall'Italia" per poi all'atto pratico fare cosa? Rifiutare/bloccare qualsiasi immigrato provenga dalla stessa Italia tanto "leccata".
Tutte cose che ovviamente non mi invento e documentate perfino a livello informazione nazionale (che è certamente stra pro-accoglienza, pro-cattolica, pro-bla bla).
Non hai idea del ridere che ci siamo fatti a Monaco quando pochi giorni prima dell'apertura dell'expo a Milano un rumeno è stato ripreso (poi circolato a livello mondiale) che letteralmente cagava nella piazza frontale alla stazione centrale di Milano.
Oh, d'altronde se sono gli stessi italiani di Italia a volere così...

Come non quotarti.
Oltre a ciò, l'assurdo, e sottolineo assurdo, è quanto capitato a me. Sono sposato con una ivoriana da agosto 2014, faccio il visto all'ambasciata italiana in Costa d'Avorio e la porto con me in Italia. Vado al comando della polizia della mia città, per regolalizzarla, mi dicono che non ci sono problemi che va bene così, che non c'è bisogno di fare il permesso di soggiorno. Dopo 1 anno torno in Costa d'Avorio, e arrivato il momento di un altro viaggio in Italia, rivado all'ambasciata per rifare il visto per mia moglie (2016), mi hanno fatto aspettare 3 settimane facendo tutte le verifiche come se fossi un importatore clandestino e, beffa, mi hanno detto IMPOSSIBILE che ti abbiano risposto così, che per loro io non era affatto andato dalla Polizia. Al che a luglio 2016 sono andato nello stesso comando con la lettera dell'ambasciata (che riportava in base all'articolo tal dei tali, bla bla bla, dovevano fare il permesso di soggiornno a mia moglie), dicendo che a fine luglio sarei partito. La risposta è stata che me lo scordo, perchè ci vogliono 45 giorni solamente per l'appuntamento e altri 2 mesi per averlo. Chiaramentte sono partito e ho il foglietto timbrato dal comando di polizia che mi sono presentato. Ora dovrò ritornare all'ambasciata per rifare il visto... e magari SUBIRE pure altre discussioni. Poi, come dici tu, ti vanno a prendere il clandestino sulle coste libiche ed il permesso di soggiorno glielo danno dopo 7 giorni, gratis, mentre io spendo 60€ circa ogni visto + il tempo + il viaggio.

[bomkill]

Originariamente inviato da paolo.oliva2

Come non quotarti.
Oltre a ciò, l'assurdo, e sottolineo assurdo, è quanto capitato a me. Sono sposato con una ivoriana da agosto 2014, faccio il visto all'ambasciata italiana in Costa d'Avorio e la porto con me in Italia. Vado al comando della polizia della mia città, per regolalizzarla, mi dicono che non ci sono problemi che va bene così, che non c'è bisogno di fare il permesso di soggiorno. Dopo 1 anno torno in Costa d'Avorio, e arrivato il momento di un altro viaggio in Italia, rivado all'ambasciata per rifare il visto per mia moglie (2016), mi hanno fatto aspettare 3 settimane facendo tutte le verifiche come se fossi un importatore clandestino e, beffa, mi hanno detto IMPOSSIBILE che ti abbiano risposto così, che per loro io non era affatto andato dalla Polizia. Al che a luglio 2016 sono andato nello stesso comando con la lettera dell'ambasciata (che riportava in base all'articolo tal dei tali, bla bla bla, dovevano fare il permesso di soggiornno a mia moglie), dicendo che a fine luglio sarei partito. La risposta è stata che me lo scordo, perchè ci vogliono 45 giorni solamente per l'appuntamento e altri 2 mesi per averlo. Chiaramentte sono partito e ho il foglietto timbrato dal comando di polizia che mi sono presentato. Ora dovrò ritornare all'ambasciata per rifare il visto... e magari SUBIRE pure altre discussioni. Poi, come dici tu, ti vanno a prendere il clandestino sulle coste libiche ed il permesso di soggiorno glielo danno dopo 7 giorni, gratis, mentre io spendo 60€ circa ogni visto + il tempo + il viaggio.

E si la nostra classe digerente (dirigente) non si rende conto che sta montando l'incazzatura della gente e te lo dice uno che comprende le ragioni di chi cerca una vita migliore,quello che non comprendo e il diverso trattamento tra italiani indigenti e immigrati,non comprendo il non rispetto degli usi e tradizioni del paese ospitante,non comprendo la ritrosia degli immigrati ad integrarsi ed accettare il cibo che viene loro dato (io se vado a casa di altri anche se non mi piace non butto per terra il cibo,piuttosto mangio ringrazio e se il posto non mi piace me ne vado per non tornare più e se non lo posso fare mi sforzo di accettare in segno di riconoscenza).
Ma in fondo la verità in fondo la conosciamo gli immigrati servono principalmente a chi gestisce l'economia per abbassare i diritti degli autoctoni .

BUON NATALE A TUTTI.

[cdimauro]

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

Per entrambi l'emulazione software potrebbe essere sufficiente: compatibilità garantita, però al prezzo di prestazioni nettamente inferiori. Meglio che toglierla completamente di mezzo.

Ed è già possibile, come ha scritto bjt2. Solo che attualmente il trap + emulazione di istruzioni x87, MMX, e in generale di una qualunque istruzione, è mostruosamente lento, a causa della chiamata di una ISR (e dunque doppio context switch).

Servirebbe una soluzione migliore.

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

Se ci pensi bene, più o meno è quello che Intel ha iniziato a fare con AVX prima e AVX-512 poi, visto che l'unità SIMD è ormai diventata un elemento fondamentale per un processore, ed è quella che cresce e si evolve di più e più velocemente in un processore, ormai.

MMX ed SSE sono delle pezze all'ISA x86, con troppi limiti. La prima è ormai abbandonata da tempo, ma la seconda è ancora troppo usata. Le AVX consentono una transizione "morbida" dalle SSE (visto che sono una sostanziale riscrittura delle stesse operazioni), e prima o poi si riuscirà a eliminare anche questa.

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)

Sulle quali non sono mai intervenuto, come sai, e non lo farò nemmeno ora.

Però sarebbe veramente un cambiamento epocale per Intel, se decidesse di deprecare alcune parti dell'ISA. Fosse anche soltanto l'MMX.

D'altra parte ARM con ARM64 ha colto l'occasione per ripensare da zero tutto, e togliere di mezzo un sacco di roba legacy. E' anche vero che aveva le mani molto più libere (visto che non ha mai avuto un'ISA a 64 bit, e giocoforza doveva presentarne una per rimanere competitiva), per cui le è venuto più facile.

Il mio cruccio rimane quello che AMD avrebbe potuto approfittarne allo stesso modo, e con x64 avrebbe potuto tirare fuori un'ISA a 64 bit nuova di pacca, con una struttura degli opcode di gran lunga più efficiente, e togliendo di mezzo molto più legacy.

Originariamente inviato da bjt2

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

Non è che ci sia tanto da scoprire o da temere. Intel non potrebbe certo cambiare le sue (micro)architetture in poco tempo, anche se AMD avesse rilasciato questi dettagli.

Si tratta di tempi molto lunghi per cambiamenti di quella portata.

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

Ecco qui.

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

Esattamente. La mia ISA è totalmente compatibile con x86 & x64 a livello di registri e istruzioni: ogni istruzione x86 o x64, infatti, può essere mappata esattamente 1:1 con una della mia ISA.

La decodifica è estremamente semplice ed efficiente. Penso che sia del tutto inutile utilizzare tag bit nella cache L1 codice, per stabilire l'inizio e la fine di ogni istruzione, perché è possibile recuperare / calcolare quest'informazione molto velocemente e richiedendo pochi bit estratti dall'istruzione; in realtà, oltre alla lunghezza, si possono recuperare praticamente tutte le informazioni utili alla decodifica più altro.
Non uso nemmeno prefissi. Mi sono inventato un meccanismo particolare per gestire i casi più complessi (registri "high" come AH, BH, ecc.. Estensione dei registri SIMD da 64 a 128. ecc..)

Nonostante tutto, la densità è simile a x86 (leggermente inferiore), e di gran lunga migliore rispetto a x64.

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.

Quant'è lungo il campo di bit? E fino a quanti elementi puoi specificare? Perché questo potrebbe condizionare la dimensione delle istruzioni e, dunque, la densità del codice, con ricadute negative sulle prestazioni.

La mia ISA prevede già nativamente supporto a registri SIMD a 128, 256, 512, e 1024 bit. Più il supporto a MMX (64 bit) ed SSE (128 bit, ma la parte alta del vettore viene mantenuta intatta), in maniera simile (nel senso che possono usare esattamente tutte le istruzioni della mia ISA, con la stessa identica struttura, ma con qualche limite. Ad esempio non viene fornito oppure ho proibito l'uso delle maschere).

Ho preferito un approccio più tradizionale, come vedi, con dimensione esplicita, anziché quello usato da Agner con la ForwardCom, oppure di recente con ARM e la sua nuova SIMD con registri "variabili" fino a 2048 bit. Ma nulla toglie di implementare il supporto ai registri a 1024 bit, spezzando internamente le istruzioni in più uop, come fa Zen, e faceva il Pentium-III con le sue SSE: così si scrive il codice una sola volta sfruttando la massima dimensione, e si delega alla micro-architettura come implementare il tutto, in base al budget/obiettivi.

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

E' esattamente quello che ho fatto io.

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

Ma non è troppo pesante usare tutti quei comparatori? Da replicare poi per le 2-3 load/store eseguibili per ciclo di clock.

L'idea di sei segmenti/range IMO sarebbe utile per ridurre notevolmente l'uso delle entry TLB, con vantaggi sia a livello prestazionale sia di consumi.

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.

Per operazioni così semplici, e in questa parte del chip, è plausibile che non aumenti.

Rimangono solo i miei dubbi relativi a tutte quelle comparazioni.

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

Già fatto.

Ho uno script Python che legge un .exe, disassembla quante più istruzioni possibili partendo dall'entry point, e traduce ogni istruzione x86 o x64 nell'equivalente della mia ISA. Inoltre genera un sacco di statistiche; è così che ho potuto misurare la densità del codice e confrontarla con x86 e x64.

C'è da dire che in questo modo ottengo "soltanto" un lower bound riguardo alla densità, perché sto soltanto mappando, rozzamente, un'istruzione x86/x64 in una mia.

Quindi non sto usando nulla delle cose nuove che ho introdotto, come i registri in più (meno load / store in memoria), nuove istruzioni ternarie o binarie non distruttive per i GPR (RISC-like ), istruzioni ternarie con valore immediato a 8 bit (idem come prima), nuove modalità d'indirizzamento, e persino una move memory to memory.
Son tutte cose che consentiranno non soltanto di aumentare le prestazioni, ma di migliorare anche la densità di codice, andando a rivaleggiare con soluzioni come RISC-V (che al momento sono fra le migliori da questo punto di vista).

Dunque devo muovermi ad aggiornare lo script per la terza versione della mia ISA, perché devo poi modificarlo per la quarta (già definita. E sarà anche l'ultima).

Originariamente inviato da Athlon

a questo punto faccio outing anche io con la mia """architettura"""

cioe' un FPGA all interno del core che viene di volta in volta programato con le istruzioni complesse piu' utilizate , ad esempio se si deve fare un encoding si puo' mettere nel FPGA la versione "hardware" del' algoritmo di encoding per avere le massime performace.

lo stesso si puo' fare per l' encription

se viene rilevato l'uso ripetuto di una istruzione complessa microprogrammata allora il processore configura il GA per eseguirla in hardware

In parte puoi già farlo con alcuni Xeon, che integrano un FPGA.

Anche se ciò che descrivi è decisamente più estremo. IMO sarebbe meglio lasciare qualche spazio nell'ISA per istruzioni "customizzabili", da smistare all'FPGA. Modello coprocessore, per intenderci.

Sarebbe un buon compromesso, e di più semplice realizzazione.

Nella mia ISA c'è spazio per centinaia di future istruzioni GPR, e migliaia di istruzioni SIMD. Per cui riservare qualche gruppo per un coprocessore è decisamente banale.

Originariamente inviato da bjt2

E' chiaro che un 4c può cloccarsi di più. Ma solo se non è uno scarto.
Attualmente i 4c saranno probabilmente gli scarti dell'8c e quindi non credo che vadano a clock superiore... Ci vuole un 4c nativo o dobbiamo aspettare l'APU...

*

@Nui_Mg: la situazione in Germania non è così diversa. Ma bisognerebbe distinguere fra immigrati / clandestini, e profughi, che sono cose completamente diverse. Altrimenti si finisce per fare dell'insano populismo, e fomentare la solita xenofobia.

[Athlon]

Originariamente inviato da cdimauro

Anche se ciò che descrivi è decisamente più estremo. IMO sarebbe meglio lasciare qualche spazio nell'ISA per istruzioni "customizzabili", da smistare all'FPGA. Modello coprocessore, per intenderci.
.

ho avuto modo di utilizzare tempo addietro un processore Transmeta e ne sono rimasto affascinato.

Da allora il mio sogno e' un piccolissimo core fisico a basso consumo visto dal sistema come 16 o piu' core logici ed una FPGA molto estesa che viene riconfigurata ed attivata solo quando serve e solo per le istruzioni che sono in coda e che non riescono a venir processate dal piccolo core fisico.

In pratica accenderei i transistor solo quando servono e solo configurati per risolvere le istruzioni che gia' sono in coda

[Gioz]

Originariamente inviato da paolo.oliva2

Ma infatti io evidenzio il fatto che erroneamente si suppone che un X8 consumi il doppio di un X4, mentre non si valuta che a parità di dati elaborati, l'X8 consuma meno di un X4 perchè un X4 è più facile che lavori ad un'efficienza peggiore di un X8 semplicemente perchè si cerca potenza con la frequenza (che aumentando fa perdere efficienza) che con i core.
In pratica, io trovo alquanto sbagliato pensare ad un X4 come soluzione green, cosa che del resto era stata ampiamente sottolineata ai tempi di BD 125W. Oggi, siamo esattamente all'opposto, nel senso che con la miniaturizzazione odierna, alla ricerca di potenza la soluzione è aumentare il numero di core, non la frequenza. Massimizza ciò che dico... cosa cambierebbe in un X4 a 10nm? a 7nm? Avresti un X4 a 65W, 4,4GHz def con +5% di IPC rispetto ad un 7700k? Cosa avresti, invece con un X8? Le frequenze di un X4 odierne al TDP di un X4 odierno.

si concordo, va tutto relazionato all'esigenza e al tipo di utilizzo reale.
poi ovviamente continuano comunque a spingere il possibile sulle frequenze e sull'st perché c'è un grosso mercato a cui interessa quello e perchè rimane comunque molto complicato parallelizzare "bene" i compiti da svolgere

Oltretutto, spero che l'iGPU si possa disabilitare nel 6700K/7700K, perchè concordo con il fatto che un APU può far risparmiare i soldi di una discreta, ma questo punto cozza con il fatto di scegliere una frequenza/IPC core alta quando con l'iGPU dell'APU non potresti mai sfruttare la potenza dei core, perchè GPU limited.

dovrebbe bastare settare come grafica primaria la pci-e per disattivare la igpu.

[bjt2]

Originariamente inviato da cdimauro

Ecco qui.

vedendo che avevi postato un link, ho pensato a un manuale VHDL... Poi me lo leggo, ma non ora perchè è quasi Natale...

A proposito: AUGURI!

Originariamente inviato da cdimauro

Esattamente. La mia ISA è totalmente compatibile con x86 & x64 a livello di registri e istruzioni: ogni istruzione x86 o x64, infatti, può essere mappata esattamente 1:1 con una della mia ISA.

La decodifica è estremamente semplice ed efficiente. Penso che sia del tutto inutile utilizzare tag bit nella cache L1 codice, per stabilire l'inizio e la fine di ogni istruzione, perché è possibile recuperare / calcolare quest'informazione molto velocemente e richiedendo pochi bit estratti dall'istruzione; in realtà, oltre alla lunghezza, si possono recuperare praticamente tutte le informazioni utili alla decodifica più altro.
Non uso nemmeno prefissi. Mi sono inventato un meccanismo particolare per gestire i casi più complessi (registri "high" come AH, BH, ecc.. Estensione dei registri SIMD da 64 a 128. ecc..)

Nonostante tutto, la densità è simile a x86 (leggermente inferiore), e di gran lunga migliore rispetto a x64.

Originariamente inviato da cdimauro

Quant'è lungo il campo di bit? E fino a quanti elementi puoi specificare? Perché questo potrebbe condizionare la dimensione delle istruzioni e, dunque, la densità del codice, con ricadute negative sulle prestazioni.

E' tutto molto fluido. Avevo pensato a una ISA a lunghezza variabile, ma con unità da 32 bit, di cui la prima divisa tra opcode (da cui derivare il numero di parametri, con opcode diversi per add1 2 ecc e magari bit iniziali diversi per istruzioni intere, fp ecc) e bit per la numerosità. Avevo pensato ad almeno 3 bit, con potenze di due crescenti, quindi con 111=256 elementi. Gli altri per opcode e numero parametri. E poi blocchi di 32 bit per i parametri, con bit per tipo di indirizzamento e indirizzo ecc. Ovviamente nessun limite e teoricamente possibilità di avere anche istruzioni ternarie con 3 operandi memoria, anche indiretti. Un vero CISCone! Ma ovviamente era solo una idea allo stato embrionale.

Originariamente inviato da cdimauro

La mia ISA prevede già nativamente supporto a registri SIMD a 128, 256, 512, e 1024 bit. Più il supporto a MMX (64 bit) ed SSE (128 bit, ma la parte alta del vettore viene mantenuta intatta), in maniera simile (nel senso che possono usare esattamente tutte le istruzioni della mia ISA, con la stessa identica struttura, ma con qualche limite. Ad esempio non viene fornito oppure ho proibito l'uso delle maschere).

Ho preferito un approccio più tradizionale, come vedi, con dimensione esplicita, anziché quello usato da Agner con la ForwardCom, oppure di recente con ARM e la sua nuova SIMD con registri "variabili" fino a 2048 bit. Ma nulla toglie di implementare il supporto ai registri a 1024 bit, spezzando internamente le istruzioni in più uop, come fa Zen, e faceva il Pentium-III con le sue SSE: così si scrive il codice una sola volta sfruttando la massima dimensione, e si delega alla micro-architettura come implementare il tutto, in base al budget/obiettivi.

E' esattamente quello che ho fatto io.

Originariamente inviato da cdimauro

Ma non è troppo pesante usare tutti quei comparatori? Da replicare poi per le 2-3 load/store eseguibili per ciclo di clock.

L'idea di sei segmenti/range IMO sarebbe utile per ridurre notevolmente l'uso delle entry TLB, con vantaggi sia a livello prestazionale sia di consumi.

Per operazioni così semplici, e in questa parte del chip, è plausibile che non aumenti.

Rimangono solo i miei dubbi relativi a tutte quelle comparazioni.

Che io sappia tutte le caches, essendo memorie associative, comparano in parallelo i vari tag. Quindi anche i TLB. Ma il problema è l'organizzazione a vie. Una cache come vorrei farla io dovrebbe essere fully associative e comparare TUTTI i tag in parallelo. Quindi la devi fare piccola. E' da vedere se bastano 16-32 ranges, visto che i SO non sono obbligati a fare allocazioni consecutive.
L'idea di AMD è geniale, perchè la comparazione è uguale al caso standard, solo che mascheri 3 bit bassi. E' un ottimo compromesso, ma il range di pagine 4k deve essere allineato a 32kb... Suggerirei ad AMD di almeno estendere a 16/32/64 ecc pagine consecutive... Magari lo faranno in Zen+...

Originariamente inviato da cdimauro

Già fatto.

Ho uno script Python che legge un .exe, disassembla quante più istruzioni possibili partendo dall'entry point, e traduce ogni istruzione x86 o x64 nell'equivalente della mia ISA. Inoltre genera un sacco di statistiche; è così che ho potuto misurare la densità del codice e confrontarla con x86 e x64.

C'è da dire che in questo modo ottengo "soltanto" un lower bound riguardo alla densità, perché sto soltanto mappando, rozzamente, un'istruzione x86/x64 in una mia.

Quindi non sto usando nulla delle cose nuove che ho introdotto, come i registri in più (meno load / store in memoria), nuove istruzioni ternarie o binarie non distruttive per i GPR (RISC-like ), istruzioni ternarie con valore immediato a 8 bit (idem come prima), nuove modalità d'indirizzamento, e persino una move memory to memory.
Son tutte cose che consentiranno non soltanto di aumentare le prestazioni, ma di migliorare anche la densità di codice, andando a rivaleggiare con soluzioni come RISC-V (che al momento sono fra le migliori da questo punto di vista).

Dunque devo muovermi ad aggiornare lo script per la terza versione della mia ISA, perché devo poi modificarlo per la quarta (già definita. E sarà anche l'ultima).

Bellissimo! Lo sai, vero, che gcc (e penso tutti i compilatori, magari per ICC ce lo puoi dire tu se lo ricordi) chiama il compilatore c che spara codice assembler e poi l'assemblatore e il linker? E che se non sbaglio, almeno l'assemblatore di gcc è abbastanza standard ed ha un file di configurazione per mappare le istruzioni assembler in opcode? Potresti studiarti il formato e scrivere il file per la tua ISA... Comprese le nuove istruzioni... Poi basterebbe solo cambiare isa target in gcc et voilà...

AUGURI DI BUON NATALE!

[bjt2]

Da anandtech:

La situazione di INTEL:

They said they didn't have time to bench Kaby Lake against Zen in the benchmarks, but there is another section in which they bench Kaby Lake, I posted them in the last picture.

Anyway it's 100% legit

If someone could explain the table with all the values where they compare Bristol Ridge, Summit Ridge and Kaby Lake, I don't understand anything

Also they think it's unlikely Zen will be available in January given the current state of the platform, even a March mass availability is optimistic.

Info I got from reading their file on Intel:

They have internal sources at Intel and the climate there is currently awful apparently, employees are very discouraged and some feel like "they have nothing left to lose". They are making big profits now by totally screwing up the future. According to the magazine, Intel is "probably in the most delicate situation it has had to face to this day". The CEO is reducing cost so much that he's managing engineers like "supermarket cashiers", he doesn't care about taking the time to train them.

Krzanich is very impatient and eager and keeps changing his mind about projects. If a new architecture isn't created in like a couple weeks, he gives up and cancels the project... he keeps sending contradictory instructions to the teams.

"Fab Hell": Intel is likely going to have a 6 month delay on 10nm. Worse, even Cannon Lake is not expected to feature any significant architectural improvement. Basically Intel was just hoping AMD would keep not competing with them.

Krzanich is apparently a disaster, and he won't be able to stay CEO for long. Apparently some people have heard him yelling from the next building when he was angry. But he seems unaware of him being perceived so negatively. Employees at Intel hope Murthy Renduchintala will replace him ASAP, and he seems much more capable and is slowly refocusing Intel in the right path, but basically R&D is fucked atm and there will be a huge empty space until about 2019. Apparently, Krzanich completely underestimated the possibility of an AMD comeback.

(I didn't really understand that point I'm not expert enough) but apparently x86 is going to disappear sooner than expected, it'll be replaced by ARM and Intel is panicking about that.

Intel is currently working on a "multichip package" (MCM) integrating an Intel CPU and an AMD GPU. So this is confirmed guys.

In the picture before the last picture I posted, it is said that Kaby Lake has exactly the same IPC as Skylake. No improvement as to perf/watt but there seems to be more room for overclocking.
Their conclusion is that if AMD doesn't mess up the launch, "Zen obviously has the necessary capacities to shake up the market..."

Link alle scansioni del giornale francese:

https://www.reddit.com/r/AMD_Stock/c..._there_you_go/

http://imgur.com/a/KOXPd

[Roland74Fun]

Mi pare poco credibile che siano nel panico. Quei virgolettati poi.....