[Thread Ufficiale] CPU Zen 14/12/7nm: AMD Ryzen!

[antonioalex]

Originariamente inviato da metal master

sto test lo feci anche io.
devi controllare anche che per ogni linea appare solo "bzip2.c" (a me in modo casuale a volte apparivano anche altri caratteri tipo "@" oppure "bzip2.c" ripetuto per più volte sulla stessa linea assieme a "@" e altri caratteri)

you may see internal compiler error prints in the output before a failure

this indicates a hardware problem

del problema se ne parla in questo topic: https://community.amd.com/thread/215773

ma veramente nel readme c'è scritto "multiple 'bzip2.c' prints on a single line are fine"

[metal master]

Originariamente inviato da antonioalex

ma veramente nel readme c'è scritto "multiple 'bzip2.c' prints on a single line are fine"

esatto hai ragione, ho riletto meglio adesso.
l'errore dovrebbe verificarsi quando appaiono altri caratteri assieme a quel "bzip2.c" per ogni linea.

io al reparto tecnico di amd ho dato gli screen del test fatto sotto ubuntu.

[antonioalex]

Originariamente inviato da metal master

esatto hai ragione, ho riletto meglio adesso.
l'errore dovrebbe verificarsi quando appaiono altri caratteri assieme a quel "bzip2.c" per ogni linea.

io al reparto tecnico di amd ho dato gli screen del test fatto sotto ubuntu.

la @ molto probabilmente è solo un separatore, da ciò che ho capito i problemi si hanno quando crasha oppure esce tutt'altro scritto tipo bzipbagughehiuwh.c o direttamente un bell error

[bagnino89]

Originariamente inviato da antonioalex

la @ molto probabilmente è solo un separatore, da ciò che ho capito i problemi si hanno quando crasha oppure esce tutt'altro scritto tipo bzipbagughehiuwh.c o direttamente un bell error

Compilato anche io per circa 20 minuti, confermo che ogni tanto appaiono righe con un separatore tra i vari bzip2.c (la prima volta che ho compilato era una @, la seconda volta un carattere che sembrava non riconosciuto, un quadratino con dentro un ?), però non ho visto stringhe strane.

Niente crash, niente errori.

Posso dormire sonni tranquilli (è ora, per giunta)?

[Neverlost]

perfetto. ho reso il mio "vecchio" 1700X e preso un r7 1700 liscio con wraith cooler...
cmq vada sarà un successo.

[bagnino89]

Avevi errori? Qualcuno può confermarmi che il mio è a posto?

[Neverlost]

Originariamente inviato da bagnino89

Avevi errori? Qualcuno può confermarmi che il mio è a posto?

Si avevo errori cpu 1707

[Cloud76]

Proverei pure io con un Intel ma non ho capito una mazza di cosa dovrei fare... non ho mai usato linux.

[bagnino89]

Originariamente inviato da Cloud76

Proverei pure io con un Intel ma non ho capito una mazza di cosa dovrei fare... non ho mai usato linux.

Non serve Linux, segui questa guida:

https://github.com/corngood/kill-ryzen-win

Scarica la cartella, scarica Visual Studio, poi dalla console di comando avvii prima "build" e poi "run".

[Catan]

Originariamente inviato da deadbeef

premetto che la cosa è un pò paradossale (rispetto a cosa ci aveva abituati Intel), ma la limitazione del socket AM4 ad un massimo di 8 core mi fa storcere un pò il naso, non foss'altro che l'alternativa AMD è la ben più costosa piattaforma su socket tr4

io non ci vedo nulla di strano. Se ti serve un desktop, 8 core - 16 tread mi paiono adatti, forse anche sovra dimensionati.
Se ti serve la workstation o hedt ti prendi una workstation o una hedt.
Tra l'altro il costo di una mobo x399 di livello è poco più alto di una mobo am4+ (80€-100€ massimo).

Più che paradossale mi pare normale separare le fasce di mercato per due mercati che in teoria hanno fasce di utilizzatori diverse.

[kira@zero]

Originariamente inviato da Catan

io non ci vedo nulla di strano. Se ti serve un desktop, 8 core - 16 tread mi paiono adatti, forse anche sovra dimensionati.
Se ti serve la workstation o hedt ti prendi una workstation o una hedt.
Tra l'altro il costo di una mobo x399 di livello è poco più alto di una mobo am4+ (80€-100€ massimo).

Più che paradossale mi pare normale separare le fasce di mercato per due mercati che in teoria hanno fasce di utilizzatori diverse.

Infatti il 1900x é una cpu inutile, contando che la mobo Costa si é no 100 euro in piú senza contare che devi montare un quadchannel oltretutto punterei su un quad buono quindi per forza delle tridentz con chip Samsung e devi spendere per quelle 200 euro in piú

[TheDarkAngel]

Originariamente inviato da Neverlost

perfetto. ho reso il mio "vecchio" 1700X e preso un r7 1700 liscio con wraith cooler...
cmq vada sarà un successo.

Alla fine hai trovato la scusa per riavere i 450€

[deadbeef]

Originariamente inviato da kira@zero

Infatti il 1900x é una cpu inutile, contando che la mobo Costa si é no 100 euro in piú senza contare che devi montare un quadchannel oltretutto punterei su un quad buono quindi per forza delle tridentz con chip Samsung e devi spendere per quelle 200 euro in piú

beh non proprio, è utile se ti servono le linee pci express o in quelle situazioni in cui sei più I/O bound che CPU bound

[kira@zero]

Azz leggo ora del bug dei 1700 lisci ed io che ho preso per la donna un 1700 e crosshair dovrebbe arrivare oggi la cpu la mobo mi é giá arrivata
Che test va fatto specifico per vedere se é afflitto da bug?

[kira@zero]

Originariamente inviato da deadbeef

beh non proprio, è utile se ti servono le linee pci express o in quelle situazioni in cui sei più I/O bound che CPU bound

A beh solo in quel senso ma é molto molto difficile

[TheDarkAngel]

Originariamente inviato da bagnino89

Avevi errori? Qualcuno può confermarmi che il mio è a posto?

Si, il tuo è a posto.

Se è così, o con @, non ci sono errori

imageupload

[paolo.oliva2]

Originariamente inviato da SpongeJohn

In realtà di ipc ryzen ne ha a sufficienza, a livello frequenze é un'altro discorso. Il "non" problema di ryzen risiede nella scarsa capacità dello scheduler in combinazione con le singole app di sfruttare l'xfr in singolo/doppio thread.
Il vantaggio di intel é proprio li, cosa che viene a decadere con le cpu skylake x che abbandonano il ringbus per una configurazione piú orientata all'architettura simil infinity fabric di amd. cosa confermata dal comportamento di questi processori rispetto al 7700k in applicazioni con pochi thread.Dove il 7700k raggiunge prestazioni migliori degli i9.
A 4100mhz (frequenza xfr) ryzen in single core é a pochi decimi di percentuale indietro al 7700k che é, e probabilmente resterà la "miglior cpu single thread" anche dopo l'uscita in pochi giorni del refresh intel.

il fatto é che anche se alcuni bench misurano le prestazioni single core, non essendo (in alcuni casi volutamente come cpuz che ha cambiato metodologia perché a detta loro ryzen performava troppo bene) scritti appositamente per rimanere su single core e "nello stesso ccx". stessa cosa accade per i giochi
quando anche intel abbandona l'architettura ringbus, i risultati, al netto di frequenze maggiori che la favoriscono, non sono dissimili da quelli di amd.

edit,: dannata grammata

Comunque è la 1a volta che vedo un procio AMD con le features al 95% attive e nel contempo sfruttato al limite.

Per me... mia opinione, nel contesto frequenza e timing cache e quant'altro, pure Zen è al filo del massimo come Intel.

E siccome tanto sapete che non flammo vs AMD, è più tirato al limite un 1800X di un FX9590... l'unica cosa, incredibile, è che consuma meno della metà con più del doppio di prestazioni.

[antonioalex]

Originariamente inviato da kira@zero

Azz leggo ora del bug dei 1700 lisci ed io che ho preso per la donna un 1700 e crosshair dovrebbe arrivare oggi la cpu la mobo mi é giá arrivata
Che test va fatto specifico per vedere se é afflitto da bug?

il bug (veramente sono partite fallate per un QA pessimo, infatti hanno fatto passare del silicio che normalmente doveva essere scartato) potrebbe affliggere qualsiasi ryzen, non solo il 1700, e cmq il "bug" si presenta in situazioni veramente particolari, nell'uso normale è difficile inciampare in quest'errore

P.S.
sil il quadrato con il ? in mezzo sta per @

[Cloud76]

Originariamente inviato da bagnino89

Non serve Linux, segui questa guida:

https://github.com/corngood/kill-ryzen-win

Scarica la cartella, scarica Visual Studio, poi dalla console di comando avvii prima "build" e poi "run".

Sul sistema (Win7) ho questi:
Microsoft Visual C++ 2010x64 10.0.40.219
Microsoft Visual C++ 2010x86 10.0.40.219
Microsoft Visual C++ 2015x86 14.0.24215

Se vanno bene questi...

[paolo.oliva2]

Originariamente inviato da Bivvoz

Che poi dove sarebbe il problema?
Con Intel si è limitati a 4 core 8 thread da 10 anni e lo si è ancora al momento, poi tra poco si passerà straordinariamente a 6/12

Da 4/8 a 8/16 è stato un salto notevole, già 8/16 servono a pochi, ancora di più servono a pochissimi e quei pochissimi dovranno rivolgersi a threadripper.
Anzi trovo che sia meglio così, in questo modo nei prossimi anni ci si concentrerà sull'affinare la funzionalità dei core, il processo produttivo e le frequenze senza cadere nella tentazione dell'inutile corsa al numero più alto di core.
Anche perchè nel 90% degli applicativi mainstream già 8 core non vengono sfruttati, aggiungerne altri è inutile anzi se per farlo bisogna ridurre le frequenze è dannoso.

La soluzione (utilizzando più core) sarebbe quella di un Turbo all'Intel.
La gestione delle frequenze su Skylake-X è migliore... la nota dolente è solamente che Intel ha fissato un limite TDP troppo fuori efficienza.

Credo che l'architettura Zen, cioè quella del die con 2 CCX, abbia un limite di frequenza unicamente nel discorso TDP, perchè di per sè, un 1800X, un 1950X, un X32 Epyc, potrebbero andare tutti alla medesima frequenza, mentre l'architettura Intel ha comunque un "peso" per ogni 2 core aggiunti.

Ipotizzando una gestione turbo alla Intel sull'architettura Zen, secondo me si potrebbe avere un procio che avrebbe una frequenza massima proporzionata al numero di core sotto carico... quindi ok che un X32 avrà frequenze da X32 ma solo quando ci sono 32 core sotto carico, altrimenti avremmo che sempre l'X32 con 16 core sotto carico avrà le stesse frequenze di un X16 e idem di un X8 quando ci sarebbero solamente 8 core sotto carico.

Il problema è solamente limitare lo scheduler dell'S.O. per fare in modo che non "accenda" i CCX spenti... ma non credo sia impossibile parametrizzare lo scheduler a n salti tanto quanto sono i core in carico e non 1 di più... foss'anche da fare come con le console, dove su 8 core 1 viene utilizzato fisso per le routine basi.

Mi sono lasciato prendere "il dito" dicendo solo vaccate?