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

[bjt2]

Originariamente inviato da MiKeLezZ

Ogni costruttore di CPU decide, di progetto, il target di frequenza operativa della sua CPU. Spesso questo è direttamente proporzionale alla lunghezza della pipeline. Quella di Kaby Lake è lunga 14-19 a seconda delle istruzioni processate. Basta che AMD abbia scelto una lunghezza leggermente inferiore, di 12-16, per limitare la frequenza massima ottenibile e spiegare l'IPC.
Per questo tale comparativa ha poco senso. Le CPU Intel hanno di progetto un target di frequenze più elevato.
Se vuoi approfondire,
http://www.agner.org/optimize/microa...nF6YYyNlR5kkdQ

Secondo un paper ufficiale la pipeline INT di Ryzen (immagino max, senza la uop cache) è 19 stadi.

[MiKeLezZ]

Originariamente inviato da bjt2

Secondo un paper ufficiale la pipeline INT di Ryzen (immagino max, senza la uop cache) è 19 stadi.

No.

Bulldozer era 18-20 (infatti certi sample superavano i 5,0 GHz) e con Ryzen è stato dichiarato di aver fatto il lavoro opposto: riduzione della lunghezza della pipeline (ovvero aumento del IPC e di conseguenza diminuzione delle frequenze operative).

Tale dichiarazione viene direttamente da Michael T. Clark, ingegnere capo che ha preso il posto di Jim Keller, ed è impegnato sulle architetture AMD da 24 anni.

Da nessuna parte è riportata la specifica ufficiale.
Fra i 20 di Bulldozer e i 12 del Athlon64 credo sia lecito immaginarsi un valore nell'intorno dei 14-16 (comunque inferiore sia a Bulldozer che a Kaby Lake).

[cdimauro]

Originariamente inviato da maldepanza

Ecco, Ryzen buona come cpu e pure economica finché si vuole, ma è stata letteralmente azzoppata da una congiunta miopìa di AMD/produttori mobo.

Francamente delle schede madri, nell'ultima decina d'anni, non m'è mai importato: ho preso fra quelle più economiche (in genere AsRock; di recente anche Gigabyte, ma solo perché c'erano vantaggiosi bundle con la CPU), perché non m'interessa più da tempo l'overclock, dunque da questo punto vista non posso aggiungere nulla, a parte che i vari problemi usciti fuori denotano una certa immaturità della piattaforma, nel suo complesso.

Se poi verrà confermato quanto dici sullo scheduler di win e cioè: "Non è un bug dello scheduler di Windows. E' che Zen si comporta con i suoi CCX come se fosse un sistema NUMA, ma senza esporre quest'informazione. Dunque Windows lo gestisce, correttamente, come se fosse un sistema non NUMA." allora sarà ancora peggio.

Non è una cosa che mi sia inventato io. Sono stati fatti dei test per misurare la latenza, e il quadro che ne viene fuori è sostanzialmente quello. Ma per qualche dettaglio in più, leggi sotto.

E, come già detto da leoneazzurro, quello che s'è visto è un problema generale, che affligge anche le CPU Intel, sebbene in misura minore (mi pare che hardware.fr abbia effettuato dei test appositi).

Originariamente inviato da LMCH

Lo faranno solo se sarà DAVVERO conveniente rispetto ad altre alternative.

I test con le applicazioni che le usano finora dimostrano che sono convenienti.

Intel ha puntato su AVX perché in tal modo entro certi limiti può contrastare meglio le soluzioni cpu+gpu dei concorrenti nel settore HPC cercando di mantenersi il più x86-centrica possibile, ma come dici tu stesso questo ha un costo in termini di progettazione ed implementazione (che Intel per ora può permettersi).

Sai meglio di me che una GPU non può sostituire in toto una buona unità SIMD, nemmeno se la GPU si trova incollata ai core del processore.

Non è un caso se circolano voci riguardo un ripensamento radicale dell'architettura da parte di Intel,

Le voci che sono circolate finora affermano che Intel potrebbe eliminare dall'ISA roba vecchia come le MMX, e si paventa anche l'FPU x87 (anche se personalmente non ci credo: c'è TROPPO software che la usa), ma niente stravolgimenti.

in presenza di un concorrente che non "insegue" sullo stesso percorso non è che potranno opporgli FPU sempre più larghe e questo lo sapevano da ben prima dell' arrivo degli Zen.
Il vero pericolo per Intel non è tanto AMD quanto piuttosto l'architettura ARM a 64bit visto che ormai è pronta per erodere anche dall'alto quote di mercato ad Intel.

Lo dico da tempo, ma dovresti anche sapere che a uno degli ultimi eventi dedicati ai microprocessori, ARM ha presentato un nuova estensione vettoriale a 128, 512 (casualmente! ) e perfino 2048 bit per la sua ISA.

Considerato che ARM ha già in casa progetti di GPU, e che unità vettoriali così massicce sono particolarmente complesse da implementare (del clock skew ne parlavi tu tempo fa, se non ricordo male), sarebbe una svolta illogica rispetto a quello che avevi scritto prima. Si vede che, invece, avere unità vettoriali massicce continua ad avere prepotentemente il suo perché.

È in essenza un architettura NUMA, ma proprio per questo si presta a più semplici evoluzioni incrementali senza dover riprogettare tutto, inoltre quello che conta non è il "come se" ma piuttosto "come va" (e già ora con tale architettura dalla L3 in giù i Ryzen sono competitivi).

Non è soltanto un'architettura NUMA. Impostando le informazioni del firmware in questo modo si risolverebbero certamente i problemi di accesso al CCX vicino, senza andare a toccare lo scheduler dei s.o., ma non si risolverebbero tutti i problemi.

La microarchitettura di Ryzen è abbastanza strana / particolare anche andando a guardare dentro il singolo CCX. L'ho fatto di recente, anche con le immagini dei die, e sembra che la situazione sia più complicata.

Un core ha, come detto prima, 2MB di cache L3 affiancati, e a cui può accedere con latenza minima. Può anche accedere con la stessa latenza a 1MB di cache L3 dei due core più vicini, e dunque per un totale di 4MB di cache L3. Ma i due vicini hanno un altro MB di cache L3, solo che per accedere a questo la latenza aumenta. Infine, la latenza aumenta anche nel caso in cui si volesse accedere ai 2MB di cache L3 dell'ultimo core del CCX, che si trova all'opposto.

Dunque un core riesce ad accedere soltanto parzialmente alle cache L3 dei vari core, e in misura diversa a seconda delle reciproche posizioni.

Immagina il lavoro che dovrebbe fare uno scheduler se dovesse anche cercare di tenere conto di tutto ciò, all'interno del singolo CCX.

La cosa più sensata da fare in questi casi sarebbe quello di non far muovere del tutto i thread hardware da dove stanno: bloccarli lì fino alla loro fine. Ma immagino che anche questo produrrebbe dei problemi, perché un'applicazione (in particolare i giochi sono un buon rappresentante di questa tipologia) che crei thread/processi non omogenei a cui smistare i vari task, dovrebbe farsi carico personalmente della loro collocazione in una piattaforma come questa, se l'obiettivo è quello di sfruttarla al meglio.

Il che crea problemi lato sviluppo, perché non credo che sia piacevole realizzarlo, peraltro con la prospettiva che in futuro le cose possano cambiare (ad esempio, e del tutto teoricamente sia chiaro, AMD potrebbe realizzare un CCX diverso con Zen2, con una cache unificata L3 per CCX, che serva equamente i 4 core), e dunque vanificando il lavoro fatto dagli sviluppatori per supportare questa strana configurazione degli attuali CCX di Ryzen.

Da qualunque parti la si guardi (s.o., applicazioni) è una bella gatta da pelare.

Originariamente inviato da imayoda

prime95 uccide le cpu intel (4c8t che ho in firma e non linko toms),

Ci sono applicazioni ancora più pesanti / stressanti. Dai un'occhiata al thread di The Stilt su AnandTech.

non può esistere un applicazione per computer x86 che mandi in combustione un componente se non l'intera cpu (col loro dissipatore sopra), perché questo significa che (rullo di tamburi) la cpu è progettata male, o le statistiche termiche le inventano in condizioni a loro favorevoli, oppure è a fine ciclo (qualcuno ha detto prescott?).
Magari dovevo fare trasformazioni di fourier, e non lo scrivono sulla scatola che serve una patch o un software vecchio e non "ottimizzato" per la mia costosa cpu.
I prossimi cryptolocker cosa faranno, mi faranno throttlare a morte la cpu se non pago ?

Non funziona così. E' vero che il consumo aumenti se utilizzi pesantemente le AVX sui sistemi Intel, ma al contempo le frequenze scendono. Il tutto per cercare di far rimanere il chip entro i limiti del sistema di dissipazione.

Originariamente inviato da imayoda

i matti farneticano
no, avevo scritto fx, niente apu, quelle cpu sono troppo tirate termicamente anche con la gpu "spenta" (cosa che non sono mai riuscito a osservare forse colpa dei bios o del design)

Le CPU "desktop" di Intel sono di fatto delle APU, ma non diminuiscono drasticamente la frequenza di clock della componente x86, nemmeno quando la GPU è pienamente operativa.

Fatta eccezione per l'uso intensivo della AVX (e nemmeno di molto), come già detto, ma in questo caso anche a fronte di vantaggi prestazioni che possono essere notevoli.

Originariamente inviato da george_p

Passata l'era in cui si dava contro amd perché non è per niente competitiva e quando lo diventa tutti i riflettori puntano stranamente solo sui minimi frames in giochi dove per anni sono state ottimizzate le cpu intel.

Hai informazioni tecniche su questo? Perché pur avendo letto il manuale delle ottimizzazioni sia di Intel sia di AMD, non ho colto nulla del genere.

Originariamente inviato da MiKeLezZ

No.

Bulldozer era 18-20 (infatti certi sample superavano i 5,0 GHz) e con Ryzen è stato dichiarato di aver fatto il lavoro opposto: riduzione della lunghezza della pipeline (ovvero aumento del IPC e di conseguenza diminuzione delle frequenze operative).

Tale dichiarazione viene direttamente da Michael T. Clark, ingegnere capo che ha preso il posto di Jim Keller, ed è impegnato sulle architetture AMD da 24 anni.

Da nessuna parte è riportata la specifica ufficiale.
Fra i 20 di Bulldozer e i 12 del Athlon64 credo sia lecito immaginarsi un valore nell'intorno dei 14-16 (comunque inferiore sia a Bulldozer che a Kaby Lake).

Potresti recuperare il link alla dichiarazione? Sarebbe molto interessante. Grazie.

[bjt2]

Originariamente inviato da MiKeLezZ

No.

Bulldozer era 18-20 (infatti certi sample superavano i 5,0 GHz) e con Ryzen è stato dichiarato di aver fatto il lavoro opposto: riduzione della lunghezza della pipeline (ovvero aumento del IPC e di conseguenza diminuzione delle frequenze operative).

Tale dichiarazione viene direttamente da Michael T. Clark, ingegnere capo che ha preso il posto di Jim Keller, ed è impegnato sulle architetture AMD da 24 anni.

Da nessuna parte è riportata la specifica ufficiale.
Fra i 20 di Bulldozer e i 12 del Athlon64 credo sia lecito immaginarsi un valore nell'intorno dei 14-16 (comunque inferiore sia a Bulldozer che a Kaby Lake).

http://www.linleygroup.com/newslette...ear=2016&tag=3

"The basic integer pipeline is 19 stages"

Io non parlo mai a vanvera. Se dico che c'è un paper, allora c'è. Se non hai seguito il thread nella sezione processori allora forse ti sei perso il link.

[bjt2]

Originariamente inviato da cdimauro

Un core ha, come detto prima, 2MB di cache L3 affiancati, e a cui può accedere con latenza minima. Può anche accedere con la stessa latenza a 1MB di cache L3 dei due core più vicini, e dunque per un totale di 4MB di cache L3. Ma i due vicini hanno un altro MB di cache L3, solo che per accedere a questo la latenza aumenta. Infine, la latenza aumenta anche nel caso in cui si volesse accedere ai 2MB di cache L3 dell'ultimo core del CCX, che si trova all'opposto.

Dunque un core riesce ad accedere soltanto parzialmente alle cache L3 dei vari core, e in misura diversa a seconda delle reciproche posizioni.

Immagina il lavoro che dovrebbe fare uno scheduler se dovesse anche cercare di tenere conto di tutto ciò, all'interno del singolo CCX.

La cosa più sensata da fare in questi casi sarebbe quello di non far muovere del tutto i thread hardware da dove stanno: bloccarli lì fino alla loro fine. Ma immagino che anche questo produrrebbe dei problemi, perché un'applicazione (in particolare i giochi sono un buon rappresentante di questa tipologia) che crei thread/processi non omogenei a cui smistare i vari task, dovrebbe farsi carico personalmente della loro collocazione in una piattaforma come questa, se l'obiettivo è quello di sfruttarla al meglio.

Il che crea problemi lato sviluppo, perché non credo che sia piacevole realizzarlo, peraltro con la prospettiva che in futuro le cose possano cambiare (ad esempio, e del tutto teoricamente sia chiaro, AMD potrebbe realizzare un CCX diverso con Zen2, con una cache unificata L3 per CCX, che serva equamente i 4 core), e dunque vanificando il lavoro fatto dagli sviluppatori per supportare questa strana configurazione degli attuali CCX di Ryzen.

Ryzen accede alla L3 facendo l'interleaving con i bit bassi dell'indirizzo, così da avere latenza media uguale per tutti i thread. Non è possibile allocare un thread in modo da usare un solo spicchio di L3...

[fatantony]

Originariamente inviato da bjt2

http://www.linleygroup.com/newslette...ear=2016&tag=3

"The basic integer pipeline is 19 stages"

Io non parlo mai a vanvera. Se dico che c'è un paper, allora c'è. Se non hai seguito il thread nella sezione processori allora forse ti sei perso il link.

No.
"Non sai niente di CPU, hai chiesto quale processore era meglio usare su un socket 7, e vieni qui a fare il gradasso?" (cit.)

Piuttosto, ho notato che il commento di Mister D sul FO4 è stato bellamente ignorato

P.s. Concordo con chi dice don't feed the troll

[ilbarabba]

Quante pippe ragazzi, ma non dovremmo essere TUTTI contenti che AMD, che partiva da una distanza siderale, è quasi riuscita a raggiungere Intel?
Ne guadagniamo tutti a prescindere.
Anche se il 1800x non raggiunge il 700k (e grazie al cazzo che non lo possa raggiungere, era ovvio) però almeno si è avvicinato molto.
Non capisco questa guerra all'ultimo frame dove addirittura si taroccano i grafici per far vincere l'uno o l'altro.
Mah

[fatantony]

Originariamente inviato da ilbarabba

... ma non dovremmo essere TUTTI contenti che AMD, che partiva da una distanza siderale, è quasi riuscita a raggiungere Intel?
Ne guadagniamo tutti a prescindere...

Questo è il pensiero delle persone cum grano salis, però leggendo vari commenti non solo su questo thread, pare che ci sia qualche voce fuori dal coro

[MiKeLezZ]

Originariamente inviato da bjt2

http://www.linleygroup.com/newslette...ear=2016&tag=3

"The basic integer pipeline is 19 stages"

Io non parlo mai a vanvera. Se dico che c'è un paper, allora c'è. Se non hai seguito il thread nella sezione processori allora forse ti sei perso il link.

Te hai detto "SECONDO UN PAPER UFFICIALE".
Quello non è un paper ufficiale, quella è una rivista. Speculazioni.

The company also made the chip’s integer and floating point processing units more dynamic and accessible to single- and multithreaded workloads. It will take fewer cycles to load operations on the processing units. The units in Bulldozer and its derivatives weren’t as dynamic, widely considered a problem.
The designers also sharpened the chip’s execution units. Zen has a distributed scheduler, and it provides visibility to more threads in a window. Bulldozer had a unified scheduler with more complexity.

It all begins with branch prediction, which feeds instructions into the 64K 4-way I-Cache. Data flows into decode, which then issues four instructions per cycle to the micro-op queue. Micro-ops are also stored in the op cache, which, in turn, serves frequently encountered ops to the queue. This technique boosts performance and saves power by reducing pipeline stages. As expected, Clark declined to comment on the specific length of the pipeline but noted that the op cache scheme allows the company to shorten it.

Clark said that the Zen core has much better branch prediction, and that one of the biggest new features was a large op cache. “In the X86 architecture, there is a variable instruction length and this makes trying to find multiple instructions to get going in the machine a very difficult problem because it is a serial process. To attack that, you build a pretty deep pipeline and you spend a lot of logic, it burns a lot of power. Having seen instructions once come through the pipeline, we now have the micro-ops and we can store them in an op cache and store them so that the next time we hit those instructions, we can just pull them out of the op cache. We can cut stages out of our pipeline when we are hitting the op cache and we can use those high power decoders and not burn all that power as well removing the state we can also deliver more ops into the machine per cycle, too. This is a really great feature that delivers us way more performance and saves us power at the same time.”

Originariamente inviato da fatantony

Questo è il pensiero delle persone cum grano salis, però leggendo vari commenti non solo su questo thread, pare che ci sia qualche voce fuori dal coro

Io sono contento. Però vengono scritte molte inesattezze ed è corretto correggerle.
Fra chi compara il 1800X al 7700K downcloccato, a chi spaccia per ufficiali delle indiscrezioni, a chi sogna infattibili CPU Ryzen da 5,0 GHz, a chi non sa riconoscere neppure un esponenziale, a chi non sa montare un dissipatore aftermarket, il lavoro non è dei più facili.

[george_p]

Originariamente inviato da cdimauro

Hai informazioni tecniche su questo? Perché pur avendo letto il manuale delle ottimizzazioni sia di Intel sia di AMD, non ho colto nulla del genere.

Ah si, perché tu cerchi nel manuale amd e intel se ci sta scritta la voce su eventuali ottimizzazioni fatte da parte delle software house per gestire al meglio una architettura soprattutto se nuova?

Quando intel ha introdotto il suo SMT nei coreduo non c'è mai stato bisogno (da parte delle software house) di ottimizzare le varie applicazioni per questa feature?
O riconoscevano automaticamente l'SMT?

I drivers, bios, di tutte le applicazioni esistenti, siano esse giochi, OS, e quant'altro, a cosa servono?

Facevi prima a risparmiare i caratteri con la tua solita uscita "Fonte?".

[LMCH]

Originariamente inviato da cdimauro

I test con le applicazioni che le usano finora dimostrano che sono convenienti.

Sai meglio di me che una GPU non può sostituire in toto una buona unità SIMD, nemmeno se la GPU si trova incollata ai core del processore.

Ma la "buona unità SIMD" non ha senso quando diventa troppo larga per cercare di competere con le gpu dove queste ultime sono già la soluzione migliore.

Originariamente inviato da cdimauro

Lo dico da tempo, ma dovresti anche sapere che a uno degli ultimi eventi dedicati ai microprocessori, ARM ha presentato un nuova estensione vettoriale a 128, 512 (casualmente! ) e perfino 2048 bit per la sua ISA.

Considerato che ARM ha già in casa progetti di GPU, e che unità vettoriali così massicce sono particolarmente complesse da implementare (del clock skew ne parlavi tu tempo fa, se non ricordo male), sarebbe una svolta illogica rispetto a quello che avevi scritto prima. Si vede che, invece, avere unità vettoriali massicce continua ad avere prepotentemente il suo perché.

Avere unità ottimizzate per l'elaborazione vettoriale ha SEMPRE avuto il suo perché in settori applicativi specifici.
Basta pensare ad esempio alle cpu dei vecchi supercomputer Cray.

A differenza di Intel ed AMD, c'è da considerare che ARM propone un vero e proprio arsenale di IP adattabili alle esigenze di vari settori e di vari target di consumo e potenza di calcolo, ma il set d'istruzioni "base" ARMv8 ha registri SIMD a 128bit.

Non a caso la SVE non è un estensione SIMD tipo SSE, AVX o NEON ma un vero e proprio
COPROCESSORE VETTORIALE con lo stesso set d'istruzioni per implementazioni di SVE da 128bit a 2048bit ( è "vector-lenght agnostic" ), tutto un altro paio di maniche insomma.
Gli dai le dimensioni dei vettori/matrici da processare e lo SVE se le macina con una granularita interna dipendente dall'implementazione se ho capito bene.

Originariamente inviato da cdimauro

Non è soltanto un'architettura NUMA. Impostando le informazioni del firmware in questo modo si risolverebbero certamente i problemi di accesso al CCX vicino, senza andare a toccare lo scheduler dei s.o., ma non si risolverebbero tutti i problemi.

La microarchitettura di Ryzen è abbastanza strana / particolare anche andando a guardare dentro il singolo CCX. L'ho fatto di recente, anche con le immagini dei die, e sembra che la situazione sia più complicata.

Un core ha, come detto prima, 2MB di cache L3 affiancati, e a cui può accedere con latenza minima. Può anche accedere con la stessa latenza a 1MB di cache L3 dei due core più vicini, e dunque per un totale di 4MB di cache L3. Ma i due vicini hanno un altro MB di cache L3, solo che per accedere a questo la latenza aumenta. Infine, la latenza aumenta anche nel caso in cui si volesse accedere ai 2MB di cache L3 dell'ultimo core del CCX, che si trova all'opposto.

Dunque un core riesce ad accedere soltanto parzialmente alle cache L3 dei vari core, e in misura diversa a seconda delle reciproche posizioni.

Immagina il lavoro che dovrebbe fare uno scheduler se dovesse anche cercare di tenere conto di tutto ciò, all'interno del singolo CCX.

La cosa più sensata da fare in questi casi sarebbe quello di non far muovere del tutto i thread hardware da dove stanno: bloccarli lì fino alla loro fine. Ma immagino che anche questo produrrebbe dei problemi, perché un'applicazione (in particolare i giochi sono un buon rappresentante di questa tipologia) che crei thread/processi non omogenei a cui smistare i vari task, dovrebbe farsi carico personalmente della loro collocazione in una piattaforma come questa, se l'obiettivo è quello di sfruttarla al meglio.

Il che crea problemi lato sviluppo, perché non credo che sia piacevole realizzarlo, peraltro con la prospettiva che in futuro le cose possano cambiare (ad esempio, e del tutto teoricamente sia chiaro, AMD potrebbe realizzare un CCX diverso con Zen2, con una cache unificata L3 per CCX, che serva equamente i 4 core), e dunque vanificando il lavoro fatto dagli sviluppatori per supportare questa strana configurazione degli attuali CCX di Ryzen.

Da qualunque parti la si guardi (s.o., applicazioni) è una bella gatta da pelare.

Non è che sia quel gran problema che sembra, le cose più rilevanti da fare sono:
1) dare (a parità degli altri criteri di selezione) la preferenza di selezione thread sullo stesso core del precedente time slice ed in secondo ordine a quelli adiacenti;
2) non deattivare completamente i due core adiacenti ad un core attivo (perché in tal caso gli accessi alle L3 "di secondo livello" si allungano, se ho capito bene).

Non si tratta di sfruttare al 100% le peculiarità dell'architettura delle L3 di Ryzen, ma semplicemente di sfruttarle meglio ( e già ora ha buone prestazioni per il prezzo che ha).

Edit: corretto un quote terminato male

[bjt2]

Originariamente inviato da MiKeLezZ

Te hai detto "SECONDO UN PAPER UFFICIALE".
Quello non è un paper ufficiale, quella è una rivista. Speculazioni.

The company also made the chip’s integer and floating point processing units more dynamic and accessible to single- and multithreaded workloads. It will take fewer cycles to load operations on the processing units. The units in Bulldozer and its derivatives weren’t as dynamic, widely considered a problem.
The designers also sharpened the chip’s execution units. Zen has a distributed scheduler, and it provides visibility to more threads in a window. Bulldozer had a unified scheduler with more complexity.

It all begins with branch prediction, which feeds instructions into the 64K 4-way I-Cache. Data flows into decode, which then issues four instructions per cycle to the micro-op queue. Micro-ops are also stored in the op cache, which, in turn, serves frequently encountered ops to the queue. This technique boosts performance and saves power by reducing pipeline stages. As expected, Clark declined to comment on the specific length of the pipeline but noted that the op cache scheme allows the company to shorten it.

Clark said that the Zen core has much better branch prediction, and that one of the biggest new features was a large op cache. “In the X86 architecture, there is a variable instruction length and this makes trying to find multiple instructions to get going in the machine a very difficult problem because it is a serial process. To attack that, you build a pretty deep pipeline and you spend a lot of logic, it burns a lot of power. Having seen instructions once come through the pipeline, we now have the micro-ops and we can store them in an op cache and store them so that the next time we hit those instructions, we can just pull them out of the op cache. We can cut stages out of our pipeline when we are hitting the op cache and we can use those high power decoders and not burn all that power as well removing the state we can also deliver more ops into the machine per cycle, too. This is a really great feature that delivers us way more performance and saves us power at the same time.”

Io sono contento. Però vengono scritte molte inesattezze ed è corretto correggerle.
Fra chi compara il 1800X al 7700K downcloccato, a chi spaccia per ufficiali delle indiscrezioni, a chi sogna infattibili CPU Ryzen da 5,0 GHz, a chi non sa riconoscere neppure un esponenziale, a chi non sa montare un dissipatore aftermarket, il lavoro non è dei più facili.

La parte in grassetto secondo te cosa significa? Scheduler più semplice, FO4 addirittura più basso e possibilmente più stadi di pipeline necessari. Ryzen ha 6 scheduler a una coda contro uno a 4 code di BD. E' più semplice. Non ha ottenuto clock più elevati solo perchè ha optato per librerie ultradense (la L3 di Ryzen occupa meno spazio a parità di capacità del processo più denso di INTEL) che sono più lente e causano una maggiore densità di potenza da dissipare, limitando ulteriormente il clock. Il fatto che il FO4 è più basso si deduce anche dalla potenza dissipata (ricordiamo, su un processo INFERIORE) da Ryzen rispetto al 6900K, a parità di clock e anche a parità di rpestazioni.

[lucusta]

Originariamente inviato da cdimauro

Le CPU "desktop" di Intel sono di fatto delle APU, ma non diminuiscono drasticamente la frequenza di clock della componente x86, nemmeno quando la GPU è pienamente operativa.

non sono delle APU, ma delle CPU con accanto una GPU via PCIe.
una APU è HSA, ma condivide il bus con la CPU, ed ha accesso diretto alla memoria e caches.
Intel usa un bus interno PCIe, come le soluzioni HSA AMD su scheda video didicata.
per quanto riguarda la gestione delle frequenze di CPU e iGPU di una APU è un altro paio di maniche rispetto alle AWX Intel.
anche in overclock del 50% la iGPU integrata nella APU è talmente blanda da non risentire di colli prestazionali nemmeno quando i 4 core la CPU sono a 2.4Ghz... non saturano affatto la CPU e le prestazioni calano solo di una piccola percentuale dovuta agli spike...

ho una APU, ed arriva a 4.9Ghz con iGPU a 1199mhz, sforando i 140W, ma usandola con la iGPU è totalmente inutile averla fissa a quella frequenza, come è inutile avere un i7-7700K a 5Ghz quando usi la sua iGPU....

diversa la questione della AWX: sono computo diretto, e piu' vanno su in frequenza piu' producono prestazioni... chiamalo overclock o chiamala gestione dei consumi, ma la frequenza della CPU non centra nulla.

le AWX consumano, e tanto, ed intel è costretta a limitarne la frequenza.
stesso dicasi della temporizzazione caches; se overclocki un i7 verrà aggiunta latenza, perche' la caches non regge e non otterrai prestazioni lineari rispetto alla frequenza, soprattutto negli ambiti in cui la caches la fà da padrona.

sono giusto delle precisazioni.

[MiKeLezZ]

Originariamente inviato da bjt2

La parte in grassetto secondo te cosa significa? Scheduler più semplice, FO4 addirittura più basso e possibilmente più stadi di pipeline necessari. Ryzen ha 6 scheduler a una coda contro uno a 4 code di BD. E' più semplice. Non ha ottenuto clock più elevati solo perchè ha optato per librerie ultradense (la L3 di Ryzen occupa meno spazio a parità di capacità del processo più denso di INTEL) che sono più lente e causano una maggiore densità di potenza da dissipare, limitando ulteriormente il clock. Il fatto che il FO4 è più basso si deduce anche dalla potenza dissipata (ricordiamo, su un processo INFERIORE) da Ryzen rispetto al 6900K, a parità di clock e anche a parità di rpestazioni.

Un conto è allargare, un conto è allungare. La frase che tu stesso hai scritto, che vi siano 6 scheduler a 1 coda rispetto a 1 a 4 code significa una riduzione degli stadi di pipeline.

In ogni caso non c'è alcuna analisi da fare: il chief engineer lead architect di Ryzen ha affermato la pipeline sia più corta rispetto a Bulldozer, e di conseguenza Kaby Lake. Tanto basta.

p.s. La L3 di Ryzen occupa il 16% di spazio mentre la L3 di Intel occupa il 4,5% di spazio.
Anche considerando che la L3 su Ryzen è il doppio rispetto a quella su Kaby Lake, il risultato è che la L3 di Intel è molto più densa e occupa molto meno spazio. Quindi il tuo discorso che su Ryzen i clock siano limitati dal processo produttivo della L3 non fila per nulla (visto che buona parte del suo die è occupata da essa, ed è quella che meno limita la velocità del clock della CPU - inoltre è meno densa e a regola dovrebbe salire meglio).

Puoi avere anche 1 miliardo di messaggi ed averne discusso per mesi su qualche thread "aspettando", ma un conto sono le chiacchiere da bar con gli amici che "ve la cantate e ve la sonate", un altro la realtà dei fatti.

[bjt2]

Originariamente inviato da MiKeLezZ

Un conto è allargare, un conto è allungare. La frase che tu stesso hai scritto, che vi siano 6 scheduler a 1 coda rispetto a 1 a 4 code significa una riduzione degli stadi di pipeline.

Lo stadio di scheduler è fatto da un solo stadio di pipeline. Se lo stadio è più semplice, ha un FO4 più basso, quindi gli altri stadi, per compensare, devono essere semplificati, spezzandoli. E poi è risaputo che una CPU con un FO4 più basso ha più stadi, a parità di architettura.

Originariamente inviato da MiKeLezZ

In ogni caso non c'è alcuna analisi da fare: il chief engineer lead architect di Ryzen ha affermato la pipeline sia più corta rispetto a Bulldozer, e di conseguenza Kaby Lake. Tanto basta.

Link, please. Se no io posso dire che è risaputo che Zen ha millemila stadi e stop.

Originariamente inviato da MiKeLezZ

p.s. La L3 di Ryzen occupa il 36% di spazio su un die di 44mm^2 mentre la L3 di Intel occupa il 4,5% di spazio su un die di 49mm^2.
Anche considerando che la L3 su Ryzen è il doppio rispetto a quella su Kaby Lake, il risultato è che la L3 di Intel è enormemente più densa e occupa enormemente meno spazio. Quindi il tuo discorso che su Ryzen i clock siano limitati dal processo produttivo della L3 non fila per nulla (visto che gran parte del suo die è occupata da essa, ed è quella che meno limita la velocità del clock della CPU - inoltre è meno densa e a regola dovrebbe salire meglio).

Addirittura un ordine di grandezza di differenza? Ma dove li hai presi questi numeri?

Sei sicuro?

Originariamente inviato da MiKeLezZ

Puoi avere anche 1 miliardo di messaggi ed averne discusso per mesi su qualche thread "aspettando", ma un conto sono le chiacchiere da bar con gli amici che "ve la cantate e ve la sonate", un altro la realtà dei fatti.

Non è il numero di messaggi, ma è il sapere di cosa si sta parlando...

[MiKeLezZ]

Originariamente inviato da bjt2

Link, please. Se no io posso dire che è risaputo che Zen ha millemila stadi e stop.

I quote sono sopra. Basta che copi-incolli e cerchi con google. Se Bulldozer ha 18-20 stadi, Ryzen che ha il 52% in più di IPC deve averne di meno. E' semplice.
http://www.ece.ualberta.ca/~elliott/...-08/Zhulei.ppt

Addirittura un ordine di grandezza di differenza? Ma dove li hai presi questi numeri?

Non è 36%, ma 16%, è stato corretto. I dati li prendi anche col righello, se sai cosa cercare.

[george_p]

Scusa ma se la L3 di intel è di 19 mm^2 su 49 mm^2 mi spieghi come fa a essere il 4,5%?

[MiKeLezZ]

Originariamente inviato da george_p

Scusa ma se la L3 di intel è di 19 mm^2 su 49 mm^2 mi spieghi come fa a essere il 4,5%?

Questo è un 7700K. La "shared cache" al centro è la L3. Prendi un righello o photoshop e misuratela.



In questo disegno fa 4% e io per gentilezza mi sono tenuto largo.

[leoneazzurro]

Ehm, Mikelezz... I dati di Zen riportati nella tabella fanno riferimento al singolo CCX (44mm^2) e quelli di Kaby Lake al complesso core-cache (49 mm^2) e le percentuali sono calcolate rispetto a queste aree. La foto del die a cui fai riferimento contiene parecchie altre cose, tra cui i controller di memoria, I/O e la GPU integrata. Es. Sky Lake e Kaby Lake condividono lo stesso complesso core-cache, e Sky Lake misura circa 122mm^2, con 4 core e GPU (più piccola di Kaby Lake). Kaby Lake nel suo complesso dovrebbe (perchè non è stato confermato ufficialmente) misurare intorno ai 125-140 mm^2.

[leoneazzurro]

Originariamente inviato da gridracedriver

ah bene, aggiorno i dati sopra

Pardon, ho aggiornato, stime più recenti danno il die size di Kaby lake solo leggermente superiore a Sky Lake