[Thread Ufficiale] Aspettando ZEN

[paolo.oliva2]

Originariamente inviato da bjt2

La differenza di prestazioni non sarà abissale. Anche se Zen dovesse superare Kabylake di poco (compreso clock e turbo superiori e l'autoOC che fa avere clock ancora superiori) ad intel basterebbe abbassare i prezzi e comunque avrebbe il vantaggio di brand e l'inerzia del mercato. AMD deve fare almeno uno sconto del 50% sui prezzi attuali di intel, perchè non ci mettono niente a tagliare il listino del 30-40% il giorno dopo il rilascio di Zen... Mi pare che ai tempi intel abbassò i prezzi del P4 anche del 70%...

Ma guarda... AMD non può certamente rinunciare alla fascia 115X che è enormemente redditizia, non tanto per il margine a procio, quanto per i volumi enormemente superiori alla fascia E, perchè se 1 procio su 100 è E, per avere gli stessi guadagni dovrebbe essere prezzato 100 volte superiore, cosa indubbiamente non attuale, una cosa è Intel, che copre tutta l'offerta con produzione di modelli nativi differenziati, ovviamente non è la stessa cosa per AMD, con BR che copre fino all'i3 e Zen che dovrebbe essere X8 nativo.

Ma il problema di ridurre i prezzi Intel non lo ha per la fascia E, ma il vero problema è la fascia 115X, perchè ha ben 3 modelli racchiusi in 200$, con l'i3 che arriva a punte di 170$ e il top X4+4 che sta sui 370%.
Se AMD come riportano i rumors e come del resto l'ho sempre pensato, proporrà un X8+8 ad un prezzo base equivalente o leggermente più basso di un i7 X4+4, ovviamente il 6700K/7700K dovrà abbassare il prezzo, anche a 250$, il che è perfettamente fattibile per Intel, ma i 200$ che oggi distanziano l'offerta i7/i5/i3, diventerebbero 100$, e chi acquisterebbe un i3 se con 50$ in più potesse acquistare un i5? E chi acquisterebbe un i5 se con 50$ in più acquisterebbe un i7?
Per me o l'i3 o l'5 scomparirebbe dal listino.

[bjt2]

Originariamente inviato da paolo.oliva2

Ma guarda... AMD non può certamente rinunciare alla fascia 115X che è enormemente redditizia, non tanto per il margine a procio, quanto per i volumi enormemente superiori alla fascia E, perchè se 1 procio su 100 è E, per avere gli stessi guadagni dovrebbe essere prezzato 100 volte superiore, cosa indubbiamente non attuale, una cosa è Intel, che copre tutta l'offerta con produzione di modelli nativi differenziati, ovviamente non è la stessa cosa per AMD, con BR che copre fino all'i3 e Zen che dovrebbe essere X8 nativo.

Ma il problema di ridurre i prezzi Intel non lo ha per la fascia E, ma il vero problema è la fascia 115X, perchè ha ben 3 modelli racchiusi in 200$, con l'i3 che arriva a punte di 170$ e il top X4+4 che sta sui 370%.
Se AMD come riportano i rumors e come del resto l'ho sempre pensato, proporrà un X8+8 ad un prezzo base equivalente o leggermente più basso di un i7 X4+4, ovviamente il 6700K/7700K dovrà abbassare il prezzo, anche a 250$, il che è perfettamente fattibile per Intel, ma i 200$ che oggi distanziano l'offerta i7/i5/i3, diventerebbero 100$, e chi acquisterebbe un i3 se con 50$ in più potesse acquistare un i5? E chi acquisterebbe un i5 se con 50$ in più acquisterebbe un i7?
Per me o l'i3 o l'5 scomparirebbe dal listino.

Scompariranno prima i pentium g e, se esistono ancora, i celeron... Gli i3 e i5 bassi saranno i nuovi pentium g...

[conan_75]

Originariamente inviato da bjt2

Scompariranno prima i pentium g e, se esistono ancora, i celeron... Gli i3 e i5 bassi saranno i nuovi pentium g...

Ma quando mai, sono i trattori del mercato cpu.
Più che altro Amd deve piazzare bei prodotti nella fascia 30-80€ perchè è li che si fanno i numeri.

[cdimauro]

Originariamente inviato da bjt2

Hanno fatto un handbrake e zen va il 10% in più... Non so perchè quasi nessuno ne parli...

Forse perché almeno di Blender un file di test l'hanno fornito, mentre per Handbrake nemmeno quello?

Originariamente inviato da bjt2

Senza turbo attivo non faresti vedere comunque il max della CPU. Tutti i test ST, con turbo disattivato, non sarebbero rappresentativi della velocità finale... E se il turbo max fosse 4.5GHz? Capisci che testare il ST a 3.4GHz sarebbe penalizzante...

Quando hanno testato Blender la prima volta hanno impostato il clock a 3Ghz per tutte le macchine, e disattivato il turbo. In questo modo era possibile rilevare l'IPC.

Per cui avrebbero potuto fare esattamente la stessa cosa con un'applicazione ST, e mostrare dunque qualche dato.

Peraltro in tutte le misure di IPC si fa procede proprio come ha fatto AMD col primo test di Blender: clock fisso a 3Ghz e Turbo disattivato.

E' diverso da blender: l'uno è FP e l'altro è int. In uno pareggia, e in un altro lo supera. io sospetto che venga ingorato dai più proprio perchè supera INTEL. E se anche li scatta il turbo, siamo a +10% con 100 mhz di clock in meno...

Handbrake è soltanto un contenitore, che fa uso di librerie esterne per le effettive operazioni di transcodifica.

Librerie come libh264 et similia dovrebbero consentire l'uso di istruzioni SIMD per accelerare parecchie operazioni intensive.

Lo so perché per il mio stage + tesi di laurea ho sviluppato un decoder JPEG 2000 per conto di STMicroelectronic (da implementare poi in hardware. All'epoca si doveva usare un sottoinsieme stretto dell'ANSI C89), per cui so quali operazioni ci sono dietro e quando & in che modo è possibile sfruttare operazioni vettoriali (anche se all'epoca il target era rappresentato dal processore LX di STM che... era un VLIW ).

Con i video ci sono altre operazioni da effettuare (motion compensation, P & B frame, ecc.), che però anch'esse possono essere vettorizzate. Diciamo che il lavoro di un en/decoder JPEG 2000 è molto simile ai calcoli effettuati per i famigerati I frame dei filmati.

Ciò precisato, è vero che è possibile utilizzare la matematica intera a virgola fissa per evitare di usare l'FPU, ma considerato che da parecchi anni qualunque processore è ormai dotato di unità SIMD in grado di utilizzare agevolmente almeno float a 32 bit, personalmente è la soluzione che adotterei.

La motivazione è semplice: con gli interi a virgola fissa sei costretto a eseguire PIU' operazioni per emulare ciò che coi float ottieni automaticamente (l'aggiustamento / normalizzazione dei risultati delle operazioni) in un colpo solo, per cui paradossalmente con gli interi ci sarebbe una perdita prestazionale.

L'unico motivo per cui POTREI (DOPO aver effettuato del sano profiling, ovviamente) optare per la virgola fissa, è se fosse possibile utilizzare interi a 16 bit (8 bit sono del tutto insufficienti allo scopo), ma almeno per JPEG 2000 non era possibile a causa della perdita di precisione dovuta alle operazioni con le wavelet in primis, per cui gli interi a 32 bit erano il minimo necessario.

Questo per la compressione lossy (che è ovviamente quella che ci preme trattare parlando di Handbrake et similia).
Con la compressione lossless il discorso è diverso, e sarebbe persino utilizzare interi a 8 bit per alcune operazioni (e dunque con un'unità SIMD "wide" si potrebbe guadagnare molto). Ma non è questo il caso, per l'appunto.

Originariamente inviato da bjt2

L'algoritmo di scoreboard è difficile da capire per noi umani, ma fidati... E' semplice... La prima volta che lo lessi sul Tanenbaum, mi venne il mal di testa... Ma sono semplicissime regole...

Saranno passati una ventina d'anni almeno, per cui non lo ricordo. Però non è questo il punto, ma mi rendo conto che non sono stato chiaro.

Con catene di dipendenze di cui tenere conto, è difficile pensare di estrarre diverse istruzioni che si possano eseguire in parallelo, nello stesso ciclo di clock. Con un approccio a più scheduler, IMO ciò sarà ancor più penalizzante.

Ovviamente con codice più "lineare", come quello di Blender e Handbrake, il problema si pone di meno. Giusto per intenderci: in un emulatore, dove le catene con mutue dipendenze sono la regola (e non potrebbe essere altrimenti), c'è poca trippa da dare ai gatti: ci saranno ben poche istruzioni eseguite per ciclo di clock.

Guarda che carina questa immagine:

Spettacolare e... utilissima.

Se solo fosse meno veloce, visto che fa girare gli occhi.

Comunque è interessante notare che parecchio lavoro viene fatto PRIMA di schedulare effettivamente le uop da spedire alle specifiche porte, per cui quest'ultimo compito non dovrebbe essere particolarmente complicato.

Vedremo quanto sarà, ma ho il sospetto che sia al max un ciclo...

E' molto probabile.

Non so che senso abbia per AMD fare una cache 2+1 se poi può fare solo 2 operazioni. O lo stack non richiede le agu, oppure, visto che ora le agu sono disaccoppiate dalle ALU, per indirizzamenti semplici non servono...

Ne avevamo discusso in passato. Il punto è che un'operazione di load/store richiede diversi cicli di clock per poter essere finalizzata, visto che potenzialmente si può arrivare fino all'accesso alla DRAM. Per cui piazzare una coda per gestire le richieste ha senso.

Il limite della soluzione di AMD è che non puoi inviare alla coda (o code; non ricordo adesso se ce ne sia una per gestire tutte le richieste, o due) più di 2 operazioni per ciclo di clock, mentre su Intel ne puoi inviare fino a 3.

A seconda di quanto vengano stressate queste unità e/o all'elevato hit rate della cache, questo può essere più o meno penalizzante.

Beh le vecint. Ma immagino che sia complicato fare un codice che al runtime impacchetti più operazioni in una simd, quindi hai ragione... Ma usare vecint come scalare e int si può...

Le vecint si possono usare soltanto implicitamente, SE le usano internamente funzioni come memcpy, memset, strcmp, ecc.. Solo che per alcune di queste funzioni ormai ha più senso usare le famigerate "REP String", visto che da Haswell in più sono state notevolmente accelerate (e peraltro l'approccio SIMD richiede che quelle funzioni siano quasi riscritte per ogni nuova unità SIMD, mentre le REP sono le sostanzialmente le stesse fin dai tempi dell'8086 ).

Ma CPython di per sé non fa esplicito uso di istruzioni SIMD. Per lo meno fino alla versione 3.2, che è l'ultima sulla quale ho messo mano, ma non credo che la situazione sia cambiata, data la natura intrinseca di questa VM.

Utilizzare l'unità SIMD in modalità scalare si potrebbe (ma solo per i float: per gli int non ha senso, fatta eccezione per i casi di cui sopra), ma considerato l'uso sporadico che si fa dei calcoli in virgola mobile in Python, penso che la vecchia FPU x87 dovrebbe far bene il suo sporco lavoro, consentendo tra l'altro di utilizzare funzioni trascendentali e trigonometriche che mancano quasi del tutto alle unità SIMD moderne.

Quella è una nostra deduzione contando i pixels... E poi non sappiamo se si riferisce all'8150, 8350, 8370 o al 9570 (o quello che è con clock 4.7/5)...

Se il confronto non è stato fatto clock-for-clock, allora lascia il tempo che trova, e sarebbe persino più penalizzante per Zen, che non credo raggiungere le frequenze di BD & compagnia.

Beh ma uno è 1x4 vie e quindi deve controllare fino a 4x<profondità coda> uop per ciclo e l'altro sono 6 scheduler che devono controllare una sola istruzionex<profondità coda> per ciclo... Io credo che il compito sia più semplice... Non sto parlando del numero totale di transistors, che può anche essere superiore, ma del FO4. Una struttura complessa, contro 6 semplici. I transistors possono pure essere di più, ma non credo il FO4...

Però le 6 uop le devi anche spedire nelle apposite 6 code, e devi anche garantire che debbano essere indipendenti (rispetto a quelle inserite nella specifica coda).

Ma infatti ti ho detto che l'algoritmo scoreboard è una cavolata... Procurati il Tanenbaum "Structured computer organization", ad esempio, oppure online cercando scoreboard scheduling algorithm:

https://en.wikipedia.org/wiki/Scoreboarding
http://www.cs.umd.edu/class/fall2001...coreboard.html
http://euler.mat.uson.mx/~havillam/c...cs-323011.html

E' più difficile spiegarlo e capirlo, che eseguirlo... E gli automi sono bravissimi ad eseguire compiti ripetitivi senza capirli...

Sì, ma qui mi riferivo ad altro.

L'analisi della composizione delle porte mi porta a pensare a una certa (notevole) semplificazione dello scheduler/dispatcher. Ed è una cosa che non riguarda soltanto Haswell e successori, che hanno soltanto migliorato la situazione (aggiungendo un paio di porte).

Ma bisogna rifletterci su un po' per capirlo.

[cdimauro]

Originariamente inviato da bjt2

Io penso che su codice non 256 bit (e quindi tutti i legacy), siamo tra broadwell e skylake come IPC, e quindi si può recuperare con il clock.

Con AES dovremmo essere superiori, perchè Zen ha 2 unità AES per core nella FP e anche con minore latenza, mentre i core una sola per core.

Solo con AES, perché per il resto non mi sembra che l'unità SIMD sia messa così bene in termini di throughput e/o latenza.

Originariamente inviato da paolo.oliva2

Nessuno lo mette in dubbio questo, ma rendiamoci conto di una cosa:

Tu vedi fibrillazione dei fanboy AMD tipo Zen va di più di Intel e quindi i fanboy Intel si sentono attaccati e di qui che vanno in difesa?

Oppure vedi una situazione in cui Zen pompa e ai fanboy Intel gli tira e non vogliono assolutamente manco ipotizzare che Zen arrivi vicino? E di qui è tutto un corollario tra frequenze non veritiere, consumi idem, software partigiano e quant'altro.

E siccome TUTTI sappiamo che i prezzi Intel sono gonfiati, allora AMD NON PUO' applicare oltre un -20% sui prezzi rispetto a quelli Intel, ma siccome in tutto il WEB di tutto il mondo non c'è una persona che non riporti che AMD i prezzi li applicherà più bassi, ovviamente Zen DEVE andare meno del 6900K almeno nell'esatta proporzione di quanto costerà meno.

Giusto per essere imparziali... Qualcuno pensa che Zen X8+8 costerà a partire da 800$? Perchè già a 800$ sarebbe maggiore del -20%, ma nessuno qua penso che ipotizzi Zen X8+8 = 6850K.

Io sono filo AMD, non lo nego... ma faccio molta fatica a ipotizzare quanto ho scritto come di parte e invece razionale la critica.

E basta con questo vittimismo infantile.

Originariamente inviato da digieffe

@Cesare

peccato per la cache L1 di soli 32k. 64k avrebbero potuto, genericamente, velocizzare molto gli emulatori (più spazio per il codice ed i dati dell'arch. emulata).

Dipende anche dalla latenza, dall'associatività, e dal numero di TLB della cache: la sola dimensione non basta per giudicare la bontà di una cache.

Originariamente inviato da bjt2

Non sono sicuro che sia int, ma per la codifica/decodifica mpeg4/h26x è possibile usare gli int, come fixed point float. 16 bit dovrebbero bastare.
E poi va a oltre 60fps tra decodifica e codifica, un buon risultato. Quindi non credo usino i float... Probabilmente usano le simd...

Secondo questo thread http://forum.doom9.org/showthread.php?t=75095 almeno l'h264 fa la DCT in intero, perciò penso che sia così per tutto...
Usando un numero di bit sufficienti si fa un fattore di scala fisso, magari potenza di due, così la riconversione ad intero è solo uno shift...

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

Quella era l'implementazione dei poveri...

Prendendo FFMPEG, che non credo abbia bisogno di presentazioni:
https://ffmpeg.org/doxygen/2.8/dct_8c_source.html
https://ffmpeg.org/doxygen/2.8/avfft...ce.html#l00035
In particolare:

typedef float FFTSample;

Direi che le routine e il typedef si commentino da soli.

Originariamente inviato da bjt2

Qui c'è un post di quello che sembra Charlie di semiaccurate (il capoccia), che risponde a Torvalds e dice che gli ultimi sample che aveva erano solidi (ma non fully featured, quindi magari il turbo o altro erano disabilitati) e che aspetta la versione finale. Inoltre dice che fino agli A1 e successivi erano pieni di bug... Chissà quanti ES hanno fatto...

Mi pare normale: servono diversi tapeout per ottenere un chip pronto alla commercializzazione.

Originariamente inviato da bjt2

Leggendo oltre si dice anche che lo store/load forwarding fatto nel front end ti fa proprio bypassare AGU, L/S e L1... Quindi non si consumano neanche slot AGU/ex/L1...

Ma quello è solo per il memory disambiguation: poi l'operazione deve andare avanti lo stesso.

Inoltre finalmente Zen ha la move elimination come le INTEL...

Occhio che per l'unità SIMD esistono PARECCHIE istruzioni di MOVE (e load/store, in generale), ma soltanto una può essere eliminata con un register rename.

Originariamente inviato da Piedone1113

Se qualcuno continua a dirti che AMD non sa fare cpu perchè negli ultimi 10 anni ha sempre cannato, non ti inalberi (più per discorso logico, come se AMD invece di essere un produttore di semiconduttori fosse un produttore di caffe improvvisatasi produttore di cpu)?
Bene se reputi non vero un dato oggettivo recente e continuato (ultimi 10 anni) perchè continui ad insinuare che Intel potrebbe continuare a pagare mazzette per la vendita delle sue cpu (per un fatto avvenuto oltre 10 anni fa e che non c'è nessun sentore che questo si sia perpretato fino ad oggi)?
Fin quando non ci sono prove di illeciti Intel è moralmente (oltre che legalmente) sbagliato infamarla (cosa che probabilmente senza volerlo direttamente hai fatto).
Considerala come Maria Maddalena che da sgualdrina si è convertita e comportata secondo le leggi religiose del tempo.
Con questo non voglio dire che intel non lo farà mai più, ma non possiamo accusare Intel di nulla solo perchè potrebbe farlo di nuovo.
Come se chiamassi una persona ladra perchè potrebbe rubare (e tutti noi abbiamo la possibilità di rubare).
Assodato che Intel ha raggiunto un accordo per un illecito, che è stata condannata per tale illecito (e che tutta la faccenda è stata trattata in modo semplicistico perchè dovrebbero essere considerati complici tutti gli oem che difatti erano in combutta con intel trattandola in questo modo) puoi portare prove (o voci fondate) della volontà di intel di rifare lo scherzo?
Per un attimo considera Cesare come dipendente BMW e non Intel (da gennaio lo sarà) e rileggi quello che ha scritto.
Non ti sembrano logici e veritiere le sue considerazioni (magari un poco enfatizzate su alcuni punti per via delle sue simpatia personali)?
Credo che la maggioranza degli utenti che postano su questo th abbiano un età sopra i 40, non comportiamoci da bambini dell'asilo su discussioni da curva sud dello stadio pure mezza ubriaca.

*

Solo un piccolo appunto: Maria Maddalena NON era una prostituta. Questa nomea (con chiaro fine dispregiativo della figura femminile) è stata creata ad arte dai cattolici, e in particolare sancito da papa Gregorio Magno.

Tutto rientra nella continua opera di cambiamento della figura femminile, che doveva diventare subalterna a quella maschile, e che ha origini lontane nel tempo. Sono presenti, infatti, diverse modifiche ai testi "sacri", introdotte proprio con questo scopo, mentre nel proto-cristianesimo / cristianesimo delle origini, le donne avevano un ruolo ben diverso da quello che ci è poi stato consegnato dalla "tradizione".

Originariamente inviato da bjt2

Sentendo l'audio in una entry del BTB ci sono due branch per questioni di risparmio energetico: con un solo load ti leggi 2 branch. Non specifica se sono uno per thread ma suppongo che debbano essere dello stesso thread perchè l'accesso alla BTB si fa con l'indirizzo dell'istruzione e quindi penso che siano 2 salti per blocco, es di 16 o 32 bytes. Con il vecchio sistema di 1 salto per BTB se i salti erano troppo vicini, non c'era spazio nel btb e i salti oltre il primo non venivano messi del btb e quindi penso predetti solo staticamente, invece con 2 salti per btb entry, i salti possono essere più vicini...

La compressione dei salti, con relativa minor occupazione nella BTB, è stata già introdotta da Intel parecchio tempo fa, e non mi pare sia limitata a 2 soli salti "corti".

Per il resto 2 jump sullo stesso thread non mi pare plausibile. Immagino che le 2 unità di branch siano utilizzate dai 2 thread.

Originariamente inviato da bjt2

Un ciclo con poche (max 2) uop. A ogni ciclo devi fare un jump all'indietro. Se il loop è nella uop cache puoi riuscire a fare anche 2 iterazioni/ciclo

Oppure due salti molto vicini in una catena di if-then correttamente predetti

Se c'è una catena di if, è chiaro che il secondo branch debba aspettare il risultato finale del primo. Ecco perché non credo che si possano eseguire due branch contemporaneamente sullo stesso thread.

Originariamente inviato da Gioz

premesso che i dubbi sui consumi che avanzi li ho anche io, almeno in parte perchè non mi pare così evidente il distacco tra le due piattaforme e non mi pare allineatissimo a recensioni viste(però non dispongo di configurazione con cui far paragoni e quindi evito di pronunciarmi), mettere due titan X in SLi, a prescindere dall'utilizzo e/o gaming, credo sia solo per fare intuire che proporranno quella cpu per configurazioni gaming di massimo livello (e in quest'ottica vedo le Titan anziché delle Vega perché la gente ad oggi fa riferimento a quelle schede pensando al massimo).

In ottica gaming lo posso capire, a parte per la cattiva pubblicità che si fa AMD a usare le schede della concorrenza.

Ma per gli altri test, no.

spezzerei anche una lancia in favore di cdimauro, io trovo abbia sempre cercato di dare una giustificazione alle sue affermazioni spiegando la ragione del suo pensiero e riportando questioni tecniche plausibili, poi va bhè gli scontri personali e le digressioni politicanteggianti andrebbero evitate.

*

Originariamente inviato da suneatshours86

la parte bella è che sei talmente ottuso anche nel modo di esprimerti che utilizzi il termine grillini come termine dispregiativo (credo sia già la 2° volta che te lo sento dire). Questo la dice lunga sul tuo modo di fare e di pensare. Additare qualcuno per la propria tendenza politica che sia grillino, che sia del pd o che sia di salvini non centra con zen non centra con il topic. Poi se vuoi continua pure ma se una volta ero dell'idea che tu potessi anche solo minimamente portare un contributo al thread devo ricredermi. Ignore list, funziona! hai ragione

Potevi evitarti di scrivere il resto della pappardella, a questo punto.

Ma evidentemente ti bruciava troppo e dovevi uscirtene con la classica ondata di fango, altrimenti il tuo ego violato ne avrebbe risentito.

Comunque tranquillo che non entro nel merito: ho ben altro da fare.

Originariamente inviato da bjt2

COLPO DI SCENA!

La famosa build beta di blender, con avx2, 256 bit e altre ottimizzazioni che fa guadagnare 40% su haswell e 60% su skylake, su carrizo fa guadagnare... Il 100% Praticamente il tempo dimezza... Quindi quella build è più veloce semplicemente perchè è più ottimizzata... Carrizo probabilmente ne beneficia per la FPU bella cicciotta e l'architettura con FPU a coprocessore (che ha anche zen)... Quindi anche zen ne dovrebbe beneficiare...

https://forums.anandtech.com/threads...#post-38632293

Non credo: Zen ha una FPU diversa, e divisa in 4 unità a 128 bit. E implementa SMT e non CMT.

Comunque aspettiamo di vedere finalmente qualche test con le AVX/-2.

[conan_75]

Originariamente inviato da Gioz

sui consumi hai ragione, ma sul rumore non sono del tutto d'accordo.
basta un dissipatore a torre da 30€ con una ventola anche solo decente, tipo l'artic a30/i30 che è inudibile...mentre riguardo al dissi stock a mio avviso contano più il case ed il ricircolo che non la ventola del dissipatore stesso, spesso è molto rumoroso perché li ficcano in case piccoli mal gestiti sul fronte dell'aerazione e ci si ritrova con una t case relativamente alta che obbliga la ventola cpu ad operare ad alto regime...e non è neanche una questione case economico vs case costoso, dato che ce ne sono di molto scadenti a bassissimo prezzo che comunque permettono di gestrie bene questo aspetto.

Ormai i big tower sono quasi scomparsi, li compra solo lo smanettone.

Io ti posso dire che in un case da 3L ci ho messo un i5 6500. Il dissipatore è alto 3cm con una singola ventola da 92 che gira tra zero (idle e web) e 800/1000rpm con carico.
Non ho altre ventole perchè non serve ricircolo.
Non ho neanche alimentatore, mi basta un pico con un brick da notebook.
Sotto carico ho un totale che non arriva a 80w.
Tutto questo con una potenza di calcolo significativa.

Dei processori con n mila core il mercato se ne fa poco e di certo non si può usare questo forum come statistica.
Amd deve creare cpu con rapporto consumi/prestazioni di fascia media e bassa se vuole risollevarsi.
E soprattutto servono APU di nuova generazione.

[Ryddyck]

Originariamente inviato da cdimauro

Forse perché almeno di Blender un file di test l'hanno fornito, mentre per Handbrake nemmeno quello?

È possibile replicare anche handbrake, il file utilizzato è quello di big buck bunny tagliato a 60 secondi. L'avevo scritto qualche post fa...

[bjt2]

Originariamente inviato da cdimauro

Forse perché almeno di Blender un file di test l'hanno fornito, mentre per Handbrake nemmeno quello?

Quando hanno testato Blender la prima volta hanno impostato il clock a 3Ghz per tutte le macchine, e disattivato il turbo. In questo modo era possibile rilevare l'IPC.

Per cui avrebbero potuto fare esattamente la stessa cosa con un'applicazione ST, e mostrare dunque qualche dato.

Peraltro in tutte le misure di IPC si fa procede proprio come ha fatto AMD col primo test di Blender: clock fisso a 3Ghz e Turbo disattivato.

Si certo, potevano fare così... Ma se era migliore, allora non l'hanno fatto per nascondersi. Se era peggiore, non lo hanno fatto per non smerdarsi... In entrambi casi la strategia di non farlo è la migliore: si ha un single thread di Shroedinger ...

Originariamente inviato da cdimauro

è soltanto un contenitore, che fa uso di librerie esterne per le effettive operazioni di transcodifica.

Librerie come libh264 et similia dovrebbero consentire l'uso di istruzioni SIMD per accelerare parecchie operazioni intensive.

Si lo sapevo che era un contenitore... ) Ed ho linkato un thread su un forum dove si dice che le librerie H264, persino nella DCT e IDCT le fanno in intero...

Originariamente inviato da cdimauro

Lo so perché per il mio stage + tesi di laurea ho sviluppato un decoder JPEG 2000 per conto di STMicroelectronic (da implementare poi in hardware. All'epoca si doveva usare un sottoinsieme stretto dell'ANSI C89), per cui so quali operazioni ci sono dietro e quando & in che modo è possibile sfruttare operazioni vettoriali (anche se all'epoca il target era rappresentato dal processore LX di STM che... era un VLIW ).

Con i video ci sono altre operazioni da effettuare (motion compensation, P & B frame, ecc.), che però anch'esse possono essere vettorizzate. Diciamo che il lavoro di un en/decoder JPEG 2000 è molto simile ai calcoli effettuati per i famigerati I frame dei filmati.

Ciò precisato, è vero che è possibile utilizzare la matematica intera a virgola fissa per evitare di usare l'FPU, ma considerato che da parecchi anni qualunque processore è ormai dotato di unità SIMD in grado di utilizzare agevolmente almeno float a 32 bit, personalmente è la soluzione che adotterei.

La motivazione è semplice: con gli interi a virgola fissa sei costretto a eseguire PIU' operazioni per emulare ciò che coi float ottieni automaticamente (l'aggiustamento / normalizzazione dei risultati delle operazioni) in un colpo solo, per cui paradossalmente con gli interi ci sarebbe una perdita prestazionale.

L'unico motivo per cui POTREI (DOPO aver effettuato del sano profiling, ovviamente) optare per la virgola fissa, è se fosse possibile utilizzare interi a 16 bit (8 bit sono del tutto insufficienti allo scopo), ma almeno per JPEG 2000 non era possibile a causa della perdita di precisione dovuta alle operazioni con le wavelet in primis, per cui gli interi a 32 bit erano il minimo necessario.

Questo per la compressione lossy (che è ovviamente quella che ci preme trattare parlando di Handbrake et similia).
Con la compressione lossless il discorso è diverso, e sarebbe persino utilizzare interi a 8 bit per alcune operazioni (e dunque con un'unità SIMD "wide" si potrebbe guadagnare molto). Ma non è questo il caso, per l'appunto.

Saranno passati una ventina d'anni almeno, per cui non lo ricordo. Però non è questo il punto, ma mi rendo conto che non sono stato chiaro.

Tutto interessante Mi sono dilettato con matlab a fare un compressore di immagini che non sia limitato a blocchi 8x8 o 16x16, ma faccia la DCT di tutta l'immagine, zigzag coding, quantizzazione, huffman coding e poi compressione con la gzip della VM java fornita con matlab...

Credo che persino xvid usi gli interi... Ho iniziato a interessarmi perchè ho ricodificato dei video che avevo per risparmiare spazio e mi sono messo un po' a ottimizzare i parametri e fare ricerca... XVID ha scarse prestazioni sulle parti scure, segno che usa troppi pochi bit, mentre H264 ha poca solarizzazione. Forse usano 16 o 32 bit...

Originariamente inviato da cdimauro

Con catene di dipendenze di cui tenere conto, è difficile pensare di estrarre diverse istruzioni che si possano eseguire in parallelo, nello stesso ciclo di clock. Con un approccio a più scheduler, IMO ciò sarà ancor più penalizzante.

Ovviamente con codice più "lineare", come quello di Blender e Handbrake, il problema si pone di meno. Giusto per intenderci: in un emulatore, dove le catene con mutue dipendenze sono la regola (e non potrebbe essere altrimenti), c'è poca trippa da dare ai gatti: ci saranno ben poche istruzioni eseguite per ciclo di clock.

E' chiaro che questo fa perdere in IPC, ma se hai più code e non condivise, può darsi che recuperi comunque rispetto ad intel... L'importante è salire di più... E anche lo shceduler FP è stato splittato, come ho scritto ieri...

Originariamente inviato da cdimauro

Le vecint si possono usare soltanto implicitamente, SE le usano internamente funzioni come memcpy, memset, strcmp, ecc.. Solo che per alcune di queste funzioni ormai ha più senso usare le famigerate "REP String", visto che da Haswell in più sono state notevolmente accelerate (e peraltro l'approccio SIMD richiede che quelle funzioni siano quasi riscritte per ogni nuova unità SIMD, mentre le REP sono le sostanzialmente le stesse fin dai tempi dell'8086 ).

Le REP mi sono sempre piaciute... Sono contento che siano state fatte prestanti... Basta un po' di microcodice per la testa e per la coda e poi via con un loop di 128/256/512 bit a seconda dell'architettura... Unico codice che va bene per tutti e occupa pochissima L1I...

Originariamente inviato da cdimauro

Se il confronto non è stato fatto clock-for-clock, allora lascia il tempo che trova, e sarebbe persino più penalizzante per Zen, che non credo raggiungere le frequenze di BD & compagnia.

Però le 6 uop le devi anche spedire nelle apposite 6 code, e devi anche garantire che debbano essere indipendenti (rispetto a quelle inserite nella specifica coda).

Sì, ma qui mi riferivo ad altro.

L'analisi della composizione delle porte mi porta a pensare a una certa (notevole) semplificazione dello scheduler/dispatcher. Ed è una cosa che non riguarda soltanto Haswell e successori, che hanno soltanto migliorato la situazione (aggiungendo un paio di porte).

Ma bisogna rifletterci su un po' per capirlo.

Beh come sopra: perdi un po' di IPC, guadagni clock e con tutte le porte che hai forse recuperi anche tutto quello che perdi... E le prestazioni ci dicono che forse è così...

[bjt2]

Originariamente inviato da cdimauro

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

Quella era l'implementazione dei poveri...

Prendendo FFMPEG, che non credo abbia bisogno di presentazioni:
https://ffmpeg.org/doxygen/2.8/dct_8c_source.html
https://ffmpeg.org/doxygen/2.8/avfft...ce.html#l00035
In particolare:

typedef float FFTSample;

Direi che le routine e il typedef si commentino da soli.

Ok, come non detto...

Originariamente inviato da cdimauro

Se c'è una catena di if, è chiaro che il secondo branch debba aspettare il risultato finale del primo. Ecco perché non credo che si possano eseguire due branch contemporaneamente sullo stesso thread.

Mi riferivo in fase di predizione: in genere si può predirre anche una serie di salti senza aspettare che si sappia il risultato dei precedenti... Invece di predirli in 2 cicli separati, se sono vicini li si predice in un ciclo solo... Immagina dei for innestati... A fine ciclo predici che torna indietro, in un solo ciclo, anche 2 for. Nella maggior parte delle volte ha ragione il predittore...

Originariamente inviato da cdimauro

Non credo: Zen ha una FPU diversa, e divisa in 4 unità a 128 bit. E implementa SMT e non CMT.

Comunque aspettiamo di vedere finalmente qualche test con le AVX/-2.

Non ha le FMAC. Ma può fare 4 operazioni semplici contro le 2 della FPU di Excavator che ne può fare 2, più una pipe per le vecint. Se non ci sono fmac siamo in vantaggio. Se ci sono, siamo in pari. Vedremo...

Per intenderci: la FPU di excavator può fare 2 fmac a 128 bit più una vecint. Oppure 2 fadd o 2 fmul. La FPU di zen può fare 2 fadd E 2 fmul oppuyre 2 fmac... E' anche meglio se non si usano le fmac...

[bjt2]

Originariamente inviato da gridracedriver

intendevo dire il decoder e non le porte di esecuzione, dice "complex decoder" → 1-2 e i "decoder" semplici → 1 (x3), quindi come si legge? che può fornire 3+2 complex o 3+3 complex? se fosse 1-1-1-2(1) quindi sarebbe un 5(4+1) wide???

Beh credo che sia il solito burst 4-1-1-1(-1) dove quello tra parentesi può essere fatto solo nel branch fusion. 1 complessa, fino a 4 uop ciclo più 3(+1) semplici. Se sono tutte semplici sono 4+1...

[paolo.oliva2]

@cdimauro

Secondo me ti impunti troppo sul fatto di quello che AMD non fa ancora vedere (tipo clock massimo turbo) imputandolo che non esiste. Un test ST vs Intel è perfettamente inutile se lo fai a 3,4GHz contro Intel che può arrivare a 4,5GHz, quindi se lo fai scopri le massime frequenze turbo, cosa che sembra AMD non voglia far vedere (tutti gli ES forniti chissà perchè hanno il turbo disattivato, non penso che un procio che al max tra 3 mesi sarebbe in commercio (questa è l'ufficialità, che faccia comodo o meno) possa essere a questo stadio, oltre al fatto che si è saputo che tutti gli ES visti fino ad ora sono A0, mentre ad agosto erano A1 (mai visti) e dopo 6 mesi non credo che non ce ne siano di nuovi. Quello fatto vedere a New Horizon, tu sai quale step era? A0, A1, A1X o A2? Io non lo so...

Non puoi fare una similitudine tra Zen che come X8+8 va a 3,4GHz consumando quanto il 6900K def (e fino ad ieri il 6900K a def era sotto i 100W) e su questo riportare che i 3,4GHz sarebbero la massima frequenza.

Ti puoi nascondere dietro al fatto che finchè non vedi non ci credi, al più si può mettere in dubbio QUANTO scali e a che frequenza massima potrà arrivare, ma non ha alcun senso impuntarsi sui 3,4GHz perchè quella è la massima frequenza vista.

Tu come lo giudichi bambinismo infantile, lamentarsi dell'ottusità o continuare a far credere cose irreali spalmando merda? Cacchio... fino ad ieri non mi davate del visionario, spara cazzate e che vivo su un altro pianeta perchè Zen avrebbe avuto più frequenza del 6900K? E no... manco serve che Lisa Su dica 3,4GHz+, hanno barato a New Horizzon, non può esistere che AMD abbia più frequenza di Intel.

[conan_75]

Originariamente inviato da paolo.oliva2

@cdimauro

Secondo me ti impunti troppo sul fatto di quello che AMD non fa ancora vedere (tipo clock massimo turbo) imputandolo che non esiste. Un test ST vs Intel è perfettamente inutile se lo fai a 3,4GHz contro Intel che può arrivare a 4,5GHz, quindi se lo fai scopri le massime frequenze turbo, cosa che sembra AMD non voglia far vedere (tutti gli ES forniti chissà perchè hanno il turbo disattivato, non penso che un procio che al max tra 3 mesi sarebbe in commercio (questa è l'ufficialità, che faccia comodo o meno).

Non puoi fare una similitudine tra Zen che come X8+8 va a 3,4GHz consumando quanto il 6900K def (e fino ad ieri il 6900K a def era sotto i 100W) e su questo riportare che i 3,4GHz sarebbero la massima frequenza.

Ti puoi nascondere dietro al fatto che finchè non vedi non ci credi, al più si può mettere in dubbio QUANTO scali e a che frequenza massima potrà arrivare, ma non ha alcun senso impuntarsi sui 3,4GHz perchè quella è la massima frequenza vista.

Tu come lo giudichi bambinismo infantile, lamentarsi dell'ottusità o continuare a far credere cose irreali spalmando merda?

Ma dai tempo al tempo; il prodotto arriverà in mano ai recensori e se ne vedranno la potenzialità.
Di certo amd ha mostrato il meglio possibile.
Attendiamo di vedere il resto.

[Gioz]

Originariamente inviato da conan_75

Ormai i big tower sono quasi scomparsi, li compra solo lo smanettone.

Io ti posso dire che in un case da 3L ci ho messo un i5 6500. Il dissipatore è alto 3cm con una singola ventola da 92 che gira tra zero (idle e web) e 800/1000rpm con carico.
Non ho altre ventole perchè non serve ricircolo.
Non ho neanche alimentatore, mi basta un pico con un brick da notebook.
Sotto carico ho un totale che non arriva a 80w.
Tutto questo con una potenza di calcolo significativa.

Dei processori con n mila core il mercato se ne fa poco e di certo non si può usare questo forum come statistica.
Amd deve creare cpu con rapporto consumi/prestazioni di fascia media e bassa se vuole risollevarsi.
E soprattutto servono APU di nuova generazione.

non è necessario un big tower per avere prese d'aria intelligenti.
sul consumo ti do ancora una volta ragione come ho fatto precedentemente, ma per la rumorosità e la funzionalità del dissipatore no, dipende più da come assembli la macchina e gestisci il flussi, senti sempre dire che quello stock fa schifo solo perché tendenzialmente la gente vorrebbe clockare a 5GHz la cpu e quello non ce la fa, se usi il sistema a default con le funzionalità di risparmio energetico per un htpc è accettabilissimo e se proprio basta un dissipatore economico per migliorare ulteriormente la cosa.
i processori con n mila core sono d'accordo che non servono a prescindere, così come concordo con te sul fatto che sono le cose economicamente più abbordabili a tirare il mercato consumer, e le apu il prodotto di punta(tra portatili e pc del supermercato).

ognuno guarda giustamente alle proprie esigenze oltre al fatto che i pochi dati emersi sono relativi ad una cpu top di gamma e quindi tutte le ipotesi che ne conseguono in questa sede sono per ovvie ragioni correlate a quella, seppur derivando in alcuni casi congetture sulle categorie più basse.
se fanno un prodotto che risponde alle mie esigenze ed ha un prezzo che trovo interessante allora ben venga.

[paolo.oliva2]

Originariamente inviato da conan_75

Ma dai tempo al tempo; il prodotto arriverà in mano ai recensori e se ne vedranno la potenzialità.
Di certo amd ha mostrato il meglio possibile.
Attendiamo di vedere il resto.

Ma se AMD riporta 3,4GHz+ come frequenza def, ha senso continuare ancora a dire che i 3,4GHz sarebbero la massima frequenza raggiungibile da Zen?

Cerchiamo di capirci... ci sono rumor, sono rumors, ci fono fonti ufficiali quali Lisa Su che lo dice, non va bene ugualmente, si deve mettere in dubbio perchè finchè non si vede non si crede. Tu ci credi che il 7700K esce? L'ha detto Intel... e se era un 6700K con logo diverso? E se ha mentito sul 14nm+? Io non vedo differenze... e se e se e se? Cacchio, se parla il Ceo e Presidente di una azienda, è ufficiale e io ci credo... di qualsiasi azienda... qui si mette in dubbio o no quanto ha detto Lisa Su? E per cosa? per 4 idioti che vedono solo Intel e gli altri sono merda?

Per quanto evidenziato, anche io sono certo, ma in che ambito? MT su tutti e 8 i core. Puoi estrapolare la massima frequenza turbo con meno di 8 core? La cosa più ovvia è che SICURAMENTE sarà maggiore di quella che ha fatto vedere su 8 core, quindi se 3,4GHz è la massima frequenza che ha fatto vedere, non credo che sia la frequenza massima possibile, no?

P.S. Edit.
Cerchiamo di fissare un punto. AMD ha la posizione ufficiale che Zen uscirà sul mercato nel 1° trimestre 2017. Ciò vuol dire entro il 31 marzo 2017.
Abbiamo quindi 2 situazioni:
1) AMD ha fatto vedere quanto possibile.
2) AMD ha fatto vedere quanto necessario.

Le caratteristiche di Zen con modelli e prezzi si sapranno al momento del lancio, pressochè solamente 3 mesi di tempo tra arrivare all'evoluzione Zen pronta per la produzione in vlumi ed il tempo necessario al confezionamento... sono compatibili con il punto 1 o punto 2?
Far vedere Zen che è arrivato a 3,4GHz, era necessario per far vedere che rispetto al 1° confronto Zen ha guadagnato 400MHz, ed era necessario (per il marketing) dimostrare che Zen è superiore al 6900K def (mentre nel 1° confronto era downcloccato). Questo è marketing, e non metto minimamente in dubbio che hanno fatto vedere nel modo più conveniente.
Però io non vedo una dimostrazione di Zen su "quanto possibile" ma più su "quanto necessario", perchè ad esempio OC, ST, e similari lo avrebbero potuto comunque fare.

Quindi comunque se già consideriamo 3,5GHz massimi def per un X8, saremmo al +3% rispetto alla demo di Zen a 3,4GHz... rimane pur sempre fuori sia il turbo su tutti i core che il turbo sul numero più basso dei core... che sarà sicuramente superiore a 3,5GHz def X8.

[Ryddyck]

Sii obiettivo, un paio di giorni fa lo "presentano" a 3.4 GHz+ e dovrebbero commercializzarlo nel primo trimestre con presentazione forse al ces2017.
Quanto tempo avrebbero per produrne uno con una frequenza maggiore stabile in volumi, considerando sempre da rumor che chi l'ha avuto tra le mani mancava di feature e aveva dei bug?

[george_p]

Originariamente inviato da gridracedriver

intendevo dire il decoder e non le porte di esecuzione, dice "complex decoder" → 1-2 e i "decoder" semplici → 1 (x3), quindi come si legge? che può fornire 3+2 complex o 3+3 complex? se fosse 1-1-1-2(1) quindi sarebbe un 5(4+1) wide???



ma il problema è alla fonte, i media italiani che sono al 77° posto nel mondo come libertà e trasparenza d'informazione o giù di li, hanno iniziato a chiamare grillini chi vota 5 stelle e adesso laggente continua su questa rotta... io non capisco, il fatto che uno si senta più vicino al 5s non vuol dire che gli vada bene tutto quello che facciano o che dice grillo... mi chiedo, oggi in italia e guardando dal 90 in poi, ma chi caxxo dovrei votare uno che si faceva le leggi ad personam per non andare dentro? uno che vuole usare le ruspe dappertutto? un fantoccio che vende pentole a suon di 80 € come voto di scambio e che oltretutto ora ci ritroviamo con un governo di SURROGATI e PRESTA NOME... siamo il paese più ridicolo del G7 e del vecchio continente "ricco"...

Ha sempre funzionato così.
O sei con loro o sei contro di loro, e in questo periodo storico essere contro di loro vuole dire essere grillini.

Ragionano così, come con sistema binario, dove esistono solo due numeri "uno" e "zero". Se parli con il signor "uno" e ti esprimi con una idea diversa dalla sua sei per forza uno "zero" e, naturalmente, viceversa. Non arrivano a pensare possa esserci un pensiero o un idea che è libera dal colore del partito.
Hanno bisogno necessariamente di crearsi un nemico e meccanicamente associano chiunque diverso da loro a quel loro nemico.



@bjt2: pensi che tra un mese con la presentazione del CES amd avrà per tempo un sample molto prossimo al processore definitivo? Se non addirittura definitivo?

[conan_75]

Originariamente inviato da paolo.oliva2

Ma se AMD riporta 3,4GHz+ come frequenza def, ha senso continuare ancora a dire che i 3,4GHz sarebbero la massima frequenza raggiungibile da Zen?

Cerchiamo di capirci... ci sono rumor, sono rumors, ci fono fonti ufficiali quali Lisa Su che lo dice, non va bene ugualmente, si deve mettere in dubbio perchè finchè non si vede non si crede. Tu ci credi che il 7700K esce? L'ha detto Intel... e se era un 6700K con logo diverso? E se ha mentito sul 14nm+? Io non vedo differenze... e se e se e se? Cacchio, se parla il Ceo e Presidente di una azienda, è ufficiale e io ci credo... di qualsiasi azienda... qui si mette in dubbio o no quanto ha detto Lisa Su? E per cosa? per 4 idioti che vedono solo Intel e gli altri sono merda?

Guarda, sul 7700 non mi esprimo perchè non è nella fascia di mio interesse.
Trovo più interessante la fascia economica (celeron/pentium) che guadagna mhz ed una gpu più completa.
Ha più senso il salto da un pentium g 4500 al sostituto kabi lake che non da 6700k al 7700k.
Inoltre ho visto ottime cpu ulv.

Tornando in tema su quello che dice Lisa Su mi ci pulisco platealmente il , idem per il CEO Intel.
Solo un fanboy può credere ciecamente a questi proclami.
Attendo quello che dice hwupgrade, tom's, anand etc.

Gli ho visti ancora in alto mare con frequenze ad alcune funzionalità.
Servirà tempo per passare alla produzione e conseguente vendita in volumi, probabilmente aprile/maggio. Ricordati questa mia frase

[conan_75]

Originariamente inviato da Gioz

ognuno guarda giustamente alle proprie esigenze oltre al fatto che i pochi dati emersi sono relativi ad una cpu top di gamma e quindi tutte le ipotesi che ne conseguono in questa sede sono per ovvie ragioni correlate a quella, seppur derivando in alcuni casi congetture sulle categorie più basse.
se fanno un prodotto che risponde alle mie esigenze ed ha un prezzo che trovo interessante allora ben venga.

Ah d'accordissimo
Io ho esigenze sicuramente particolari, per dire non uso cpu ulv ma ormai sono loro a padroneggiare nella vendita.
Notebook, 2in1, micro sistemi stile nuc etc.

Credo ci sia tanta domanda nella fascia 10-25w tdp.

[paolo.oliva2]

Originariamente inviato da Ryddyck

Sii obiettivo, un paio di giorni fa lo "presentano" a 3.4 GHz+ e dovrebbero commercializzarlo nel primo trimestre con presentazione forse al ces2017.
Quanto tempo avrebbero per produrne uno con una frequenza maggiore stabile in volumi, considerando sempre da rumor che chi l'ha avuto tra le mani mancava di feature e aveva dei bug?

E' proprio questo che faccio risaltare.
E' possibile che si viene a sapere che di Zen hanno fatto l'A0 e che l'A1 era già di agosto e sempre ad agosto ci sono arrivate le info dell'ES A0 di marzo?
C'è o non c'è uno slittamento di tempo?
Se noi sappiamo le caratteristiche unicamente dell'A0 e non dell'A1, e la fonte diceva che l'A1 è già vecchio, mi sembra ovvio che non sappiamo nè a che punto è Zen e nè le caratteristiche finali di Zen.

Lisa Su non te le dice, perchè non ha riportato le massime frequenze e ha detto solamente che saranno superiori a 3,4GHz del Zen che hanno presentato.

Per i produttori di mobo, basta avere anche l'A0 (credo) per terminare la mobo, perchè il clock Turbo è autonomo nel procio, quindi non avrebbe il minimo impatto sul TDP/alimentazione della mobo, perchè, da quello che si è capito, funziona semplicemente su un TDP massimo e da li a seconda del carico, dei core in funzione, delle temp e del Vcore, varia la frequenza.
Per assurdo AMD potrebbe pure dare un ES con il numero minore di bug possibile ma con silicio non affinato, giusto per portare al massimo TDP commerciale ma su una frequenza inferiore rispetto all'ultimo affinamento.

Forse non ci stiamo accorgendo che il top secret di Zen è tutto sulla massima frequenza Turbo, il resto AMD più o meno l'ha già detto tutto. Perchè? Perchè incentra il confronto di Zen sul 6900K quando Lisa Su parla specificatamente di Zen vs i5/i7?

[Grizlod®]

Originariamente inviato da Ryddyck

Sii obiettivo, un paio di giorni fa lo "presentano" a 3.4 GHz+ e dovrebbero commercializzarlo nel primo trimestre con presentazione forse al ces2017.
Quanto tempo avrebbero per produrne uno con una frequenza maggiore stabile in volumi, considerando sempre da rumor che chi l'ha avuto tra le mani mancava di feature e aveva dei bug?

Al CES di gennaio, quasi sicuramente faranno un paper-launch, per cui avranno tutto il tempo per
produrlo, packeggiarlo e commercializzarlo entro il Q1 2017.

Verosimilmente IMO, sarà sugli scaffali da metà febbraio in poi...
Sempre IMO, avrà un clock base di (almeno) 3.5 GHz.