[Thread Ufficiale] Aspettando ZEN

[paolo.oliva2]

Originariamente inviato da bjt2

Hanno detto che ci sono migliaia di sensori sparsi per il chip... Immagino che faccia salire il clock finchè qualche sensore gli dice che la temperatura/corrente/tensione è troppo alta...

La mia curiosità è su che base venga applicato il valore di Vcore, se soggettivo a quel procio o sul valore peggiore di quel modello di procio.

Cioè... ogni procio ha un suo Vcore ad una determinata frequenza e richiederà un Vcore via via superiore all'aumentare della frequenza... ma prendendo il procio sfigatello ed il procio fortunello, la differenza potrebbe essere consistende specie con l'OC massimo.. supponiamo verso i 5GHz.
E poi la differenza non credo sia in 1-2 core alla massima frequenza turbo, quanto in 8 core 16 TH sotto carico a frequenze medio-alte, perchè un +0,05V potrebbero dire tranquillamente +5° e di qui segare l'OC.

Poi penso che sia impossibile fare una selezione dei proci e modificare il parametro Vcore def dell'XFR, perchè ci potrebbe essere il procio che richiede un Vcore inferiore alla frequenza def ma poi ne richiede un tot per salire, mentre un altro che richiede un Vcore maggiore a def ma sale che è una delizia.

Facendo un parallelismo a BD e 32nm, se occo 1 core di un 8350 e gli do' 1,55V o 1,6V a @5,3GHz, non mi frega una tozza perchè le temp non è che salirebbero di molto, ma diverso è un 9590 che per i 4,7GHz AMD assegnava 1,5V+ quando un 8350 non selezionato arriva prossimo ai 5GHz a quel Vcore.

[Theodorakis]

Originariamente inviato da bjt2

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

Qui si afferma che Agner è rimasto anni indietro, e che scrive cose non più vere.

http://www.bitsandchips.it/forum/vie...9903&start=430

[paolo.oliva2]

Originariamente inviato da Ryddyck

Questo vi è sfuggito? http://ranker.sisoftware.net/show_ru...284f7cafa&l=en e confronto con il 6900k http://ranker.sisoftware.net/show_ru...284f7cafa&l=en
http://www.dailytech.com/AMDs+2017+L...ticle38953.htm

Preview di vega tra qualche giorno

La frequenza massima di OC per un 6900K qual'è? Non intendo ad azoto, ma un OC-bench corposo ma in sicurezza.

In quel link che hai postato, ad esempio, il team danese di OC è composto da 5 persone... 4 si fermano a 4,3GHz e solamente 1 arriva a 4,4GHz, e stiamo parlando di persone che postano un valore bench il più alto possibile.

Se questi arrivano a 4,3GHz, in OC-Bench, un RS/DU a quanto dovrebbe essere? 4GHz? Ma si può avere un dato preciso senza sparate di bandiera?

[Ryddyck]

Meglio questo? http://ranker.sisoftware.net/show_ru...a8cffc2fb&l=en
Ma ce ne stanno ancora comunque http://ranker.sisoftware.net/show_ru...c8af9c4fd&l=en http://ranker.sisoftware.net/show_ru...98ffcc1f8&l=en - http://ranker.sisoftware.net/show_ru...583f0cdf4&l=en (Alienware Area-51 r2) - http://ranker.sisoftware.net/show_ru...086f5c8f1&l=en (Hp Omen)
E comunque era preso da un sito giapponese http://blog.livedoor.jp/nichepcgamer...063391211.html

[paolo.oliva2]

Originariamente inviato da Ryddyck

Meglio questo? http://ranker.sisoftware.net/show_ru...a8cffc2fb&l=en
Ma ce ne stanno ancora comunque http://ranker.sisoftware.net/show_ru...c8af9c4fd&l=en http://ranker.sisoftware.net/show_ru...98ffcc1f8&l=en
E comunque era preso da un sito cinese

Ancora peggio... questi occano il 6900K al max @4,2GHz, poi 4GHz, 3,8GHz e 3,7GHz.
Mi trovo in difficoltà a capire... qui si dice @4,5GHz RS/DU, se fai di meno, il procio è sfigatello, ma lì su 10 persone sono tutte sfigate?

Le frequenze sono importanti perchè sembra che con XFR, in Zen l'OC sia automatico e a frequenze di molto superiori al 6900K.
Del resto l'abbiamo visto nei bench di confronto fatti da AMD, il 6900K che frequenze massime ha raggiunto? @3,4GHz? @3,5GHz? Forse manco sufficienti per arrivare alla frequenza def minima di Zen.
Magari si potrebbe pareggiare occando il 6900K manualmente... ma è impossibile capire la frequenza reale raggiungibile... per quanto scritto sopra.

[Ryddyck]

Rileggi il messaggio, l'ho modificato con configurazioni stock (hp omen e alienware area51-r2 che in teoria non dovrebbero nemmeno avere tra le versioni disponibili il 6900k)

[Mister D]

Originariamente inviato da paolo.oliva2

Onestamente tutto sta a come inserisci il discorso nel contesto.
Dall'8088 ad oggi sono passati 40 anni... ma fondamentalmente nel computer cosa è cambiato? L'S.O. a 64 bit, standard più veloci negli HD/VGA, la parallela e RS232C che ha lasciato il posto all'USB... i proci che sono diventati più veloci e complessi... però...
Il tutto è vincolato a retro-compatibilità e ad interessi... e nessuno ha la potenza necessaria per sdradicare l'attuale e creare un nuovo di sana pianta.
Poi che AMD ha fatto qualche passo nella direzione giusta, ma parliamo di millimetri rispetto a quello che si potrebbe fare... e poi il mio era un discorso di principio e non di bandiera.

Lo so Paolo, ma a volte nella vita bisogna essere un po' più realisti e purtroppo quello che ha visto amd e quello che speriamo in molti è un filo utopico al momento. Magari fra 5 anni non lo sarà perché nel frattempo cambieranno isa, paradigmi di programmazione e si potrà sfruttare a pieno gli sp per tutti i compiti di una fpu odierna. Non dico che il progetto fusion non sia stata una bella iniziativa perché in fin dei conti ha smosso le acque, solo che ci vuole tempo e pazienza per arrivare a quell'obiettivo.

[bjt2]

Originariamente inviato da paolo.oliva2

La mia curiosità è su che base venga applicato il valore di Vcore, se soggettivo a quel procio o sul valore peggiore di quel modello di procio.

Cioè... ogni procio ha un suo Vcore ad una determinata frequenza e richiederà un Vcore via via superiore all'aumentare della frequenza... ma prendendo il procio sfigatello ed il procio fortunello, la differenza potrebbe essere consistende specie con l'OC massimo.. supponiamo verso i 5GHz.
E poi la differenza non credo sia in 1-2 core alla massima frequenza turbo, quanto in 8 core 16 TH sotto carico a frequenze medio-alte, perchè un +0,05V potrebbero dire tranquillamente +5° e di qui segare l'OC.

Poi penso che sia impossibile fare una selezione dei proci e modificare il parametro Vcore def dell'XFR, perchè ci potrebbe essere il procio che richiede un Vcore inferiore alla frequenza def ma poi ne richiede un tot per salire, mentre un altro che richiede un Vcore maggiore a def ma sale che è una delizia.

Facendo un parallelismo a BD e 32nm, se occo 1 core di un 8350 e gli do' 1,55V o 1,6V a @5,3GHz, non mi frega una tozza perchè le temp non è che salirebbero di molto, ma diverso è un 9590 che per i 4,7GHz AMD assegnava 1,5V+ quando un 8350 non selezionato arriva prossimo ai 5GHz a quel Vcore.

Credo che ci siano anche delle repliche di circuiti significativi (es: adder), fatti magari un po' più lenti, che vengono controllati in tempo reale: si sale fino alla frequenza in cui iniziano a sbagliare i calcoli...

[bjt2]

Originariamente inviato da Theodorakis

Qui si afferma che Agner è rimasto anni indietro, e che scrive cose non più vere.

http://www.bitsandchips.it/forum/vie...9903&start=430

Quello che ha scritto agner si riferisce al compilatore INTEL che ha default SSE2, quindi se quello che hai linkato dice il vero, allora quello che cambia è solo il default a SSE3... Ma siamo nel 2017 e le CPU AMD supportano 4.1, 4.2, AVX, AVX2... Questo è uno dei motivi per cui AMD non si sbatte a fare unità a 256 bit... Se il compilatore INTEL usa codice generico a 128 bit per AMD sarebbe solo uno spreco di spazio. Invece faccio una CPU che macina 4 operazioni a 128 bit e nel codice fatto con compilatori vecchi ho vantaggi. Immagino che il compilatore INTEL sia costoso e che molte software house non si sbattono ad aggiornare...

[bjt2]

Originariamente inviato da Veradun

Il 6900K è il ~65% più veloce in quel test, mi sembra fuori di dubbio che quel test non ha alcun senso

Ho letto da altre parti (mi pare Anand) che quel punteggio è lo stesso fatto da un 6950 occato a 4GHz e che quindi quel punteggio è di un 6900K occato ad almeno 4.2GHz... Sisandra non rileva correttamente il clock a quanto pare...

[Theodorakis]

Originariamente inviato da bjt2

Immagino che il compilatore INTEL sia costoso e che molte software house non si sbattono ad aggiornare...

Neppure tanto costoso da quello che vedo: https://software.intel.com/en-us/try-buy-tools

[paolo.oliva2]

Originariamente inviato da bjt2

Quello che ha scritto agner si riferisce al compilatore INTEL che ha default SSE2, quindi se quello che hai linkato dice il vero, allora quello che cambia è solo il default a SSE3... Ma siamo nel 2017 e le CPU AMD supportano 4.1, 4.2, AVX, AVX2... Questo è uno dei motivi per cui AMD non si sbatte a fare unità a 256 bit... Se il compilatore INTEL usa codice generico a 128 bit per AMD sarebbe solo uno spreco di spazio. Invece faccio una CPU che macina 4 operazioni a 128 bit e nel codice fatto con compilatori vecchi ho vantaggi. Immagino che il compilatore INTEL sia costoso e che molte software house non si sbattono ad aggiornare...

Mi suonava strano che Keller, dopo aver fatto di tutto di più su Zen, avesse deciso per l'FPU a 128bit su basi completamente diverse dal progetto Zen in toto.
Direi che probabilmente Keller, avendo fatto questa scelta, avrà adottato pure soluzioni atte a far lavorare meglio l'FP 128bit con istruzioni 256bit... (potrebbe essere le 4 pipeline?)

[bjt2]

Originariamente inviato da paolo.oliva2

Mi suonava strano che Keller, dopo aver fatto di tutto di più su Zen, avesse deciso per l'FPU a 128bit su basi completamente diverse dal progetto Zen in toto.
Direi che probabilmente Keller, avendo fatto questa scelta, avrà adottato pure soluzioni atte a far lavorare meglio l'FP 128bit con istruzioni 256bit... (potrebbe essere le 4 pipeline?)

Certo. Intel ne ha 2 FP, ma a 256 bit e AMD ne ha 4 ma a 128 bit. Se avessero fatto 4 FMAC invece di 2 FMUL e 2 FADD, a parte la banda verso la memoria avremmo le stesse teoriche FLOP dei core intel... Intel ne ha 3x256 ma di vecint. Le FP sono 2x256... E mi pare che una può fare FMA e FADD e una FMA e FMUL a 256 bit... Quindi 2 FADD o 2 FMUL a 256bit non si possono fare in un ciclo, a meno di non usare una FMA con moltiplicando 1, mentre in Zen si.

[digieffe]

@paolo

da quanto ho potuto leggere il 6900k gira tra i 4.0 ed i 4.2 in base al fattore C ed al raffreddamento.

oltre potrebbe anche essere ma parliamo di casi rari

[alexsky8]

Originariamente inviato da bjt2

Molti non si rendono conto che se il turbo max (o effettivo dopo XFR) è sui 4.5-4.6GHz, effettivamente Zen sarebbe la "fusione" tra quadcore e octacore, qualunque fosse la frequenza di base (purchè sopra i 3.4GHz)... Questo perchè con software poco threaded, avrebbe frequenze come il 7700K e quindi ci battaglierebbe, e con molti thread avrebbe si frequenze basse, ma avrebbe più core del 7700 e quindi andrebbe mooooolto di più... Insomma la panacea di tutti i mali...

E molti ancora non si rendono conto dell'evento New Horizon. Zen ha pareggiato in blender e superato in handbrake un chip INTEL con clock finali e turbo attivato, avendo clock non finali e turbo disattivato... Anche se il clock base dovesse rimanere 3.4GHz, il turbo gli darebbe almeno una spinta media di 200-300Mhz... E quindi un altro 10% dai livelli di New Horizon...

io ho solo un timore....il prezzo
se davvero questo ZEN 8+8 può giocarsela con un 4core intel di alta gamma (lato frequenze) e al tempo stesso con una CPU MT di alta gamma non posso credere che AMD lo regali a 400€ ma piuttosto ci sarebbe il serio rischio di vederlo più verso i 550/600€

[paolo.oliva2]

Originariamente inviato da digieffe

@paolo
da quanto ho potuto leggere il 6900k gira tra i 4.0 ed i 4.2 in base al fattore C ed al raffreddamento.
oltre potrebbe anche essere ma parliamo di casi rari

Ed è questo che volevo sottolineare.

Supponiamo la condizione che uno voglia acquistare un X8+8, e che Zen permetta un RS/DU di 4GHz (valori a caso) mentre il 6900K 4,5GHz come lo si vuole far credere. Uno potrebbe essere invogliato ad acquistare il 6900K... poi invece si ritrova un OC pari (se non iferiore) a Zen, e magari passare pure per idiota con la scusa "il tuo procio è sfigato".

E' o non è disinformazione?

[Roland74Fun]

Le info più recenti su
[email protected].

145 euro Zen APU 4c/4t 3.0 GHz = Pentium G3210

256 euro RyZen 4c/4t 3.5 GHz = PentiumG 4500
(uguale all'apu ma senza vga integrata)

385 euro RyZen 4c/8t 3.4 GHz = i3 4310

422 euro RyZen 6c/6t 3.2 GHz = i3 6300

599.99 euro RyZen 8c/8t 3.6 GHz = i5 4440

799,99 euro RyZen 8c/16t 3.7 GHz = i5 6400

[CiccoMan]

Originariamente inviato da Roland74Fun

Le info più recenti su
[email protected].

145 euro Zen APU 4c/4t 3.0 GHz = Pentium G3210

256 euro RyZen 4c/4t 3.5 GHz = PentiumG 4500
(uguale all'apu ma senza vga integrata)

385 euro RyZen 4c/8t 3.4 GHz = i3 4310

422 euro RyZen 6c/6t 3.2 GHz = i3 6300

599.99 euro RyZen 8c/8t 3.6 GHz = i5 4440

799,99 euro RyZen 8c/8t 3.7 GHz = i5 6400

... sono solo io a pensare che c'è qualcosa che non va?

[VanCleef]

Originariamente inviato da CiccoMan

... sono solo io a pensare che c'è qualcosa che non va?

Per me sono sovrastimate... L'APU RR non andrà più di un Celeron n3060 mobile...

[paolo.oliva2]

Originariamente inviato da alexsky8

io ho solo un timore....il prezzo
se davvero questo ZEN 8+8 può giocarsela con un 4core intel di alta gamma (lato frequenze) e al tempo stesso con una CPU MT di alta gamma non posso credere che AMD lo regali a 400€ ma piuttosto ci sarebbe il serio rischio di vederlo più verso i 550/600€

Scusa, te la faccio lunga perchè altrimenti sarebbe incomprensibile un Zen X8 a 300$ e nel contempo a 600$

Secondo me... c'è un qualche cosa che non torna considerando Zen X8 95W, in accoppiata XFR, visto come funzionamento i7 X4 e 6900K.
Partiamo dal presupposto che AMD ci ha fatto vedere Zen efficiente quanto un 6900K, cioè Zen 95W produce 101, il 6900K a 96W produce 99.
Però sappiamo che il 6900K ha un TDP def di 140W e in alcune situazioni ci arriva a quei 140W. Come può Zen con 95W e la stessa efficienza fornire gli stessi dati elaborati da un 6900K a 140W?
Secondo me il "trucco" di AMD sarà l'XFR visto sia come aumento di frequenza in base al carico e ai core utilizzati, ma anche con il TDP massimo disponibile visto come limitatore.
Un i7 X4+4 è 95W? Beh... un Zen X8+8 allo stesso TDP, ma senza iGPU, con un CCX disattivato (stesso carico di un i7 X4) in linea di massima (a parte PP silicio) dovrebbe ottenere le stesse frequenze massime e quindi le stesse prestazioni e AMD prezzarlo di conseguenza (rispetto ai rumors circa 300$).
Ma come commercializzare un X8+8 a 300$ che non danneggi le vendite dei modelli superiori? Per me la soluzione è il TDP nominale, fisso a 95W, >95W e libero, in accoppiata a XFR.

Inoltre, sono dell'opinione che il 6950X prenderà il posto del 6900K come prezzo, quindi il 6900K calerà e di conseguenza idem il 6850K.
Occhio, perchè il 6850K è una gran bella CPU, nel senso che arriva ad un ST simile agli i7 X4, ma con +50% di core, ed un 6850K a 400$, sarebbe una gran gatta da pelare per Zen.