Ryzen 7 1800X: la nuova rinascita di AMD nel mondo delle CPU

[lucusta]

Originariamente inviato da cdimauro

Non puoi farlo, perché è il gioco stesso che lancia più thread hardware (o processi, se dovessero servirgli), e non puoi reindirizzarli come / dove vuoi.

non ne sono sicuro ed ho già qualche idea come realizzarlo, e se le ho io e probabile che le abbiano già realizzate.
l problema di RyZen è evidente che è dovuto allo scheduler ed alla sua cieca distribuzione dei carichi, che và a braccetto con la gestione dei power state.

è sufficiente un layer software d'indicizzazione.

lo scheduler è sempre stato il punto debole delle macchine windows, e credo che in futuro s'interverrà su quello.
associare stato istantaneo della risorsa e verificare che i dati che dovrà usare
siano già locali facilita enormemente compito e latenze.

ad oggi si puo' fare un workarround fittizio.
occupare il core con un thread dormiente che lo usa al 100%, ma che lo usa a P-state piu' basso che c'e'.
lo scheduler lo scarterà a priori;

insomma, li fai diventare dei quad core su codice da quad core.

cosi' facendo puoi mantenere 4 core a un bassissimo valore di frequenza e vcore, e lasciare agli altri la possibilità di sfruttare il TDP massimo.
tutto, logicamente, dipende dal silicio, lo sai... ed AMD in questo momento non lo ha, sembra evidente.
vedremo sui quad veri.

[LMCH]

Originariamente inviato da cdimauro

Ho letto anche le eccellenti recensioni (molto complete e dettagliate: la prima più per le applicazioni, la seconda più per i giochi) di hardware.fr e computerbase.de, e anche quella di Phoronix su Linux & compilatore GCC (la recensione è un po' esotica: testano applicazioni per lo più diverse da quelle degli altri recensori), ma il trend rimane lo stesso o anche un po' peggiore rispetto a quello visto finora.

Non solo la cache (in particolare la L3. Vedi dopo), ma credo che sia la micro-architettura di per sé a essere intrinsecamente poco efficiente.

Qui trovi un'analisi dell'IPC, suddivisa per applicazioni e giochi, che penso sia abbastanza eloquente, specialmente coi giochi, dove c'è un abisso rispetto a Broadwell-E.

Qui un'analisi sul cache & memoria, dove si vede che la latenza della cache L2 è del 34% maggiore, mentre per la L3 addirittura del 270% (non è uno scherzo: è quasi il triplo!) maggiore. Anche l'accesso alla memoria è più lento, di circa il 40%.

Infine, nell'unico test (Himeno, di Phoronix) in cui vengono usate appositamente le AVX-2 e ottimizzazione massima (-O3, con GCC. Ma sulle ottimizzazioni si è discusso di recente, in un altro thread. Dunque prendilo comunque con le pinze), Haswell-E (i7-5960X. Purtroppo non c'è il 6900K / Broadwell-E) risulta più veloce del 59%, mentre Kaby Lake (i7-7700K) arriva a uno stratosferico +245%.
Ma ripeto: è UN solo test, che va preso con le pinze. Come ho già ripetuto innumerevoli volte, mi piacerebbe vedere molti più test con AVX/-2, e magari con compilatori diversi (GCC e pure Intel), con ottimizzazioni massime per specifiche micro-architetture.

Da tutte le recensioni che ho letto (mi manca solo Tom's. Sono ANNI che non leggo recensioni da quel sito , ma questa volta farò un'eccezione perché mi interessano i test con AVX. Se ce ne sono altri), finora sembra che il limite sia di 4Ghz, e alcuni sono arrivati a 4,1Ghz, ma in ogni caso con v-core molto alti, e consumi che sono arrivati alle stelle.

Se si guardano le latenze in base al working set sul primo link che avevi indicato
Si nota che le latenze aumentano in modo drastico quando si superano i 4MB ovvero quando si superano le dimensioni della L3 "contigua" in un blocco di 4 core e si deve accedere alla L3 sull'altro blocco.
(la cosa non è ovvia perché i grafici delle latenze non sono visualizzati insieme).

Una volta che saranno superati i problemi di tuning e di messa a punto del firmware delle nuove schede madri che supportano i Ryzen e gli scheduler dei S.O. terranno conto delle particolarità a livello di gerarchia della memoria ed affinità dei thread mi sa che si rileveranno ulteriori miglioramenti nelle prestazioni.

Non mi aspetto miglioramenti sconvolgenti, ma in compenso i Ryzen 5 (che avranno un singolo gruppo di 4 core) mi sa che avranno prestazioni molto buone e con meno "sorprese".

[cdimauro]

Originariamente inviato da Ale55andr0

Basta pensare che il parco titoli futuro si baserà su macchine ad 8 core...e scorpio potrebbe avere proprio ryzen lato cpu (ovviamente a basso clock) a quel che si dice. Ma ryzen o meno 8 thread hardware in ogni caso

Non credo che Scorpio avrà Ryzen: i core sono troppo grandi e consumano troppo. Jaguar è la soluzione migliore in questi ambiti. /OT.

Comunque per sfruttare più core nei giochi ci vorrà tempo, ma non sta scritto da nessuna parte che si potranno usare tutti quelli a disposizione, e a piano carico.

Certamente col tempo verranno usati più core, ma quanti e come è tutto da vedere.

Originariamente inviato da gd350turbo

È un fatto estremamente positivo che AMD abbia compiuto il miracolo e spero che ne vendano un casino...
In tal modo Intel si desterà dal torpore da cui era avvolta dai tempi del C2, si rimetta a lavorare come sa fare e produca delle prossime generazioni di processori con le cosiddette "balls"!

Non vedo perché. Mi sembra evidente che, numeri e numerosi test alla mano, le sue micro-architetture (anche quelle meno recenti) si comportino ancora mediamente molto bene. Perché dovrebbe cambiare qualcosa che funziona?

Ma certamente dovrà abbassare i prezzi e proporre soluzioni con più core per essere competitiva con le soluzioni di AMD che, come dicevo, a livello di prezzo e prestazioni MT (con certe applicazioni) sono imbattibili.

Originariamente inviato da gridracedriver

http://www.bitsandchips.it/9-hardwar...ei-videogiochi
cosa del tutto normale dopotutto è una uarch completamente nuova

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

[Piedone1113]

Originariamente inviato da cdimauro

Corretto. Anche se purtroppo è difficile farlo capire.

Invece qui ha ragione MiKeLezZ: il compilatore ha certamente un suo valore e Intel guadagna dalla sua vendita, ma nasce in funzione / a supporto delle vendite delle CPU.

Intel non è una software house. Il software è soltanto il contorno / supporto al suo (vero) business: il silicio.

Allora ho interpretato male i bilanci di Intel dove risulta che il 53% del fatturato arriva dal silicio ( quindi ci ho inserito non solo le cpu ma tutto il resto che esce dalle fonderie) il fumante 47% quindi arriva da ( brevetti, sas, schede varie)?

[cdimauro]

Originariamente inviato da Pino90

OT, scusate

@cdimauro

In merito alla tua domanda/dubbio sull'uso del multithreading in numpy/scipy, dipende molto da quali algoritmi/strutture dati vengono usati nei bench.

In generale no, non usa moltissimo il MT, soprattutto perché molti problemi risolti da quelle librerie non sono facilmente parallelizzabili, e anche quando è fattibile andare in parallelo non sempre è stato fatto (networkx ad esempio o tutto il package del clustering).

Vero. Ma vedi sotto.

Originariamente inviato da fraquar

E, ad esempio, se viene usato Intel MTK o OpenBlas

Sì, e infatti va MOOOOLTO meglio. Come dicevo, la versione di (C)Python che Intel ha realizzato, sfrutta le sue librerie e il suo compilatore, e arriva a prestazioni eccezionali.

Purtroppo non ho trovato i test che arrivavano a circa 10 mila volte meglio di CPython. Intanto vedi qui.

Originariamente inviato da bjt2

Questa estrema variabilità di Ryzen su Handbrake, rispetto al 6900K non può essere dovuta ai settings o al file. E' troppo elevata. Io penso che dipenda dalla diversa marca di MB che è stata data ad ogni reviewer, se avevano fatto l'aggiornamento BIOS, se avevano disabilitato HPET e core parking, ecc... Ci sono troppe variabili. Io prenderei il miglior risultato, ossia quello in cui il 1800X supera anche il 6950. Questo è il miglior risultato in handbrake e dovrebbe essere riproducibile anche con altre MB prima o poi...

Sì, c'è molta variabilità, ma proprio perché si usano settaggi e file diversi. Handbrake non serve solo a effettuare transcodifica, ma anche di applicare filtri, scaling, ecc.

[Piedone1113]

Originariamente inviato da cdimauro

Non credo che Scorpio avrà Ryzen: i core sono troppo grandi e consumano troppo. Jaguar è la soluzione migliore in questi ambiti. /OT.

Comunque per sfruttare più core nei giochi ci vorrà tempo, ma non sta scritto da nessuna parte che si potranno usare tutti quelli a disposizione, e a piano carico.

Certamente col tempo verranno usati più core, ma quanti e come è tutto da vedere.

Non vedo perché. Mi sembra evidente che, numeri e numerosi test alla mano, le sue micro-architetture (anche quelle meno recenti) si comportino ancora mediamente molto bene. Perché dovrebbe cambiare qualcosa che funziona?

Ma certamente dovrà abbassare i prezzi e proporre soluzioni con più core per essere competitiva con le soluzioni di AMD che, come dicevo, a livello di prezzo e prestazioni MT (con certe applicazioni) sono imbattibili.

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

Non taglio per via del cell.
Considera solo la prima parte.
Credo che ti sbagli, Zen sembra molto più adatto a frequenze basse che alte, sopratutto con il turbo.
Credo che un 8 core senza smt possa girare tranquillamente a 1800-2000 mhz con turbo 2600 al core ( questo dipende dinamicamente dal tipo di carico) entrò i 25w.
Un solo ccx con ht attivo a quelle frequenze lo potremmo valutare in 15w ( con la parte nb ridotta perché non servono tutte le fratture da desktop su consolle)

[digieffe]

Originariamente inviato da cdimauro

Allora AMD avrebbe fatto bene a spostare il lancio di un paio di settimane, in modo da dare la possibilità di avere firmware/BIOS più aggiornati & stabili & performanti, ma soprattutto molto più tempo ai redattori per lavorare, e nel caso in cui fossero stati rilevati dei problemi (come sembra ci siano), segnalarlo ad AMD, aspettare il fix, e ritornare a lavorare per arrivare alla recensione finale e ben ponderata.

AMD forse non s'è resa conto dell'enorme danno che s'è fatta con questa politica del lancio a tutti i costi, con una piattaforma immatura.

Perché la gente ricorderà le recensioni che sono state fatte ORA: non gli aggiornamenti che arriveranno fra un po'! Anche perché voglio vedere chi saranno quei redattori che rifaranno da capo TUTTO il lavoro.

E' chiaro che quel è uscito ieri sarà destinato a rimanere decisamente più impresso. Nel bene e nel male...

d'accordo su tutto tranne sul fatto che i redattori "seri" metteranno una pezza alle recensioni, quindi i più addentrati conosceranno la versione finale

Sì, le ha fatte, e un utente le ha riportate poco fa. A seconda dei casi, Ryzen ne risente di più. Alcune volte ne risente di più la piattaforma Intel.

Difficile, senza test ad hoc, stabilire dove stiano i problemi.

Comunque se controlli i numeri, l'impatto che ha l'SMT è decisamente inferiore rispetto alla differenza prestazionale che Ryzen con la concorrenza (che comunque è anch'essa penalizzata dall'SMT, visto che è tenuto acceso. Mi riferisco alle soluzioni Intel con più di 4 core).

questo era intuibile, quando ci sarà un'analisi accurata o i fix vedremo il reale impatto

[cdimauro]

Originariamente inviato da Bivvoz

Non mancano Mhz, windows (ma anche linux immagino) ha problemi con l'SMT AMD (e non c'è da stupirsi visto che è nuovo).
Spegnendo SMT già si migliora sopratutto gli FPS minimi, ma poi ovviamente si sta usando un processore a metà.
Attesa patch per sistemare il problema.

Guardate per esempio la differenza tra stock con SMT e stock senza.

Purtroppo non hanno disabilitato l'SMT anche sui processori Intel con più di 4 core. In particolare al 6900K, che è diretto concorrente del 1800x (8 core).

Originariamente inviato da HwWizzard

Non c'è un abisso tra Zen e Broadwell-E visto che il grafico è fuorviante
L'unico caso dove la differenza è piuttosto marcata è 7Zip dove come visto in un intervento di leoneazzurro sembra esserci un grave problema con i BIOS.
Cmq è innegabile che l'IPC di Zen sia inferiore a quello di Broadwell-E e SL-KL ma l'abisso non c'è

Ho usato la parola abisso per quanto riguarda i giochi, e se vedi il link, direi che i numeri siano lo eloquenti.

Comunque oltre a 7-Zip c'è WinRAR (che essendo un compressore, avrà un comportamento simile, ovviamente), e Adobe Lightroom, dove c'è un bel divario.

Ripeto, queste CPU sono uscite per scontrarsi con quelle sul socket 2011 e lo fanno alla grande, intel ha più IPC mentre AMD è salita più in frequenza, sono scelte, il dubbio mi rimane per gli R5 che non dovessero superare abbondantemente i 4Ghz diventerebbero dei mezzi fail.

Beh, alla fine le prestazioni sono il risultato di IPC * frequenza.

I test sull'IPC sono pochi, ma quanto a quelli prestazionali direi che ce ne siano un'enorme quantità ormai.

Originariamente inviato da leoneazzurro

Intendevo con Handbrake, non nel gaming.

Ah, OK. Allora avevo frainteso. Comunque su Handbrake ci sono risultati molto diversi, a causa della diversità di sample e/o settaggi utilizzati.

C'è persino un test che ho visto, e in cui il 6900K è di più del 25% più veloce del 1800X, per dire.

Per il gaming è per forze di cose indietro al 7700K in molti giochi (era atteso), lo è anche il 6900K, il problema di scheduling è palese dove c'è una differenza marcata tra 6900K e 1800X

Ed è un peccato che non sia stato disattivato l'SMT anche sul 6900K, dove qualche recensore ha fatto anche questa prova.

[cdimauro]

Originariamente inviato da digieffe

ad occhio Himeno è ST o pochi TH

Direi che è praticamente solo ST.

se trovo recensioni in AVX/-2 t'informo

Grazie!

basta prendere le recensioni di Tom's cum grano salis

Come sempre.

Originariamente inviato da lucusta

non ne sono sicuro ed ho già qualche idea come realizzarlo, e se le ho io e probabile che le abbiano già realizzate.
l problema di RyZen è evidente che è dovuto allo scheduler ed alla sua cieca distribuzione dei carichi, che và a braccetto con la gestione dei power state.

è sufficiente un layer software d'indicizzazione.

lo scheduler è sempre stato il punto debole delle macchine windows, e credo che in futuro s'interverrà su quello.
associare stato istantaneo della risorsa e verificare che i dati che dovrà usare
siano già locali facilita enormemente compito e latenze.

ad oggi si puo' fare un workarround fittizio.
occupare il core con un thread dormiente che lo usa al 100%, ma che lo usa a P-state piu' basso che c'e'.
lo scheduler lo scarterà a priori;

insomma, li fai diventare dei quad core su codice da quad core.

cosi' facendo puoi mantenere 4 core a un bassissimo valore di frequenza e vcore, e lasciare agli altri la possibilità di sfruttare il TDP massimo.

Sì, potrebbe essere sufficiente questo workaround.

tutto, logicamente, dipende dal silicio, lo sai... ed AMD in questo momento non lo ha, sembra evidente.

Certamente il processo a "14"nm di GF non è a livello di quello di Intel.

vedremo sui quad veri.

Che integrano GPU, mi pare.

[cdimauro]

Originariamente inviato da LMCH

Se si guardano le latenze in base al working set sul primo link che avevi indicato
Si nota che le latenze aumentano in modo drastico quando si superano i 4MB ovvero quando si superano le dimensioni della L3 "contigua" in un blocco di 4 core e si deve accedere alla L3 sull'altro blocco.
(la cosa non è ovvia perché i grafici delle latenze non sono visualizzati insieme).

Ryzen ha 16MB di cache L3, per cui un CCX ne contiene 8MB, e quindi il decadimento dovrebbe esserci superando gli 8MB (strettamente oltre, visto che è di tipo evict), e non dopo i 4MB.

Una volta che saranno superati i problemi di tuning e di messa a punto del firmware delle nuove schede madri che supportano i Ryzen e gli scheduler dei S.O. terranno conto delle particolarità a livello di gerarchia della memoria ed affinità dei thread mi sa che si rileveranno ulteriori miglioramenti nelle prestazioni.

Non mi aspetto miglioramenti sconvolgenti, ma in compenso i Ryzen 5 (che avranno un singolo gruppo di 4 core) mi sa che avranno prestazioni molto buone e con meno "sorprese".

Infatti non credo anch'io che ci saranno rivoluzioni. Vedremo coi 4 core, per l'appunto, ma ci vorranno ancora un po' di mesi.

Originariamente inviato da Piedone1113

Allora ho interpretato male i bilanci di Intel dove risulta che il 53% del fatturato arriva dal silicio ( quindi ci ho inserito non solo le cpu ma tutto il resto che esce dalle fonderie) il fumante 47% quindi arriva da ( brevetti, sas, schede varie)?

Sicuro che sia solo il 53%? Ricordavo numeri diversi. Comunque è tardi, e non ho voglia di cercare. Ho finito coi messaggi, e mi fiondo a letto.

Originariamente inviato da Piedone1113

Non taglio per via del cell.
Considera solo la prima parte.
Credo che ti sbagli, Zen sembra molto più adatto a frequenze basse che alte, sopratutto con il turbo.
Credo che un 8 core senza smt possa girare tranquillamente a 1800-2000 mhz con turbo 2600 al core ( questo dipende dinamicamente dal tipo di carico) entrò i 25w.
Un solo ccx con ht attivo a quelle frequenze lo potremmo valutare in 15w ( con la parte nb ridotta perché non servono tutte le fratture da desktop su consolle)

E immagina un cluster Jaguar quanto potrebbe consumare.

Originariamente inviato da digieffe

d'accordo su tutto tranne sul fatto che i redattori "seri" metteranno una pezza alle recensioni, quindi i più addentrati conosceranno la versione finale

Ma non credo che rifaranno nuovamente tutti i test.

Mi aspetto che ne facciano un po', e basta.

questo era intuibile, quando ci sarà un'analisi accurata o i fix vedremo il reale impatto

*

Buona notte a tutti.

[digieffe]

Originariamente inviato da cdimauro

A meno che non carichi 8 pagine contemporaneamente, non te ne faresti niente.

Il caricamento è l'operazione più impegnativa, e incide di più sul ST. Fatto questo, poi il consumo di CPU per una pagina è praticamente nullo. In questo momento ho quasi 60 pagine aperte, YouTube che riproduce uno spezzone di Cetto La Qualunque , e il mio i7-6700K è occupato il 3-4% circa.

normalmente le mie sessioni medie sono composte da 50+ pagine su alcune sessioni (doc tecnica) arrivo anche a 200... e quando apro chromium me le tira tutte su contemporaneamente a volte attendo diversi minuti... ovviamente priorità al minimo escludo il core 0 dall'esecuzione e faccio altro in questo caso mi serve sia cpu che bw di rete

[rockroll]

Originariamente inviato da MiKeLezZ

Oh allora i mittttici utenti Bivvoz, *aLe, ionet, Veradun, HwWizzard, rockroll, max72-ITA, riuzasan ??? Dai che vi vengo a prendere uno a uno per le orecchie...

Tutto quello che avevo previsto si è avverato, e ora che si fa???

Non mi sembra un grandissimo risultato esser bastonati da un'architettura Intel del 2015 con metà dei core, o sbaglio?

Belli i millemila core, bello che venga ammazzata la LGA2011 (ponzi ponzi po'... ti piace vincere facile?), ma il guinea pig a comprarli ad oltre 350 euro per invogliare il mercato a sfruttare il multithreading nel consumer lo lascio fare a voi.

In pratica per ora i Ryzen sono rivolti ai pirati di bluray per rippare più velocemente le copie senza svenarsi

Il mittico HwWizzard già si sta prodigando con l'evangelizzazione con il suo "aspettare gli R5 saranno a 5GHz e voleranno"...

Ma da che escono si rischia pure di vedere Cannonlake a 10nm.

Sì sì sogna... Io sono ancora col Dual Core e continuo a giocare, pensa te. Giusto da poco, dopo 7/8 anni, si sente la necessità del Quad Core. Dopo quasi un decennio, l'upgrade ci sta...

Ma che cando vai dicezzo, ragazzo?

Ne hai sparate così tante che ti hanno sospeso? E ora che si fa, mi/ci vieni a prendere per le orecchie? Mi... che paura...

Tieniti i tuoi favolosi Intel spendendo il doppio o limitandoti a giocare a basse risoluzioni per far esaltare la tua tesi da fanboy istituzionale, e non provocare il prossimo, per cortesia.

[rockroll]

Originariamente inviato da Rinz

Credo che litigare sul forum per chi ce l'ha più lungo ( o avrà più lungo) sia sconveniente e puerile. Anche perché a voi non torna nulla in tasca.

Ho letto solo un altra rece oltre a questa e i dati (più o meno marcati a seconda di quello che si vuol far apparire) mostrano che queste CPU vanno leggermente peggio nel gaming (e bisogna considerare le risoluzioni, c'è differenza) e si comportamento ottimamente in ambiti fortemente dipendenti dai core ( ma và, ne hanno otto).

Quindi il discorso dovrebbe essere personale e dovrebbe tener conto di quello che uno va effettivamente a farci col PC.
Fermo restando che non conosciamo le prestazione dei Ryzen 5 e 3, le domande che devo farmi sono: gioco col pc o lo uso per altro? Che risoluzione ha il mio monitor? Ma soprattutto: per fare quello che devo fare quanto spendo con una configurazione AMD (cpu+mobo) o con una prestazionalmente simile INTEL? (sempre cpu+mobo).Cosa mi conviene

Poi ognuno può trarre le sue conclusioni, che non devono essere necessariamente uguali per tutti. Puntare su un 8 core potrebbe essere sprecato nel gaming di oggi, ma un domani potrebbe rivelarsi una mossa vincente.

Ottimo intervento, oggettivo e pratico, comprensibile anche da chi non sa interpretare i risultati del grande lavoro di Corsini.

E' esattamente il mio pensiero.

[Tribal23]

Qualcuno aveva richiesto alcuni test nei giochi con l'adozione di rivatuner come GUI per vedere come lavorano i 16 threads, un gruppo di ragazzi sta appena testando, e difatti stanno sfornando test su test in base a quello che gli viene fornito come spunto, un R7 1800X e anche secondo loro le prestazioni sono molto in linea con i7 6°a e 7°a generazione.
questa è una loro playlist su YouTube, attualmente e probabilmente con l'aggiunta di altri video test, a mio parere molto veloci e concisi e stanno attualmente uppando altri video che mano a mano inseriranno.
https://www.youtube.com/playlist?list=PLtxHocGsjK_NGVaWcT3BzONKkqk9TSgDU

[digieffe]

Originariamente inviato da cdimauro

Ryzen ha 16MB di cache L3, per cui un CCX ne contiene 8MB, e quindi il decadimento dovrebbe esserci superando gli 8MB (strettamente oltre, visto che è di tipo evict), e non dopo i 4MB.

Infatti non credo anch'io che ci saranno rivoluzioni. Vedremo coi 4 core, per l'appunto, ma ci vorranno ancora un po' di mesi.

qui la spiegazione (trad. google):

On Ryzen, the behavior is different. In its Hot Chips presentation, AMD noted that access to different parts of the L3 could have a different latency (depending on the core where it is attached) inside a CCX. One can see a behavior of this type on the first 4 MB, and a particularly strong increase beyond. We will not focus on this point without feedback from the authors of the benchmark.

However, the situation beyond 8MB is without appeal: on a 12MB access (in a combined L3 of 16MB), we have a latency close to that which would be obtained if we made the access over- 8 MB in memory.

We asked AMD who confirmed this: in practice, in this case of school the L3 of the second CCX is not used, Ryzen behaving as if it had only 8 MB of L3.

This is a particularity of the benchmark used: to be able to measure the latency correctly, it is essential that the threads are attached to a heart and do not move. However, you probably remember, the L3 cache is a "victim" cache, it contains the data that is removed from the L2 cache. And to fill the L2 cache, access must be made ... inside the CCX. Result, blocking our benchmark (latency is only measured on a thread) on the first core, the other CCX is not solicited, its cache not filling.

This is actually a disadvantage of the architecture even if it is overly theoretical: in practice, Windows 10 loves, we keep saying it, to stroll the software threads from one heart to another.

If AMD could not give us an idea of ​​the latency of an access on the second CCX, it gave us another much more important data: the bandwidth between these two CCX: only 22 GB / s!

Only, as you will have noticed, this bandwidth is not only lower than that of the L3 inside the CCX ("at least" 175 GB / s, a figure to check when the measurement software has been set Day), but especially lower ... to memory bandwidth!

il resto qui:
>> link Inglese (trad google) <<
>> link Francese (originale) <<

E immagina un cluster Jaguar quanto potrebbe consumare.

IMO non è tanto per i consumi quanto se non risolvono il problema del fabric tra i ccx

Ma non credo che rifaranno nuovamente tutti i test.

Mi aspetto che ne facciano un po', e basta.

infatti ho scritto "pezza"

Buona notte a tutti.

starai già dormendo buon riposo



IMO, SE, e riperto SE, Microsoft sistema lo scheduler di windows* (ed inoltre i rispettivi mettono un fix a bios, ecc), allora pochi punti percentuali si possono recuperare (1-4% in condizioni generali e più nei giochi e compressione)
a questo punto attenderò Skylake-x, sperando che sistemino quel collegamento "minimale"** tra i ccx in Zen+


*IMO ad Amd converrebbe pagare MS per far customizzare lo scheduler

**se il MC è a 1333mhz (per ram 2666) allora il bus fabric sarebbe di 128 bit=16B * 1.33ghz = 22GB/s. SE veramente fosse così sono basito...

Ps: overcloccando il fabric/controller ram si allevia un po' la situazione?

[rockroll]

Originariamente inviato da leoneazzurro

In realtà i problemi sembrano essere altri, le latenze misurate sulle cache L1/L2 non sono particolarmente elevate, anzi (e pure per la L3, almento stando ai dati riportati da techreport). Semmai è la latenza con la memoria di sistema a dare dei valori "strani" e dico strani perchè semrba che alcuni software non li misurino correttamente (qualcosa di strano con gli algoritmi di prefetching?).
Un problema sembrerebbe la non corretta allocazione dei core fisici/logici (in pratica cerchi di far andare due thread sullo stesso core fisico anzichè distribuirli tra due core, con conseguente perdita di potenza) e il tread switching tra core appartenenti a CCX diversi: Ryzen non è un octa core in senso stretto, ma è diviso in due partizioni con due cache L3 separate e connesse da un bus, se ci sono thread che vanno e vengono tra i due CCX il bus si satura e le prestazioni decrescono. In genere però il thread switching tra CCX non è detto che sia necessario, si potrebbe risolvere settando un'affinità tra thread che devono stare sullo stesso CCX.

Questa analisi sulle cause del problema mi sembra la più convincente tra quelle finora esposte.
Ma se è così, chiedo da non esperto in materia, non sarebbe abbastanza semplice interdire opzionalmente i core logici, almeno per i giochi e condizioni di utilizzo similari? Ed eventualmente inibendo il CCX switching ove conveniente? Il tutto potrebbe essere automatizzato in funzione della situazione dinamica di richieste thread e carico macchina relativo?
Forse non converrebbe ad AMD tirar fuori versioni Ryzen 7/b senza SMT, ovvero 8c 8t senza core logici? Basterebbe semplicemente castrare gli R7 in R7b e demandare questa versione più economica all'uso consumer e gaming in particolare, mentre la versione R7 attuale coprirebbe scenari di potenza MT più da server che da gaming?

[rockroll]

Originariamente inviato da HwWizzard

Tutto vero, ma siccome erano certi che comunque nessuno li poteva infastidire se c'era una scelta rischiosa da fare o intraprendere una strada più dispendiosa sicuramente ci sono andati con i piedi di piombo. Come qualsiasi azienda guidata da persone di buon senso avrebbe fatto.
Più di 4c8t nel desktop sono inutili e tali rimarranno per molto tempo ancora.
Questi Ryzen sono CPU da WS e non desktop.

Condivido l'opinione.

Questi Ryzen 7 sono finalmente ottimi processori di potenza MT a costo contenuto, ma non mi esaltano più di tanto proprio in considerazione della tua ultima osservazione.

[rockroll]

Originariamente inviato da emanuele83

arrivo per ultimo ma tanto vale:

ottimo il rapporto prezzo/prestazioni
pessima la mancanza di GPU integrata se si pensa che consumano come gli intel. lascaindo stare la parte gaming o rendering se si pensa ad ambienti di sviluppo o ricerca avrebbe fatto comodo avere una CPU performante come il 1800x ma con una gPu integrata. Purtroppo leggo che anche i ryzen 5 non l'avranno. peccato, i SOC CPU+GPU sono il futuro dell'integrazione e comodità

*EDIT* ovviamente il fatto che le CPU intel in comparazione non avessero GPU era a me sconosciuto. ritiro, altro plus per AMD visti i prezzi.

buonissimo il fatto che la concorrenza sia tornata, mi aspetto un calo di prezzi per intel. certo è che se AMD non sarà in grado di tenere il passo nel produrre nuove e più performanti soluzioni con intel la concorrenza andrà presto a farsi benedire.

La mancanza di gpu integrata infastidisce anche me. Ma qualche discreta da battaglia magari usata si dovrebbe acchiappare poche decine di euro, e poi non è detto che tra le varie MoBo per Ryzen nessuna offra gpu integrata.
Tieni comunque presente che una GPU discreta può esserti utile in supporto calcolo parallelo, che su macchine di questa potenza può trovare un logico utilizzo.

[cdimauro]

Originariamente inviato da digieffe

normalmente le mie sessioni medie sono composte da 50+ pagine su alcune sessioni (doc tecnica) arrivo anche a 200... e quando apro chromium me le tira tutte su contemporaneamente a volte attendo diversi minuti... ovviamente priorità al minimo escludo il core 0 dall'esecuzione e faccio altro in questo caso mi serve sia cpu che bw di rete

Uso Opera, che è basato su Chromium (e dunque dovrebbero essere parenti), e ho appena fatto una prova: appena lo apro arriva a un picco del 34%, ma scende subito al 20-25% per alcuni secondi, l'ultima decina di secondi si assesta intorno al 15%, per poi stabilizzarsi sull'1% (se non faccio niente. Altrimenti aumenta di qualche punto percentuale).

Questo sul mio 6700K, come dicevo, con una 60ina di pagine. La stragrande maggioranza dal sito di Repubblica (saranno ormai preistoria ormai: altro che notizie. ), poi Appunti Digitali, Gmail, YouTube, e qualche altra roba. Direi che ce n'è abbastanza di complesse.

La cosa interessante è che già dopo 2-3 secondi posso già navigare senza problemi. In ogni caso si tratta di un picco d'utilizzo del processore, che comunque nemmeno lo frutto tutto: al massimo per 1/3 della totale potenza di calcolo.

Questo è il mio caso d'uso (su Windows 10 x64 con 16GB di RAM ed SSD). Il tuo sarà ovviamente (molto) diverso.

Originariamente inviato da digieffe

qui la spiegazione (trad. google):

On Ryzen, the behavior is different. In its Hot Chips presentation, AMD noted that access to different parts of the L3 could have a different latency (depending on the core where it is attached) inside a CCX. One can see a behavior of this type on the first 4 MB, and a particularly strong increase beyond. We will not focus on this point without feedback from the authors of the benchmark.

OK, ma la cosa strana è che, come ripetono anche dopo, un CCX ha attaccato 8MB di cache L3, mentre i problemi sorgono già quando si superano i 4MB, che sono la metà. C'è qualcosa che non quadra proprio.

However, the situation beyond 8MB is without appeal: on a 12MB access (in a combined L3 of 16MB), we have a latency close to that which would be obtained if we made the access over- 8 MB in memory.

Infatti.

We asked AMD who confirmed this: in practice, in this case of school the L3 of the second CCX is not used, Ryzen behaving as if it had only 8 MB of L3.

E questa è una cosa che, se ricordi, avevo sollevato già un bel po' di tempo fa, nel thread Aspettando Zen, quando si parlava di cache L3 e di confronti con le soluzioni Intel.

Per gli altri, in sintesi, avevo detto che il vantaggio di queste ultime era che tutti i core / thread hardware potevano sfruttare l'intera cache L3, mentre per Zen potevano accedere alla loro porzione (metà nel caso di due CCX. Prova a immaginare cosa succederà con Naples / 32 core, che ne avrà ben 8!) mentre per accedere all'altra porzione ci sarebbe stata una penalizzazione (maggior latenza, per l'appunto).

Adesso scopriamo che in realtà... nemmeno ci accedono!

This is a particularity of the benchmark used: to be able to measure the latency correctly, it is essential that the threads are attached to a heart and do not move. However, you probably remember, the L3 cache is a "victim" cache, it contains the data that is removed from the L2 cache. And to fill the L2 cache, access must be made ... inside the CCX. Result, blocking our benchmark (latency is only measured on a thread) on the first core, the other CCX is not solicited, its cache not filling.

Praticamente è come se fossero due die attaccati come in modalità MCM del passato: lavorano in maniera separata / indipendente.

This is actually a disadvantage of the architecture even if it is overly theoretical: in practice, Windows 10 loves, we keep saying it, to stroll the software threads from one heart to another.

Già. Con queste informazioni è evidente che UNO (perché non è l'unico, come hai sottolineato alla fine) dei problemi più grosso è rappresentato dallo scheduler, per l'appunto.

Come per Intel, ma in maniera minore per i suoi processori (in questo caso i problemi sorgono spostando un thread hardware in un altro core, e dunque sono legati alla cache L2).

If AMD could not give us an idea of ​​the latency of an access on the second CCX, it gave us another much more important data: the bandwidth between these two CCX: only 22 GB / s!

Only, as you will have noticed, this bandwidth is not only lower than that of the L3 inside the CCX ("at least" 175 GB / s, a figure to check when the measurement software has been set Day), but especially lower ... to memory bandwidth!

Incredibile. Ma non avevano parlato di un velocissimo collegamento da 100GB/s? Invece è un quarto!

il resto qui:
>> link Inglese (trad google) <<
>> link Francese (originale) <<

IMO non è tanto per i consumi quanto se non risolvono il problema del fabric tra i ccx

Non credo che un aggiornamento del firmware/BIOS possa risolvere quello dei 22GB/s.

infatti ho scritto "pezza"

Vedremo se sarà grande o piccola.

starai già dormendo buon riposo

A quell'ora, quando hai scritto, la probabilità che ronfassi era prossima a 1.

IMO, SE, e riperto SE, Microsoft sistema lo scheduler di windows* (ed inoltre i rispettivi mettono un fix a bios, ecc), allora pochi punti percentuali si possono recuperare (1-4% in condizioni generali e più nei giochi e compressione)

Sono della stessa idea, ma non so se Microsoft rimetta mano proprio allo scheduler, che è il componente più delicato del kernel. Anche se dovesse farlo, non penso sarebbe pronto per la prossima settimana.

a questo punto attenderò Skylake-x, sperando che sistemino quel collegamento "minimale"** tra i ccx in Zen+

Beh, al solito vale la regola d'oro: meglio non comprare al day 1, e lasciare che altri facciano da cavia.

*IMO ad Amd converrebbe pagare MS per far customizzare lo scheduler

Indubbiamente. SE Microsoft accettasse di farlo, perché poi il problema sarebbe di tenersi dietro tutte le modifiche per l'intero lifecycle. Il costo della sola modifica non è, infatti, assolutamente sufficiente a coprire i costi di tutta la manutenzione.

**se il MC è a 1333mhz (per ram 2666) allora il bus fabric sarebbe di 128 bit=16B * 1.33ghz = 22GB/s. SE veramente fosse così sono basito...

Ps: overcloccando il fabric/controller ram si allevia un po' la situazione?

Sì, ma:
- non sappiamo quanto possa esserlo;
- con quei numeri, la situazione è già pessima di uso, e otterresti un aumento di qualche punto percentuale.

[cdimauro]

Originariamente inviato da rockroll

Questa analisi sulle cause del problema mi sembra la più convincente tra quelle finora esposte.
Ma se è così, chiedo da non esperto in materia, non sarebbe abbastanza semplice interdire opzionalmente i core logici, almeno per i giochi e condizioni di utilizzo similari? Ed eventualmente inibendo il CCX switching ove conveniente? Il tutto potrebbe essere automatizzato in funzione della situazione dinamica di richieste thread e carico macchina relativo?

Solo se si modifica lo scheduler del kernel, altrimenti è un'operazione complicata.

In ogni caso non si può certo chiedere all'utente di occuparsene. In particolare mi riferisco alla disattivazione dell'SMT: non è nemmeno da prendere in considerazione.

Ovviamente per gli smanettoni la cosa è diversa, ma anche loro credo che si scoccino e preferirebbero usare il processore come l'hanno comprato, senza essere costretti a disattivare e riattivare l'SMT alla bisogna.

Forse non converrebbe ad AMD tirar fuori versioni Ryzen 7/b senza SMT, ovvero 8c 8t senza core logici? Basterebbe semplicemente castrare gli R7 in R7b e demandare questa versione più economica all'uso consumer e gaming in particolare,

Sarebbe una buona soluzione temporanea, ma antieconomica. L'SMT costa molto poco in termini di implementazione, e dunque è estremamente raro che in un chip sfornato l'SMT, e solo l'SMT (quindi solo uno dei due thread hardware a disposizione) possa non funzionare.

Quindi AMD sarebbe costretta a disattivare l'SMT a un chip che, invece, è perfettamente funzionante, e venderlo a un prezzo inferiore (e che ovviamente sia appetibile: se togli solo qualche dollaro, un utente preferirebbe comprare quello con l'SMT).

mentre la versione R7 attuale coprirebbe scenari di potenza MT più da server che da gaming?

Veramente anche con l'SMT disattivato la situazione, in media, è cambiata molto poco per quanto riguarda gli FPS medi. E' migliorata un po' con quelli minimi, che sono senz'altro importanti.

Per quanto riguarda l'uso server, senz'altro per il rendering 3D s'è dimostrata un'eccellente architettura, e col prezzo che ha farà felice un sacco di professionisti che non vedevano l'ora di metter le mani su soluzioni con molti core, ma economiche.

Ma i server usualmente fanno girare ben altre tipologie di codice: virtualizzatori, linguaggi dinamici (PHP, Python, Ruby, Javascript), database (Oracle, MySQL, DB2, e i vari "No-SQL").

Già con Python (vedi i test che ha riportato Ren) la situazione non è affatto rosea e, dunque, se il trend è quello, dubito che Zen possa risultare competitivo, a meno di sostanziosi tagli di prezzo per renderlo appetibile.

Originariamente inviato da rockroll

Condivido l'opinione.

Questi Ryzen 7 sono finalmente ottimi processori di potenza MT a costo contenuto, ma non mi esaltano più di tanto proprio in considerazione della tua ultima osservazione.

Non per per tutta la tipologia di software MT, come dicevo.

Originariamente inviato da rockroll

La mancanza di gpu integrata infastidisce anche me. Ma qualche discreta da battaglia magari usata si dovrebbe acchiappare poche decine di euro, e poi non è detto che tra le varie MoBo per Ryzen nessuna offra gpu integrata.

Non vedo GPU integrate nel chipset da parecchio tempo (visto che ormai da anni sono integrate direttamente nella CPU), per cui è poco plausibile un'inversione di tendenza.

Si compra una discreta, e amen. O si aspetta le APU Zen.

Tieni comunque presente che una GPU discreta può esserti utile in supporto calcolo parallelo, che su macchine di questa potenza può trovare un logico utilizzo.

Infatti non è un caso che circa i 2/3 delle GPU sono... integrate. Le discrete sono 1/3 dell'intero mercato.

E sì: sono ormai utili anche in altri ambiti, oltre alla mera visualizzazione di grafica.