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

[sacd]

Originariamente inviato da LkMsWb

È abbastanza imboscato (per usare un termine tecnico), cerca bene, sul menù a sinistra c'è "Specifica comportamento pulsanti di alimentazione" o una cosa del genere (il testo cambia con le varie versioni di win), da lì avrai l'opzione in alto per poterle modificare - richiede l'essere admin - e poi puoi toccarle, anche se anche io dubito sia quello. Però tentare non costa nulla

E' attivo come nella foto ..

[LkMsWb]

Originariamente inviato da sacd

E' attivo come nella foto ..

La prova è disattivarlo infatti

Se l'Avvio rapido è attivo, i componenti di windows vengono fatti ripartire da zero solo in caso di riavvio, e non in caso di spegnimento/accensione. Si vede anche dal task manager, dove viene riportato l'up time

[sacd]

Originariamente inviato da LkMsWb

La prova è disattivarlo infatti

Se l'Avvio rapido è attivo, i componenti di windows vengono fatti ripartire da zero solo in caso di riavvio, e non in caso di spegnimento/accensione. Si vede anche dal task manager, dove viene riportato l'up time

Fatto, non è cambiato nulla..

[Totix92]

Originariamente inviato da sacd

Fatto, non è cambiato nulla..

Aggiorna i drivers del chipset, puoi riattivare l'avvio rapido.

[sacd]

Originariamente inviato da Totix92

Aggiorna i drivers del chipset, puoi riattivare l'avvio rapido.

Sono gli ultimi sul sito gigabyte.

http://it.gigabyte.com/products/page..._10#support-dl

Ho provato tutti e due le versioni

[sacd]

Ho trovato.....è la scheda con le porte usb aggiuntive...forse va in conflitto con qualcosa sul bus pci-ex, provo a spostarla...

[Totix92]

Originariamente inviato da sacd

Sono gli ultimi sul sito gigabyte.

http://it.gigabyte.com/products/page..._10#support-dl

Ho provato tutti e due le versioni

questi: https://www2.ati.com/drivers/amd_chi...18.10_1018.exe
quelli sul sito web di gigabyte sono più vecchi.

[SpongeJohn]

Originariamente inviato da digieffe

da ciò che scrivi devo presumere che tu non sia un programmatore.
Purtroppo l'IPC e la frequenza sono una necessità tecnica* ed economica**

*non pochi algoritmi non si possono parallelizzare, un altra parte trae poco o nessun giovamento dalla parallelizzazione, parallelizzare comporta difficoltà e sforzi tecnici che conducono ad un aumento della compessita degli algoritmi

**parallelizzare non è gratis: cosa pensereste se i software che non si possono parallelizzare in modo semplice costassero dal doppio a cinque volte tanto? li acquistereste o partirebbe la lagna sui costi ?

Non che non concordi con il fatto che ipc e prestazioni single thread (al momento) siano importanti. Ma quando toccheranno il muro del processo produttivo intorno ai 5nm: quali dovrebbero essere le alternative?

Ci fermiamo? Ci diamo per vinti e continueremo ad andare di brute force su single thread?
Se fosse cosí che l'industria ragiona non avremmo il branch prediction e ci ritroveremmo oggi con celeron a millemila hrz...

Vero che "al momento" non si puó parallerizzare tutto, ma é una visione alquanto chiusa della realtà pensare che in futuro non sarà cosí per tutti i task. Aggiungo, e non volermene male, che é la classica visione di chi fabbrica elettrodomestici ai quali non interessa niente innovare, ma solo guadagnare finché si puó: e che il futuro si fo...

Una visione oltremodo miope.
Le cose cambiano, gli status quo non reggono all'infinito, e chiamatemi pure ignorante con la testa fra le nuvole perché sono solo un osservatore (sebbene di lunga data) e non un programmatore: ma il limite tecnico sulla produzione in nm c'é ed é vicino. Cosa che pende come una spada di damocle non su chi cerca soluzioni alternative, ma su chi si ostina a sfruttare la stessa architettura/visione delle cose, in modo da soddisfare gli azionisti e gonfiarsi il portafogli.

Fosse per quelli, non solo non avremmo istruzioni secondarie, branch prediction, amd64 (itanium se lo ricorda qualcuno?): ma nemmeno avremmo arm e smarthpone sempre piú potenti (o volete venirmi a raccontare la cazzata della validitâ delle cpu x86 in ambito mobile...).

Le pure prestazioni in single thread sono un dogma, con una pesantissima spada di damocle sulla testa. Come ogni dogma: é destinato a cadere. Un giorno qualcuno inventerâ il modo di spezzetare le istruzioni sincronizzandole tra vari chip senza perdite su pipeline multiple...

quello o i celeron a 8 ghz (aka lavatrici). Fate voi, nel mentre nemmeno nell'industria dell'automobile si credeva possibile andare oltre i combustibili fossili e rendere il tutto sostenibile economicamente, ed invece...

[hotak]

Originariamente inviato da SpongeJohn

Non che non concordi con il fatto che ipc e prestazioni single thread (al momento) siano importanti. Ma quando toccheranno il muro del processo produttivo intorno ai 5nm: quali dovrebbero essere le alternative?

Ci fermiamo? Ci diamo per vinti e continueremo ad andare di brute force su single thread?
Se fosse cosí che l'industria ragiona non avremmo il branch prediction e ci ritroveremmo oggi con celeron a millemila hrz...

Vero che "al momento" non si puó parallerizzare tutto, ma é una visione alquanto chiusa della realtà pensare che in futuro non sarà cosí per tutti i task. Aggiungo, e non volermene male, che é la classica visione di chi fabbrica elettrodomestici ai quali non interessa niente innovare, ma solo guadagnare finché si puó: e che il futuro si fo...

Una visione oltremodo miope.
Le cose cambiano, gli status quo non reggono all'infinito, e chiamatemi pure ignorante con la testa fra le nuvole perché sono solo un osservatore (sebbene di lunga data) e non un programmatore: ma il limite tecnico sulla produzione in nm c'é ed é vicino. Cosa che pende come una spada di damocle non su chi cerca soluzioni alternative, ma su chi si ostina a sfruttare la stessa architettura/visione delle cose, in modo da soddisfare gli azionisti e gonfiarsi il portafogli.

Fosse per quelli, non solo non avremmo istruzioni secondarie, branch prediction, amd64 (itanium se lo ricorda qualcuno?): ma nemmeno avremmo arm e smarthpone sempre piú potenti (o volete venirmi a raccontare la cazzata della validitâ delle cpu x86 in ambito mobile...).

Le pure prestazioni in single thread sono un dogma, con una pesantissima spada di damocle sulla testa. Come ogni dogma: é destinato a cadere. Un giorno qualcuno inventerâ il modo di spezzetare le istruzioni sincronizzandole tra vari chip senza perdite su pipeline multiple...

quello o i celeron a 8 ghz (aka lavatrici). Fate voi, nel mentre nemmeno nell'industria dell'automobile si credeva possibile andare oltre i combustibili fossili e rendere il tutto sostenibile economicamente, ed invece...

in programmazione capita spesso di utilizzare operazioni "in serie" che hanno bisogno del risultato della precedente per poter essere svolte, in molti casi non è possibile separarle, non tutto è parallelizzabile, anche volendo.

[digieffe]

perdonami il risponderti punto per punto, è solo per essere più dettagliato

so già che potrebbe "suonare" come un'attacco ma non vuol assolutamente esserlo, voglio solo chiarire dei miti che circolano in questo thread e mi sta bene farlo con te, in quanto ho notato che a differenza di altri quando "afferri" qualcosa poi la riporti a coloro ai quali puntualmente sfugge... aggiungo che io non sempre posso scrivere...

una ri-riprecisazione non sto parlando di confronti tra marche ma solo di cpu... e puoi considerare questo post come il prosieguo dei miei ultimi 2-3 in questo thread a proposito di IPC

un'altra precisazione, è bene distinguerere nettamente quelle che sono le mie opinioni (O) da ciò che è la inconfutabile logica-matematica (LM)

Originariamente inviato da SpongeJohn

Non che non concordi con il fatto che ipc e prestazioni single thread (al momento) siano importanti.

Non "al momento" lo saranno per l'eternità!
LM:
Ci sono determinate classi di algoritmi che non sono parallelizzabili, su ciò non ci si può far assolutamente nulla e non sono affatto pochi.
Altri algoritmi scalano male appena s'inizia a salire con i thread (ad es perché ci sono troppe interazioni tra i th o troppe risorse contese o ...)
Altri algoritmi ancora scalano bene ma con l'aumentare in modo considerevole dei thread "s'ingolfano" anch'essi (vedi leggi di Amdahl e Gustafson)
-> Dunque ci sono dei forti limiti logico-matematici alla parallelizzazione ed è bene che se ne prenda atto (che piaccia o meno)

O:
oltre un certo numero di core il rischio diventa quello di avere più transistor dedicati alla logica di comunicazione (IF/Crossbar/RingBus/Mesh) che a quella di elaborazione (i core veri e propri)
Inoltre, quando la LM lo consente, scrivere nuovi programmi multithread costa sensibilmente di più dell'equivalente ST (ci saranno sicuramente degli studi accademico-industriali a tale proposito).

c'è anche un limite al crescere dell'IPC!
LM:
data una sequenza di istruzioni, non è sempre possibile eseguirne dei "blocchi" contemporaneamente (per ciclo di clock). Tra i vari motivi: salti condizionati (if), disponibilità dei dati, dipendenze, ...
-> Dunque ci sono dei forti limiti logico-matematici alla parallelizzazione delle istruzioni per ciclo di clock (IPC), anche in questo caso è bene che se ne prenda atto.
nota: ai tempi del lancio di haswell c'erano degli studi che indicavano in ~1.5 (non ricordo bene, forse ~1.8) volte l'incremento massimo di IPC relativo a quest'ultimo.

O: 1.5 oppure 1.8, ma fosse anche 2.x, non si va assolutamente lontano... un utente preparato in materia addirittura mi diceva che sarebbe stato difficile allontanarsi dai valori attuali, vedremo...

Ma quando toccheranno il muro del processo produttivo intorno ai 5nm: quali dovrebbero essere le alternative?

O: innanzitutto speriamo si possa arrivare anche al 3nm (ricordo che quando ero "giovane" il limite era posto a 20nm), poi finché non cambieranno i materiali (es. grafene) si andrà di "rifinitura" 3nm+++++++, potrebbe essere che migliorino i trattamenti ecc.
purtroppo se non si cambiano/migliorano i materiali si rischia uno stallo dal punto di vista dei PP, sto pensando a questo problema fin dal lancio del 22nm intel (2012) :-/
IMHO, una possibile strada potrebbe essere prendere esempio dalle cpu degli smartphone con core di tipo diversi (veloci/basso consumo, con più o meno unità specializzate). Se veramente ci sarà lo stallo potrebbero affinare anche questo aspetto.

Ci fermiamo? Ci diamo per vinti e continueremo ad andare di brute force su single thread?

come già spiegato sopra non si può far nulla, è come se si volesse che 2+2 non sia più uguale a 4 ma prima a 4.1 poi a 4.2, ma si cerchiamo di arrivare a 5

O: per quanto possibile si ridurranno le latenze delle istruzioni esistenti, s'introdurranno nuove istruzioni in grado di migliorare le prestazioni a parità di clock (es. bmi), si inseriranno nuove unità simd specializzate (es avx) e possibilmente si dovrebbe salire di clock.
I programmi, per quanto possibile, saranno sempre più ottimizzati e scritti con logica parallela, ma escludendo aree migliorabili ben conosciute non attendetevi chissà quali miglioramenti.

Se fosse cosí che l'industria ragiona non avremmo il branch prediction e ci ritroveremmo oggi con celeron a millemila hrz...

qui c'è un problema concettuale l'industria non può violare né la fisica né la matematica!
si stava percorrendo la strada dei "millemila hrz" (il pentium IV - basso ipc - era previsto fino a 10ghz) ma ad un certo punto (2-3ghz) hanno notato che il leakage saliva notevolmente e non riuscirono a superare i 3.8 (il PIV 4 ghz non usci mai, ripiegando sull'uarch. "core" che altro che non era una evoluzione del PIII dunque a alto IPC) ...
Se non risolveranno il problema del leakage non si potrà tanto salire in frequenza...


- nota: nei post precedenti non parlavo specificatamete di single thread ma soprattutto di ipc x ogni singolo thread su pochi thread (fino a 4-6) senza HT/SMT. -

Vero che "al momento" non si puó parallerizzare tutto, ma é una visione alquanto chiusa della realtà pensare che in futuro non sarà cosí per tutti i task. Aggiungo, e non volermene male, che é la classica visione di chi fabbrica elettrodomestici ai quali non interessa niente innovare, ma solo guadagnare finché si puó: e che il futuro si fo...

Una visione oltremodo miope.

ma questa visione non mi appartiene, ai bei tempi nei quali forse gli unici calcolatori con 2 cpu erano i mainframe (non ricordo se i Cray erano già usciti), fui tra i pochi a scegliere macchine parallele come argomento a scelta di "architettura dei calcolatori II" ...

Le cose cambiano, gli status quo non reggono all'infinito, e chiamatemi pure ignorante con la testa fra le nuvole perché sono solo un osservatore (sebbene di lunga data) e non un programmatore: ma il limite tecnico sulla produzione in nm c'é ed é vicino. Cosa che pende come una spada di damocle non su chi cerca soluzioni alternative, ma su chi si ostina a sfruttare la stessa architettura/visione delle cose, in modo da soddisfare gli azionisti e gonfiarsi il portafogli.

1 - è vicino il limite fisico dei materiali attuali (silicio: 5/3nm++++++ ?)
2 - è vicinissimo il limite di frequenza (a meno di fo4 bassissimi ed allungamento pipeline: 6ghz ?)
3 - è vicino il limite LM dell'IPC (1.5x ?)
4 - poco si può parallelizzare (anche ammesso che riscrivano tutti i programmi, si dovrebbe fare una stima di guadagno per ogni settore)

Fosse per quelli, non solo non avremmo istruzioni secondarie, branch prediction, amd64 (itanium se lo ricorda qualcuno?): ma nemmeno avremmo arm e smarthpone sempre piú potenti (o volete venirmi a raccontare la cazzata della validitâ delle cpu x86 in ambito mobile...).

quando c'è concorrenza in genere le situazioni evolvono per il meglio
c'è stato un tempo nel quale ho creduto nel set x86 ma è stato eoni fa...

Le pure prestazioni in single thread sono un dogma, con una pesantissima spada di damocle sulla testa. Come ogni dogma: é destinato a cadere. Un giorno qualcuno inventerâ il modo di spezzetare le istruzioni sincronizzandole tra vari chip senza perdite su pipeline multiple...

hai affermato un po' di cose strane... una possibile evoluzione e che facciano core più "cicciottelli" ed inteligenti (con SMT4 o più), ma non è detto che il budget dedicato "all'inteligenza" ripaghi a parità di transistor pochi core inteligenti rispetto ad avere più core "tonti"

quello o i celeron a 8 ghz (aka lavatrici). Fate voi, nel mentre nemmeno nell'industria dell'automobile si credeva possibile andare oltre i combustibili fossili e rendere il tutto sostenibile economicamente, ed invece...

questo paragone non calza, sarebbe come a dire non si può andare oltre il silicio, certo si potrà... prima o poi...

purtroppo per tutti, quei dogmi LM rimangono, non credo che neanche con cambio di paradigmi e computer quantici possa cambiare granché

io lavoro con passione, perchè io che sono del settore non dovrei essere dispiaciuto più di te?

O: arriveranno al limite fisico ma i nuovi materiali non saranno pronti, però in quel momento il core count sarà alto (~100core in hedt), seguirà un periodo di ottimizzazione in attesa che i nuovi processi consentiranno maggior integrazione e frequenza

vista l'ora non fare caso ad errori

ciao

[paolo.oliva2]

Quest è il mio 2700X con delle DDR4 3600 CL 16.

A farle funzionare oltre 3600, nemmeno pregando in aramaico.
A 3600 CL 16 funziano, ma a 3400 CL 14 vanno meglio.

Il top è 3466 CL 14, vanno, ma a naso non sono stabili.

https://imgur.com/a/p1qPTuo

[paolo.oliva2]

Originariamente inviato da hotak

in programmazione capita spesso di utilizzare operazioni "in serie" che hanno bisogno del risultato della precedente per poter essere svolte, in molti casi non è possibile separarle, non tutto è parallelizzabile, anche volendo.

Però si potrebbe operare in altro modo.... non sono un programmatore, però sono un ottimizzatore .

Ti faccio questo esempio:

Supponiamo una persona con una calcolatrice.
Ha il 1° dato, imposta la funzione e ottiene il risultato. Lo annota, riprende la calcolatrice, scrive il valore e imposta la funzione successiva, ed ottiene il risultato successivo, e così via fino alla fine di tutta la procedura.

Supponiamo invece che la persona abbia 8 calcolatrici e ciascuna abbia precaricato la funzione da eseguire. Una volta avuto il primo dato, gli basta scrivere il risultato e premere invio, senza digitare la funzione.

Cioè, quello che voglio dire, è che oggi i computer sono come una macchina anni 1920 in cui l'aereodinamica non era considerata. Qual'è la soluzione? Aumentare i CV del motore o semplicemente fare in modo che le potenzialità attuali vengano sfruttate meglio?

Il processore come concezione cerca di riprodurre il cervello umano. Se noi ci alziamo la mattina, basta una occhiata fuori dalla finestra per capire se dobbiamo mettere il maglione o basta la maglietta, se dobbiamo mettere le scarpe al posto delle ciabatte, e così via. Eppure il cervello umano ha un IPC nettamente inferiore al processore (facciamo un calclo a mente e facciamolo fare al procio) eppure il più potente processore al mondo arriva al 10% della potenza del cervello di un topo, il quale, a sua volta, è il 10% potente rispetto al cervello umano. Ovvio che ci vorrà un'infinità di tempo, ma mi sembra più che ovvio che l'IPC non potrà essere aumentato di 1000 volte o d 1 milione rispetto all'attuale... ma, come il cervello umano, dove i neuroni sono i processori, tanti neuroni con poco IPC, ma tanta e tanta potenza parallela.
Oggi i PC hanno lo stesso concetto di S.O., potenziato di un 8088 a 8bit funzionante a 4,77MHz. Oggi abbia processori che funzionano a GHz e nn MHz, a 64bit e non a 8, con 32 core e con cache L1, L2 e L3 (se non pure L4). Se ragionassimo in termini di IPC*frequenza, avremmo miliardi di potenza in più... eppure è totalmente non sfruttata... magari un 8088 farebbe un calcolo in mezzo secondo al posto di miillisecondi... ma il tutto si ferma lì.

[zerotre]

se gia' postato scusate:

annuncio il 6 novembre

3700x


3990x


"Improved IPC and reduced inter-core latency"

[Gyammy85]

Originariamente inviato da zerotre

se gia' postato scusate:

annuncio il 6 novembre

3700x


3990x


"Improved IPC and reduced inter-core latency"

Fonte?

No seriamente, fa parte degli annunci del 6?

[LicSqualo]

Questa la fonte: https://twitter.com/chiakokhua/statu...66516548857856

[zerotre]

Originariamente inviato da Gyammy85

Fonte?

No seriamente, fa parte degli annunci del 6?

Originariamente inviato da LicSqualo

Questa la fonte: https://twitter.com/chiakokhua/statu...66516548857856

il disegno e' stato presentato come speculazione, che pero' sembra essere stato confermato... Ne avremo la certezza il 6 novembre

a parita' di freq tra zen+ e zen2 si parla del 13% in piu'

[Gyammy85]

Originariamente inviato da zerotre

il disegno e' stato presentato come speculazione, che pero' sembra essere stato confermato... Ne avremo la certezza il 6 novembre

a parita' di freq tra zen+ e zen2 si parla del 13% in piu'

Mi sembra un gran guadagno, mettici core in più e frequenze in più...

[Mparlav]

(take it with a bowl of salt)

[Gyammy85]

Originariamente inviato da Mparlav

(take it with a bowl of salt)

Se non altro potremo comprare il 9999kxxx da 5,005 ghz all core da 500 watt a meno

[digieffe]

@spongejohn
mi rendo conto che avrei dovuto precisare meglio alcuni contesti, dare risposte più focalizzate, in alcune situazioni parlare di medie ecc, ma erano le 5 di mattina e credo che tutto sommato possa andar bene comunque

@paolo pur volendo interpretare si capisce ben poco di ciò che hai scritto