[Thread Ufficiale] Aspettando ZEN

[Piedone1113]

Originariamente inviato da affiu

AUGURI
Buon 2017

Nell'attesa che si compia la fusione.....siamo sempre più vicini!

Questo 2017 vedremo finalmente APU-ZEN....e dopo finalmente la GRANDE APU chiaramente solo AMD

E GRANDE API di AMD credi che abbia speranze contro il GRANDE BART di Intel?

[Piedone1113]

Originariamente inviato da Pozhar

Porca vacca. Ci avrai fatto l'abitudine. Ma non è per tutti. Specie qui in Italia da noi che siamo abituati bene e non abbiamo quel genere di problemi/pericoli come nel posto dove ti trovi ora tu o in Australia etc...

Su questo aspetto, credo che siamo uno dei pochi paesi al mondo che stiamo veramente nel "ventre della vacca" come si suol dire dalle mie parti. Poi certo punti di vista.

Sicuramente su certi aspetti è bello vedere tutta quella biodiversità etc... specie per chi è appassionato di ste' cose.

Dalle mie parti si spingono fin nel centro abitato le vipera.
Fuori ti ritrovi vipera, scorpioni, lupi, cinghiali e qualche cartello con su scritti:
Attenzione pericolo di avvelenamento da piombo (se cerchi di fregare ciliege, uva da tavola peschenoci ecc, anche se nei rarissimi casi si tratta di sale grosso).

[Pozhar]

Dove ti trovi tu ora?

[Gioz]

Auguri a tutti, spero abbiate passato tutti una bella serata come la mia (son già tornato perchè ho l'influenza)

Originariamente inviato da Mister D

In linea generale sono d'accordo ma lui ha preso un valore che, guardacaso, è lineare. Vuoi la prova:
http://www.anandtech.com/bench/CPU/1029
640 punti per fx8350 @4000
http://www.hardwarecanucks.com/forum...-review-5.html
638 punti per fx8350 @4000
http://www.hwupgrade.it/articoli/cpu...n-prova_3.html
612 punti per fx8350 @4000
Mediando abbiamo 630 punti ergo facciamo 630/4000 e viene circa 0.1575 che è molto simile ai 0.1564 pti/Mhz ottenuti prendendo il valore di cine r15 per un fx8350 portato a 7649 MHz. Ti pare non lineare? Anzi lo sottostima pure ergo ancora più sicuro.

Quindi tutto il suo ragionamento è corretto, tranne per il caso dei consumi dove non è corretto usare un andamento lineare rispetto la frequenza, come riportato giustamente anche da digieffe.

non mi sono espresso bene.
tu hai ragione, l'andamento dei risultati tende ad essere lineare, ma lui suppone linearità a prescindere su un bench di terze parti in condizioni estreme, è questo che trovo poco interessante.
per farti un esempio scremo e raggruppo alcuni miei risultati in varie condizioni con il 6300
base clock a 200 (settato a 200 o su auto la mobo imposta 200,99 - 201, da cui circa 20MHz extra rispetto al settaggio nominale):
https://s23.postimg.org/anzp9m1sr/cinebench_201.jpg

base clock a 240:
https://s30.postimg.org/yc25gbyqp/cinebench_240.jpg

settaggi vari tra cui il miglior punteggio che ho totalizzato:
https://s23.postimg.org/psnta5sgb/cinebench_max.jpg

a meno di scarti minimi che ci possono essere effettuando il bench la linearità è abbastanza evidente, però se prendi i 573 a 5030 da un rapporto di 0,1139... e se lo moltiplichi per 1510 fa 172 contro i 180 del bench.
al contrario se prendi il 180 a 1510 fa 0,1192... che per 5030 arriva a 599 anzichè i 573 del bench,
se poi facessi 180/1510 dalla prima slide x 5040 della seconda ne ricaveresti 600 contro il 569 del bench.

probabilmente è dovuto al fatto che a 5GHz il sistema non è perfettamente stabile, quindi come una volta ho beccato 608, l'altra ci sta di beccare 569 o crashare ed è questa condizione che falsa tutto il gioco.

non dico che sia sbagliato il ragionamento a prescindere dico che non mi piace e non lo prendo in considerazione perché non trovo così uitile fare il punto della situazione prendendo dati, relativi poi ad un caso così estremo di 7,X GHz sotto LN2, per estrapolare valori di confronto.

[bomkill]

http://en.yibada.com/articles/182451...or-amd-cpu.htm

Non so se già postato.

[cdimauro]

Originariamente inviato da paolo.oliva2

Se mi chiarite un punto.

Per quello che sapevo, una volta, si era bacchettata Intel perchè i compilatori avevano una specie di "if genuine Intel allora fai questo, else, quest'altro.
Ricordo che Intel si era giustificata perchè non poteva ottimizzare proci non suoi, però c'era un punto in cui sembrava che volutamente non si eseguiano delle istruzioni ma altre meno efficienti.

Come avevo già spiegato prima, Intel è stata condannata per non aver documentato il funzionamento dei suoi compilatori, e dunque i clienti non erano informati e pienamente consapevoli delle conseguenze di ciò.

Inoltre Intel continua ancora a ottimizzare specificatamente per i suoi processori, come peraltro è ampiamente riportato nella presentazione di cui Grizlod® ha fornito il link.

Però io devo capire... se i ruoli fossero invertiti, e quindi AMD facesse i compilatori, Intel potrebbe obbligare AMD a fare i compilatori per lei?

No, visto che negli USA non vige una dittatura e l'iniziativa privata è "sacra".

Cioè... io direi che sono cacchi tuoi.

Assolutamente sì: decide chi scuce i soldONi per sviluppare il compilatore.

Quindi mi chiedo... perchè AMD non si fa dei compilatori in proprio per i suoi proci e librerie idonee a C++ & C.?

Infatti potrebbe farlo. "Basta" pagare qualche migliaio di ingegneri altamente specializzati.

Cioè... se Intel paga ad AMD le features dell'interfacciamento X86/iGPU,

Qui ti riferisci ai brevetti immagino, che attualmente Intel paga a nVidia e non ad AMD.

In questo caso i brevetti sono regolati da una giurisprudenza differente, che include il concetto di fair use, visto che ci sono dei brevetti fondamentali senza i quali non è possibile progettare GPU.

La normativa prevede in questi casi che i detentori dei brevetti consentano a terzi di utilizzarli dietro un consono pagamento (leggi: niente giochetti al rialzo).

AMD paga Intel per i compilatori, e tutti vivono felici e contenti.

In teoria sì. In pratica Intel non sarebbe affatto interessata visto che ha una posizione di eccellenza in ambito compilatori, mentre AMD dovrebbe scucire un pozzo di soldi per cui non le sarebbe conveniente.

Originariamente inviato da bjt2

Se ti leggi i manuali di ottimizzazione AMD, è scritto che la pratica ottimale sarebbe: se la CPU supporta X, allora usa le istruzioni X e così via.

Francamente non ricordo di aver letto qualcosa del genere, che peraltro contraddirebbe l'esistenza stessa di un manuale per le ottimizzazioni di una ben precisa microarchitettura.

L'ultimo manuale per le ottimizzazioni di AMD dovrebbe essere questo: 47414 - Software Optimization Guide for AMD Family 15h Processors

Mi sapresti dire dove posso trovare l'affermazione che hai citato?

Invece i compilatori INTEL facevano (? Secondo quel PDF di Agner lo fanno ancora) così: Se la CPU è INTEL e supporta X, allora usa X, altrimenti usa Y (meno efficiente)...

Non fa solo questo: leggi il PDF di cui è stato postato il link.

Ma per ALCUNE sue CPU il compilatore Intel è in grado di generare codice specifico usando (SE possibile) tutte le loro feature. Ovviamente leggendo prima quale esatta microarchitettura si tratta.

E com'è ovvio che sia, visto che se vuoi ottenere il codice più ottimizzato possibile DEVI necessariamente procedere in questo modo.

Originariamente inviato da Ren

Diamo a cesare quel che è di cesare...
Con carrizo hanno messo una pezza alla questione (buongiorno).
Se per questo hanno fatto marcia indietro anche sui decoder.

BD non ci mancherai...

ROTFL: cache L1D raddoppiata e, sempre "casualmente", L2 dimezzata. Hanno impiegato quasi 5 anni per capirlo.

Tra l'altro ieri ho dimenticato di aggiungere un particolare molto importante, causa fretta per andare al cenone.

Fra Phenom-II e Nehalem c'è anche da tenere conto del fatto che quest'ultimo implementa anche l'HyperThreading, che ha un certo costo in termini di complessità implementativa. Immagino che i 140Mhz di clock (a favore del Phenom) possano ragionevolmente essere anche attribuiti a questo.

Originariamente inviato da Roland74Fun

Ogni giorno qui tutti paghiamo il tributo a Cesare.

Però niente pugnalate, please.

Originariamente inviato da paolo.oliva2

Capisco questo... ma non capisco il perchè Intel sarebbe obbligata...

Obbligata a cosa? A documentare il funzionamento del compilatore? Se è questo ciò di cui parli, è giustissimo che sia costretta a farlo, perché i consumatori che usano i suoi (COSTOSI) compilatore devono essere a conoscenza di come funzioni.

nel senso... AMD non potrebbe fare un compilatore lei?

Senz'altro, ma dovrebbe spendere VAGONATE di soldi per pagare professionisti altamente specializzati. Peraltro partendo da zero quanto a brevetti utilizzabili e, dunque, essendo alquanto limitata nelle ottimizzazioni generali possibili.

In fin dei conti, in Linux, ad esempio (ora non so), mi ricordo che c'era la versione AMD e Intel, e quella 64bit e 32bit...
Forse era anche per quello che sotto Linux le differenze AMD/Intel si assottigliavano... magari con le specifiche versioni, erano equivalentemente ottimizzate.

Non mi pare di aver visto binari per AMD e Intel. Forse ti riferisci ai binari marcati come AMD64, che però si riferiscono all'ISA, che è condiviso da AMD e Intel.

Se vuoi ottenere binari ottimizzati specificamente per determinati processori AMD, devi compilarteli da solo.

Originariamente inviato da bjt2

Il compilatore intel è ancora il migliore... Gli altri sono ancora indietro nell'autovettorizzazione. IMHO un altro motivo per AMD per fare più pipeline a 128 bit e non poche a 256 bit come INTEL è che per default i compilatori INTEL usano codice SSE2 su AMD, quindi sarebbe stato inutile fare unità a 256 bit... Faccio una CPU che macina a bestia i 128 bit e via...

Un altro motivo è che i compilatori Intel costano, e dunque non sono usati tanto quanto GCC et similia, che usa code path basati su feature anziché su architetture, e in genere di default si ottimizza soltanto per le SSE2, per l'appunto.

Originariamente inviato da Piedone1113

Auguri ai tifosi AMD, ai tifosi Intel, a quelli nvidia e a quelli del portafogli.
Buon 2017

*

Originariamente inviato da Piedone1113

Dipende dalle parallizazione del software e delle eventuali ottimizzazioni possibili.
Comunque per amd il compilatore intel va comunque bene.

Esattamente, perché comunque il codice generato "per feature" risulta in ogni caso ben ottimizzato.

Ovviamente il massimo è quello generato "per micro-architettura", perché tiene conto (giustamente!) ANCHE delle peculiarità di quel preciso processore, ma non le si può certo chiedere di fare lo stesso per quelli della concorrenza.

Originariamente inviato da bomkill

http://en.yibada.com/articles/182451...or-amd-cpu.htm

Non so se già postato.

Una sintesi scritta da chi non ha capito come stanno realmente le cose. Lascia perdere: meglio il pezzo originale di CPC, e il successivo intervento nel loro blog.

[Neverlost]

buon anno, si sa più o meno il MESE di uscita sul mercato consumer di Ryzen?

[Forum Rift]

Interessante punto della situazione sul versante cpu...

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

[bjt2]

Originariamente inviato da cdimauro

Francamente non ricordo di aver letto qualcosa del genere, che peraltro contraddirebbe l'esistenza stessa di un manuale per le ottimizzazioni di una ben precisa microarchitettura.

L'ultimo manuale per le ottimizzazioni di AMD dovrebbe essere questo: 47414 - Software Optimization Guide for AMD Family 15h Processors

Mi sapresti dire dove posso trovare l'affermazione che hai citato?

Hai ragione. Non sono sicuro di averlo letto in un manuale AMD. Ho letto così tanti manuali di AMD, e Agner Fog, ad esempio, che li confondo. Ricordo vagamente l'algoritmo consigliato per la determinazione delle feature. Sui documenti AMD ufficiali, la cosa più simile che ho trovato sono le appendici D ed E del 3 manuale LINK, pagina 523 e seguenti, dove sono solo elencati i flag da controllare per i vari subset di istruzioni. Ovviamente non specifica che prima bisogna controllare se c'è la stringa AuthenticAMD o GenuineIntel e poi procedere con il resto dei flags... Mi ricordavo che ci fosse un algoritmo in pseudocodice, ma mi devo essere confuso con il manuale di Agner Fog LINK che da pagina 125 in poi suggerisce strategie e algoritmo ottimale...

Originariamente inviato da cdimauro

Non fa solo questo: leggi il PDF di cui è stato postato il link.

Ma per ALCUNE sue CPU il compilatore Intel è in grado di generare codice specifico usando (SE possibile) tutte le loro feature. Ovviamente leggendo prima quale esatta microarchitettura si tratta.

E com'è ovvio che sia, visto che se vuoi ottenere il codice più ottimizzato possibile DEVI necessariamente procedere in questo modo.

L'ho letto e ti faccio le mie considerazioni:

1) La software house decide di usare le impostazioni di default del compilatore (caso che io credo sia il più diffuso, ma nel caso non lo fosse, vedi punto 2).
Le impostazioni di default prevedono il loop unrolling automatico e lo scheduling automatico SOLO per le CPU INTEL. Per le CPU non INTEL è previsto il path base, che per default è SSE2.

Più esplicitamente, ad inizializzazione del codice (anche nel C è possibile inserire funzioni da chiamare prima e dopo il main()... Non è necessario usare DLL o il C++ e i costruttori. E infatti il metodo scelto è quello a basso livello con variabili globali e funzione chiamata prima del main) per prima cosa controllata la stringa GenuineIntel. Tanto che i software di patching che migliorano le prestazioni sulle CPU AMD devono solo patchare l'istruzione che fa lo string compare... E solo dopo controlla con CPUID i subset supportati...

2) La software house è un po' più scafata o semplicemente tiene di più all'ottimizzazione. Cosa offre il compilatore INTEL? Lo scheduling automatico (-ax) è a disposizione UNICAMENTE delle CPU INTEL.

Ci sono 2 alternative:

a) Usare il flag -m che modifica la codebase di base (minima) che viene usata per le CPU non INTEL. Questo non reintroduce la flessibilità che si ha sulle CPU INTEL. Il produttore di software dovrebbe produrre più binari per più sottofamiglie di CPU AMD e in ogni caso se usa librerie INTEL, queste avranno il dispatcher automatico che legge che le variabili (vedi dopo) non sono inizializzate e chiama il dispatcher di CPU che fa quello detto sopra. Quindi se usa le librerie matematiche ottimizzate, compilate con compilatore INTEL (e ad esempio Matlab lo fa), gireranno in SSE2 su CPU AMD.

b) Usare il trucco che è specificato nel PDF di Agner Fog e non so quanto sia documentato e come lui lo sappia, ossia riazzerare le variabili globali che usa il compilatore e chiamare la routine di scheduling alternativa (_x) che non discrimina tra i brand... Quindi l'hanno implementata! E perchè non usano quella di default? Questo trucco risolve anche il problema di eventuali librerie INTEL usate dal software.

Capirai che INTEL non ha fatto nulla per semplificare la vita al programmatore...

Si potrebbe creare un piccolo file .h contenente le dichiarazioni per il compilatore INTEL, in un #ifdef che magari crea una funzione dispatch universale, che fa i controlli come suggerito da Agner Fog e che viene richiamata da tutti i software che si intende scrivere...

[cdimauro]

Originariamente inviato da Forum Rift

Interessante punto della situazione sul versante cpu...

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

"Perdona lui perché non sa quello che dice..." (semi-cit.)

Originariamente inviato da bjt2

Hai ragione. Non sono sicuro di averlo letto in un manuale AMD. Ho letto così tanti manuali di AMD, e Agner Fog, ad esempio, che li confondo. Ricordo vagamente l'algoritmo consigliato per la determinazione delle feature. Sui documenti AMD ufficiali, la cosa più simile che ho trovato sono le appendici D ed E del 3 manuale LINK, pagina 523 e seguenti, dove sono solo elencati i flag da controllare per i vari subset di istruzioni. Ovviamente non specifica che prima bisogna controllare se c'è la stringa AuthenticAMD o GenuineIntel e poi procedere con il resto dei flags... Mi ricordavo che ci fosse un algoritmo in pseudocodice, ma mi devo essere confuso con il manuale di Agner Fog LINK che da pagina 125 in poi suggerisce strategie e algoritmo ottimale...

OK, quindi non c'è niente nei manuali di AMD, come immaginavo.

L'ho letto e ti faccio le mie considerazioni:

1) La software house decide di usare le impostazioni di default del compilatore (caso che io credo sia il più diffuso, ma nel caso non lo fosse, vedi punto 2).
Le impostazioni di default prevedono il loop unrolling automatico e lo scheduling automatico SOLO per le CPU INTEL. Per le CPU non INTEL è previsto il path base, che per default è SSE2.

Più esplicitamente, ad inizializzazione del codice (anche nel C è possibile inserire funzioni da chiamare prima e dopo il main()... Non è necessario usare DLL o il C++ e i costruttori. E infatti il metodo scelto è quello a basso livello con variabili globali e funzione chiamata prima del main) per prima cosa controllata la stringa GenuineIntel. Tanto che i software di patching che migliorano le prestazioni sulle CPU AMD devono solo patchare l'istruzione che fa lo string compare... E solo dopo controlla con CPUID i subset supportati...

Non credo che questo sia sufficiente. Come fai, dopo aver patchato la stringa, a distinguere se chiamare il code path per Atom (in-order. O l'ultimo out-of-order) o per Core Duo 2, ad esempio? Sono microarchitetture completamente diverse, per le quali sono generati code path ben diversi (ovviamente).

2) La software house è un po' più scafata o semplicemente tiene di più all'ottimizzazione. Cosa offre il compilatore INTEL? Lo scheduling automatico (-ax) è a disposizione UNICAMENTE delle CPU INTEL.

Mi pare normale: Intel genera codice specificamente ottimizzato per le sue micro-architetture.

Ci sono 2 alternative:

a) Usare il flag -m che modifica la codebase di base (minima) che viene usata per le CPU non INTEL. Questo non reintroduce la flessibilità che si ha sulle CPU INTEL. Il produttore di software dovrebbe produrre più binari per più sottofamiglie di CPU AMD e in ogni caso se usa librerie INTEL, queste avranno il dispatcher automatico che legge che le variabili (vedi dopo) non sono inizializzate e chiama il dispatcher di CPU che fa quello detto sopra. Quindi se usa le librerie matematiche ottimizzate, compilate con compilatore INTEL (e ad esempio Matlab lo fa), gireranno in SSE2 su CPU AMD.

b) Usare il trucco che è specificato nel PDF di Agner Fog e non so quanto sia documentato e come lui lo sappia, ossia riazzerare le variabili globali che usa il compilatore e chiamare la routine di scheduling alternativa (_x) che non discrimina tra i brand... Quindi l'hanno implementata! E perchè non usano quella di default? Questo trucco risolve anche il problema di eventuali librerie INTEL usate dal software.

Anche qui vale quanto ho scritto sopra: i code path per micro-architetture Intel diverse sono molto diversi. Come fai a distinguerli se vai a smanettare soltanto sui flag delle feature?

Capirai che INTEL non ha fatto nulla per semplificare la vita al programmatore...

Non vedo come potrebbe, visto che la generazione di codice per micro-architettura, anziché per feature, è (ovviamente) esclusiva per le sue CPU.

Si potrebbe creare un piccolo file .h contenente le dichiarazioni per il compilatore INTEL, in un #ifdef che magari crea una funzione dispatch universale, che fa i controlli come suggerito da Agner Fog e che viene richiamata da tutti i software che si intende scrivere...

Anche qui vale quanto ho già scritto sopra, perché la problematica che ho esposto non verrebbe risolta.

Ti faccio anche un esempio, giusto per chiarire meglio. Mettiamo che tu abbia un processore AMD Jaguar, e che per questo sarebbe meglio utilizzare il code path che il compilatore Intel ha generato per gli Atom out-of-order: come fai a farglielo usare, al posto di quello per un Core Duo 2?

[bjt2]

Originariamente inviato da cdimauro

Non credo che questo sia sufficiente. Come fai, dopo aver patchato la stringa, a distinguere se chiamare il code path per Atom (in-order. O l'ultimo out-of-order) o per Core Duo 2, ad esempio? Sono microarchitetture completamente diverse, per le quali sono generati code path ben diversi (ovviamente).

Mi pare normale: Intel genera codice specificamente ottimizzato per le sue micro-architetture.

Anche qui vale quanto ho scritto sopra: i code path per micro-architetture Intel diverse sono molto diversi. Come fai a distinguerli se vai a smanettare soltanto sui flag delle feature?

Non vedo come potrebbe, visto che la generazione di codice per micro-architettura, anziché per feature, è (ovviamente) esclusiva per le sue CPU.

Anche qui vale quanto ho già scritto sopra, perché la problematica che ho esposto non verrebbe risolta.

Ti faccio anche un esempio, giusto per chiarire meglio. Mettiamo che tu abbia un processore AMD Jaguar, e che per questo sarebbe meglio utilizzare il code path che il compilatore Intel ha generato per gli Atom out-of-order: come fai a farglielo usare, al posto di quello per un Core Duo 2?

Hai ragione per quanto riguarda le ottimizzazioni. L'unica soluzione sarebbe usare -O0 che disabilita le ottimizzazioni specifiche per le varie CPU o provare e vedere come va sulle suddette CPU... Non credo che le CPU però perdano poi così tanto. Sicuramente non usare i 256 bit quando supportati o le istruzioni AVX (penso all'esempio con blend) porta ad avere più istruzioni da eseguire e quindi probabilmente andrebbero più lenti...
Restano le esperienze dei vari utenti con il patcher per gli eseguibili. Non ho notizie di perdite di prestazioni dopo la patch, ma solo di aumenti...

[paolo.oliva2]

Originariamente inviato da bomkill

http://en.yibada.com/articles/182451...or-amd-cpu.htm

Non so se già postato.

Non è già stato postato ma è in pratica un riassunto di quanto si dice negli ultimi 2 mesi.

Comunque... o AMD ha seguito corsi di riparazione per presentare un nuovo prodotto, o la gente spera in un nuovo prodotto, non lo posso sapere, però di fatto le info di Zen sono tutto un crescendo.

Si era partiti da un confronto 3GHz vs 3GHz in cui comunque Zen era alla pari per consumo/prestazioni e prestazioni in sè (con il dubbio, però, del 6900K downcloccato e dei bench scelti).
Poi c'è stato il confronto a New Horizon, con Zen a 3,4GHz bloccato con turbo disattivato e 6900K in situazione def, in cui ha forse migliorato le prestazioni ottenute nel confronto precedente.

Faccio notare che il 6900K, dai 3,2GHz def, ha ottenuto frequenze 3,4GHz/3,5GHz nel bench grazie al turbo, mentre Zen bloccato a 3,4GHz (che tra l'altro rappresenta la frequenza def al momento ottenuta da AMD/GF), di fatto non ha usufruito dei vantaggi, come il 6900K, del turbo.

Ora i rumors riportano frequenze superiori alle aspettative, quindi se 3,4GHz+ poteva rappresentare 3,5GHz, un "superiore alle aspettative" significherebbe almeno 3,6GHz, il che porterebbe Zen X8+8 ad una frequenza def praticamente uguale/superiore a quella di un 6900K in condizione turbo e quella turbo di Zen come X8 probabilmente superiore a quella del 6900K Turbo 1-2 core.

Ma l'aspetto più positivo, è il prezzo. In 7 mesi, non ho mai letto una testata riportare il prezzo di Zen X8+8 top sopra gli 800€, e l'ultima che ha riportato 800€, con un kit liquido stile 9590 compreso nel prezzo (credo approssimativamente un valore di ~100€), il che comunque porterebbe Zen X8+8 versione top simile ai prezzi di un 6850K X6 Intel.

In questa situazione, ritorno a ripetere, l'unica preoccupazione di una aspettativa ingiustificata, non la vedrei lato prestazioni nel confronto core to core vs Intel, ma unicamente nel lato/prezzo prestazioni.

Sinceramente, visto che c'è un assoluto vuoto di notizie circa un Zen X4+4 nativo, secondo me l'unica vera falsa aspettativa è quella di ipotizzare X4+4/X6+6 ad un prezzo proporzionato all'X8+8, mentre io sarei dell'idea che l'X8+8 possa essere proposto ad un prezzo molto competitivo proprio per rappresentare l'alternativa agli X4+4/X6+6, perchè da un die X8 nativo, è utopia sperare quantità di fallati superiori al numero di X8 sani, quindi come potrebbe AMD soddisfare la richiesta di Zen <X8?

-------

Bisognerà attendere Zen APU X4+4 per un'offerta nativa Zen X4+4... però io mi chiedo... Un Zen X8+8 X86 è 2 moduli CCX + relativa L3, un Zen X4+4 APU è sarebbe 1 modulo CCX senza L3 e l'iGPU e HBM2 al posto del 2° modulo CCX, e l'iGPU 2x/2,5x rispetto all'iGPU di un BR (quindi direi con un numero di transistor ben superiore a quella di BR).
Quanta differenza, in termini totali di costo (R&D e produzione/scarti) si potrebbe ipotizzare tra un Zen X8+8 X86 e un Zen X4+4 APU?

Perchè, da come sembra, AMD avrebbe tutto il margine TDP per realizzare un Zen X86 X12+12 (una sorta di Zen vs 6950X) e quindi una nicchia superiore più costosa, e vedersela vs Intel nella fascia 11XX dove potrebbe proporre un Zen APU X4+4 o Zen X86 X8+8 a prezzi simili per pulire il melo.
Non dimentichiamoci che AMD produce anche VGA, quindi tra vendere Zen APU e un bandle Zen X86 + RX 480, alla fine è pur sempre lei che venderebbe.

[Mister D]

Originariamente inviato da cdimauro

cut...
Non c'entra nulla con quanto detto prima. AMD era o non era una ladra vendendo a peso d'oro i suoi dual core in via esclusiva, visto che Intel non ne forniva?
cut...

Cesare ma ne sei proprio così sicuro? Per me ti ricordi male:
http://www.hwupgrade.it/articoli/cpu...s-intel_5.html
http://www.cpu-world.com/CPUs/Pentiu...1PG3200F).html
http://www.cpu-world.com/CPUs/K8/AMD...800CDBOX).html

Le cpu dual core sono arrivate insieme tra aprile e maggio 2005 e costavano una fortuna per entrambi i marchi, circa i soliti 1000$. Ok per essere precisi 999 per intel e 1001 per amd e andando nelle fasce sottostanti che amd "ladrava" di più offrendo a prezzi più elevati di intel ma c'è da considerare che andavano poco di più e consumavano meno.
Ti ricordi male quindi dicendo che intel non ne forniva
Spezzo cmq una lancia a tuo favore sul fatto che il mercato fa il prezzo quando c'è concorrenza:
http://www.hwupgrade.it/articoli/cpu...2-3800+_2.html
Da maggio 2005 passarono pochi mesi che amd introdusse il x2 3800+ che costava di meno e abbassò tutto il listino con intel che però rimase immobile perché già ben posizionata.

[Gioz]

Originariamente inviato da Forum Rift

Interessante punto della situazione sul versante cpu...

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

secondo me è però ambiguo il fatto di paragonare cpu da 10 anni a questa parte senza tener conto dei nuovi set di istruzioni introdotti da un modello all'altro.

P.S. quanto a potenza ed efficienza non capisco perchè riportino il solo valore in idle di 6950X e pentium 955, dato che han misurato le varie configurazioni avrei trovato logico presentare anche le misurazioni ottenute sotto carico, anche se presentano cpumark/potenza che è correlato e permette comunque di derivare il consumo che hanno misurato.
per scrupolo aggiungo: non intendo dire che sia fatto male, semplicemente mi sarei aspettato di vedere riportati quei valori.

[Mister D]

Originariamente inviato da Gioz

Auguri a tutti, spero abbiate passato tutti una bella serata come la mia (son già tornato perchè ho l'influenza)


non mi sono espresso bene.
tu hai ragione, l'andamento dei risultati tende ad essere lineare, ma lui suppone linearità a prescindere su un bench di terze parti in condizioni estreme, è questo che trovo poco interessante.
per farti un esempio scremo e raggruppo alcuni miei risultati in varie condizioni con il 6300
base clock a 200 (settato a 200 o su auto la mobo imposta 200,99 - 201, da cui circa 20MHz extra rispetto al settaggio nominale):
https://s23.postimg.org/anzp9m1sr/cinebench_201.jpg

base clock a 240:
https://s30.postimg.org/yc25gbyqp/cinebench_240.jpg

settaggi vari tra cui il miglior punteggio che ho totalizzato:
https://s23.postimg.org/psnta5sgb/cinebench_max.jpg

a meno di scarti minimi che ci possono essere effettuando il bench la linearità è abbastanza evidente, però se prendi i 573 a 5030 da un rapporto di 0,1139... e se lo moltiplichi per 1510 fa 172 contro i 180 del bench.
al contrario se prendi il 180 a 1510 fa 0,1192... che per 5030 arriva a 599 anzichè i 573 del bench,
se poi facessi 180/1510 dalla prima slide x 5040 della seconda ne ricaveresti 600 contro il 569 del bench.

probabilmente è dovuto al fatto che a 5GHz il sistema non è perfettamente stabile, quindi come una volta ho beccato 608, l'altra ci sta di beccare 569 o crashare ed è questa condizione che falsa tutto il gioco.

non dico che sia sbagliato il ragionamento a prescindere dico che non mi piace e non lo prendo in considerazione perché non trovo così uitile fare il punto della situazione prendendo dati, relativi poi ad un caso così estremo di 7,X GHz sotto LN2, per estrapolare valori di confronto.

Ciao,
non voglio assolutamente imporre la mia visione o la mia idea ma ti faccio notare che i tuoi valori differiscono entro il 5% dal valore aspettato di linearità perfetta. Se avessi voglia e tempo potresti divertirti con un foglio excel a provare i test di correlazione (se mi ricordo bene ma sono passati 10 anni e la mia memoria potrebbe ingannare, c'è il test del chi quadrato che usavamo a fisica) e vedresti che i tuoi valori sono ampiamente dentro una ipotetica retta con y=k*x con k uguale al valore di punti/frequenza. Però capisco che c'è sicuramente di meglio da fare, soprattutto in questi giorni, che divertirsi con il chi quadrato

[bjt2]

Originariamente inviato da Mister D

Ciao,
non voglio assolutamente imporre la mia visione o la mia idea ma ti faccio notare che i tuoi valori differiscono entro il 5% dal valore aspettato di linearità perfetta. Se avessi voglia e tempo potresti divertirti con un foglio excel a provare i test di correlazione (se mi ricordo bene ma sono passati 10 anni e la mia memoria potrebbe ingannare, c'è il test del chi quadrato che usavamo a fisica) e vedresti che i tuoi valori sono ampiamente dentro una ipotetica retta con y=k*x con k uguale al valore di punti/frequenza. Però capisco che c'è sicuramente di meglio da fare, soprattutto in questi giorni, che divertirsi con il chi quadrato

Un'altra cosa che si può fare è il fitting lineare e vedere l'R^2 (R quadro, indice di Pearson): più è vicino a 1 e più la correlazione (lineare in questo caso, perchè può essere applicato ad ogni fitting) è perfetta...

[Mister D]

Originariamente inviato da bjt2

Un'altra cosa che si può fare è il fitting lineare e vedere l'R^2 (R quadro, indice di Pearson): più è vicino a 1 e più la correlazione (lineare in questo caso, perchè può essere applicato ad ogni fitting) è perfetta...

Vedi che c'è qualcuno che si ricorda meglio di me Cmq già si vede ad occhio che è lineare cinebench rispetto la frequenza con cpu stabili

[Gioz]

Originariamente inviato da Mister D

Ciao,
non voglio assolutamente imporre la mia visione o la mia idea ma ti faccio notare che i tuoi valori differiscono entro il 5% dal valore aspettato di linearità perfetta. Se avessi voglia e tempo potresti divertirti con un foglio excel a provare i test di correlazione (se mi ricordo bene ma sono passati 10 anni e la mia memoria potrebbe ingannare, c'è il test del chi quadrato che usavamo a fisica) e vedresti che i tuoi valori sono ampiamente dentro una ipotetica retta con y=k*x con k uguale al valore di punti/frequenza. Però capisco che c'è sicuramente di meglio da fare, soprattutto in questi giorni, che divertirsi con il chi quadrato

premesso che tu hai ragione e il tuo discorso è corretto, non è un discorso sulla correttezza dei dati a prescindere, ma del modo di fare un articolo.
mi quoto sperando di farti capire cosa intendevo

Originariamente inviato da Gioz

io mi sono fermato con la lettura al "prendiamo il punteggio cinebench più alto..." linkando un *8370 sotto LN2 a oltre 7GHz

EDIT: * 8350

Originariamente inviato da Gioz

il senso in cui lo dico è che prendono una condizione di funzionamento talmente lontana dalle specifiche che non è possibile supporre uno scaling lineare come invece fanno nell'articolo.
la mia voleva essere una critica fortemente negativa al modo in cui deducono i valori di confronto, non aveva il senso di considerare meglio o peggio uno dei processori presi a paragone.

appena ho visto che prendeva un dato simile per ricavare i valori di riferimento ho smesso di leggere, un'analisi in quell'ottica non mi piace a prescindere dai valori che ottiene.
assume come corretto il bench di zen che è emerso essere un fake, avrei trovato sensato prendere un 83XX e clockarlo al pari di zen per confrontare due dati misurati, anziché prendere un bench estremo e normalizzarlo per poi prendere il fake e rapportarlo ai 7,X GHz.
considera quindi lineare lo scaling di zen partendo da quello che è un risultato fake e lo rapporta alla proporzione del 8350.
per me se vuoi fare un articolo sul punto della situazione fai come bitsandchips o HwUpgrade, o le principali testate serie:
prendi le cose che si sanno e le descrivi, prendi i componenti che puoi e li provi, non ho mai visto corsini scrivere un articolo in cui "tanto a 4.8GHz andrà così...a 3.6 andrà cosà".
per me è sbagliato fare un articolo in cui derivi i valori in questa maniera, non dico che è sbagliato il risultato che ottiene(probabilmente lo è per zen, dato che si basa su un risultato di dubbia provenienza), dico che per come imposta il discorso fin da subito a me non interessa leggerlo.

[Mister D]

Originariamente inviato da Gioz

premesso che tu hai ragione e il tuo discorso è corretto, non è un discorso sulla correttezza dei dati a prescindere, ma del modo di fare un articolo.
mi quoto sperando di farti capire cosa intendevo


appena ho visto che prendeva un dato simile per ricavare i valori di riferimento ho smesso di leggere, un'analisi in quell'ottica non mi piace a prescindere dai valori che ottiene.
assume come corretto il bench di zen che è emerso essere un fake, avrei trovato sensato prendere un 83XX e clockarlo al pari di zen per confrontare due dati misurati, anziché prendere un bench estremo e normalizzarlo per poi prendere il fake e rapportarlo ai 7,X GHz.
considera quindi lineare lo scaling di zen partendo da quello che è un risultato fake e lo rapporta alla proporzione del 8350.
per me se vuoi fare un articolo sul punto della situazione fai come bitsandchips o HwUpgrade, o le principali testate serie:
prendi le cose che si sanno e le descrivi, prendi i componenti che puoi e li provi, non ho mai visto corsini scrivere un articolo in cui "tanto a 4.8GHz andrà così...a 3.6 andrà cosà".
per me è sbagliato fare un articolo in cui derivi i valori in questa maniera, non dico che è sbagliato il risultato che ottiene(probabilmente lo è per zen, dato che si basa su un risultato di dubbia provenienza), dico che per come imposta il discorso fin da subito a me non interessa leggerlo.

Ok comprendo benissimo il tuo discorso ma per me vale sempre il principio prima leggo e poi decido se è scritto bene o no e a parte quel punto di partenza che poi utilizza solo per derivare probabili punteggi di cinebench ma non usa per scrivere le conclusioni, per me è un buon articolo riassuntivo di quello che è successo fin ora. Lui usa i dati di canard e prendi buoni quelli e ci fa dei ragionamenti condivisibili o meno invece per cine usa quel dato di un fx8350 a 7,6 per dire che il punteggio di 1188 uscito (e descritto poi come fake) è VEROSIMILE. Almeno io a leggere ho inteso questo, tanto che i grafici non usano i calcoli fatti da lui con cinebench.

Che poi mi sono accorto di un errore in quei calcoli
Così avalla ancora più la tua tesi
Il passaggio che non mi torna è questo:
/* Zen CineBench R15 score @ 3300 MHz */
(PD_MHz ÷ ZN_GAIN) × ZN_PPC = 1194
ZN_3300 = 1194 cb

Ok tutto il resto ma perché non moltiplicare direttamente quel ZN_PPC per la frequenza desiderata, in questo caso di 3300 MHz? Verrebbe esattamente 3300*0,311=1026,3 che torna con i risultati di canard pc perché 1026,3/630 (punteggio medio di un fx8350 a stock) viene 1.629 che è molto vicino al 168,7% venuto ai francesi rispetto il fx8370 stock. Così i numeri tornano e aggiungo:
4100*0,311= 1275,1 che è circa poco più del doppio di un fx8350.
Ti ricordi quando dicevo che era plausibile uno zen che avesse un punteggio doppio rispetto ad un fx8350 a parità di frequenza? Ecco e già torna con un ES A0 buggato. Pensa pure senza bug

[Gioz]

dice:
The Piledriver-based FX-8370 is handily beaten by AMD's new offering, by 60.4%. Let's assume that Zen can overclock to the FX-8370's all-core turbo frequency of 4.10 GHz (also shared by the FX-8350), and in a clock-for-clock comparison, Zen is outpacing Piledriver by a collosal 99.2%, while it silently becomes the fastest chip on the graph — a lead on the i7-6900K by 8.4%!

che credo si possa rendere come:
l'Fx8370 basato su Piledriver è agevolmente sconfitto dalla nuova proposta di AMD con un margine del 60,4%.
Assumendo che Zen si possa overcvlockare fino alla stessa frequenza di turbo di 4.1GHz su tutti i core del 8370(condivisa anche dal 8350), e in un paragone clock a clock, Zen si distacca da Pildriver di un mastodontico 99,2%, diventando tranquillamente il più veloce dei chip nel grafico - in testa al 6900K con margine di 8,4%

quindi assume che 99,2% sia l'incremento medio di IPC rispetto a 8350 in funzione dei test di canard sul 8370, da cui prestazione di PD x 1,992 = Prestazione di Zen che è in linea con quello del leak considerato fake.

rapporta le frequenze e moltiplica per questo coefficiente per derivare il punteggio che starebbe a zen a vari clock.

può essere anche tutto giusto e vero, però mi sembrano i calcoli babilonesi che non avrebbe dovuto affrontare Leuconoe per conoscere il futuro...

Originariamente inviato da Mister D

Ti ricordi quando dicevo che era plausibile uno zen che avesse un punteggio doppio rispetto ad un fx8350 a parità di frequenza? Ecco e già torna con un ES A0 buggato. Pensa pure senza bug

penso che ci siano ottime possibilità, le prestazioni sicuramente ci sono, non sono in grado di quantificarle ma se il prezzo sarà favorevole potrebbe essere davvero molto interessante.