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

[MiKeLezZ]

Originariamente inviato da 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 140-150 mm^2.

ok. ma per la percentuale io ho usato la misura della cache l3 dall'immagine del die e rapportata direttamente all'immagine intera del die.

[leoneazzurro]

Originariamente inviato da MiKeLezZ

ok. ma per la percentuale io ho usato la misura della cache l3 dall'immagine del die e rapportata direttamente all'immagine intera del die.

Se usassimo lo stesso criterio la cache in zen sarebbe il 16% del die, ma ha poco senso perchè di core x86 ce ne sono il doppio e in Ryzen non c'è la GPU.

[MiKeLezZ]

Originariamente inviato da leoneazzurro

Se usassimo lo stesso criterio la cache in zen sarebbe il 16% del die, ma ha poco senso perchè di core x86 ce ne sono il doppio e in Ryzen non c'è la GPU.

sì hai ragione. puoi commentare anche riguardo la lunghezza pipeline, se rispetto ai comunque stimati 18-20 di bulldozer vi sia stata una riduzione in ryzen?

[demon77]

Originariamente inviato da leoneazzurro

Se usassimo lo stesso criterio la cache in zen sarebbe il 16% del die, ma ha poco senso perchè di core x86 ce ne sono il doppio e in Ryzen non c'è la GPU.

Io dico solo che in tutte ste pagine di 3d ho visto pippozzi mentali oltremisura in tutte le salse immaginabili.

Sinceramente, visti i risultati dei test, se dovvessi prendere un pc oggi credo sarebbe un RYZEN.

Perchè con otto cores ho garanzia di potenza e longevità massima, il tutto ad un prezzo meravigliosamente conveniente rispetto ad Intel.

Il fatto del OC limitato sono briciole.
Il fatto che coi giochi va qualcosina in meno sono sempre briciole. (oltretutto questa cosa anrà a sparire secondo me, solo questione di ottimizzazione)

[MiKeLezZ]

Originariamente inviato da gridracedriver

ps. il 1800x non ha 1.40v a default come dice il guru @MiKeLezZ

Ho scritto una caz_ata, il 1800X non ha 1,4V di tensione di alimentazione, ma 1,25V (come il 7700K). Ma non mi è uscito dal nulla: stavo correggendo un utente che era convinto le CPU 14nm Intel andassero a 1,4V.

[george_p]

Mamma mia, ma a questo si deve arrivare?
Mo mi devo prendere il righello per misurare quanta cache L3 c'ha una cpu, devo contarne le pipeline, quanto son lunghe, grosse ecc... Ma per che cosa poi?

[bjt2]

Originariamente inviato da MiKeLezZ

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

Ti ho dimostrato che gli stadi sono 19 e solo per la pipeline intera. Ovviamente quella FP ne ha di più anche perchè lo scheduler è almeno 2 stadi...
EDIT: e quel PPT è quello che ha portato al pentium 4, che ha FO4 di circa 13 (compresi i flip flop intra stadio) e consiglia il FO4 ottimale per avere le massime prestazioni A PRESCINDERE dal consumo... E sappiamo tutti com'è finita con il P4. Bulldozer ha FO4 di circa 17, guarda caso quello ottimale, secondo uno studio IBM, per il miglior rapporto prestazioni/consumo. Zen si muove in quei dintorni. Altrimenti non si spiega come fa ad essere così efficiente.

Originariamente inviato da MiKeLezZ

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

Si vede l'immagine che ho postato? Mi viene il dubbio che non si veda. Quelli sono dati ufficiali di AMD. Per la colonna relativa ad INTEL, immagino che in AMD, una volta comprato un chip di skylake/kabylake sul mercato sappiano come deliddarlo, togliere lo strato protettivo e misuare le aree, quindi possiamo assumere che sono accurate...

[MiKeLezZ]

Originariamente inviato da gridracedriver

http://www.bitsandchips.it/9-hardwar...volt?showall=1
si, a parte che con tutti queste features sul risparmio energetico e clock/volt dinamico è difficile stabilirlo con precisione e dipende dal carico, ma dalle prove effettuate pare essere intorno 1.25v
http://www.bitsandchips.it/forum/dow...le.php?id=2684

matematicamente pare essere quadratico il rapporto vcore/consumo come anche il rapporto frequenza/vcore in quel range.

3.7@1.15v 155watt → 4.0@1.35v 211watt

frequenza 4/3.7=1.08^2 = 1.17x
vcore 1.35/1.15= 1.17x → 1.17^2 = 1.37x
consumo 211/155= 1.36x

Sì, bhe, interessante, ma tralasciando il fatto che il tipo è laureato in storia e non è buono neppure a fare i grafici con libreoffice...

[leoneazzurro]

Originariamente inviato da MiKeLezZ

sì hai ragione. puoi commentare anche riguardo la lunghezza pipeline, se rispetto ai comunque stimati 18-20 di bulldozer vi sia stata una riduzione in ryzen?

A dire la verità non ne ho idea, in realtà credo che le lunghezze non siano molto diverse, per arrivare a certe frequenze le CPU moderne usano comunque pipeline abbastanza lunghe e poi alleviano i problemi usando meccanismi per prevenire le branch misprediction. Le stesse architetture Intel odierne possono arrivare a 19 stadi, secondo alcune stime.

[[A]okyZ]

Vabbe potete sparare tutte le pippiate che volete.
Il 1700 RYzen è un ottimo processore che in quella fascia non ha paragoni, nemmeno nelle cose in cui non dovrebbe eccellere come game &co, dove cmq va da Dio.
Il resto sono parole.

[riuzasan]

Originariamente inviato da MiKeLezZ

Sì, bhe, interessante, ma tralasciando il fatto che il tipo è laureato in storia e non è buono neppure a fare i grafici con libreoffice...

Mmm e quindi, non è che i tuoi post siano molto lontani da articoli su ilfattoquotiDaino.it o ansIa.it
Adesso mi prendo una foto del die e ci misuro la velocità delle pipeline ...

[MiKeLezZ]

Originariamente inviato da riuzasan

Mmm e quindi, non è che i tuoi post siano molto lontani da articoli su ilfattoquotiDaino.it o ansIa.it
Adesso mi prendo una foto del die e ci misuro la velocità delle pipeline ...

Sei davvero utile alla discussione.

Originariamente inviato da bjt2

Ti ho dimostrato che gli stadi sono 19 e solo per la pipeline intera.

Non capisco perché ti intestardisci, AMD non ha fornito alcuna specifica (con un lapidario "no comment"), il tuo "sapere" deriva dalla speculazione del blogger "dresdenboy", poi ripresa da un magazine qualunque (che hai linkato).
Il link originario è questo:
http://semiaccurate.com/forums/showp...postcount=3781
L'informazione non è ufficiale.

Bulldozer aveva una pipeline lenght di 16-19 che si trasformava in 19-22 nel caso di misprediction (http://www.agner.org/optimize/microarchitecture.pdf).
AMD ha dichiarato che con Ryzen è riuscita a migliorare notevolmente l'IPC migliorando il branch predictor e ingrandendo la opcache.
In effetti non ha mai parlato direttamente di riduzione di stage di pipeline (la riduzione che intende potrebbe anche derivare dalla scorciatoia della opcache)... per quanto ne sappiamo sia io che te può anche averla lasciata 16-19 oppure averla portata a 14-19, in entrambi i casi non vedo l'importanza della cosa.

Di certo se voleva migliorare il suo IPC non sarebbe stata l'idea più geniale fare una pipeline a 30 stadi e accoppiarvi CPU da 3 GHz.

Si vede l'immagine che ho postato? Mi viene il dubbio che non si veda. Quelli sono dati ufficiali di AMD. Per la colonna relativa ad INTEL, immagino che in AMD, una volta comprato un chip di skylake/kabylake sul mercato sappiano come deliddarlo, togliere lo strato protettivo e misuare le aree, quindi possiamo assumere che sono accurate...

Sì hai ragione.
Sempre allo stesso link si evince come il processo a 14nm di AMD sia leggermente meno performante di quello Intel:
http://wccftech.com/ryzen-smaller-di...-not-good-hpc/

In definitiva, che la colpa sia della scarsa maturità dell'architettura, della difficoltà di far dialogare 8 CPU assieme, della maggiormente compressa L2/L3, delle differenze architetturali fra le CPU, della differente abilità produttiva della fonderia... IL PUNTO E' CHE LE CPU RYZEN HANNO QUALCHE CENTINAIO DI MHZ IN MENO RISPETTO LE CPU INTEL e un paragone clock-to-clock non ha senso, se non a fini accademici (visto si tratta di downcloccare una delle due CPU).
Si parlava di questo 2 giorni fa, poi è stato tutto un divagare.
Con Ryzen 2 è possibile risolvano tutto, vada a bomba e tiri a 5 GHz, ma se ne riparla fra 16 mesi.
Ok? La accendiamo?

[cdimauro]

Originariamente inviato da bjt2

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

Perché l'L3 non è di esclusiva proprietà di un core, ma le "fette" (slice) vengono usate alla bisogna, dai vari thread hardware.

Inoltre i thread hardware non accedono alla L3 facendo interleaving coi bit bassi. I test sulla latenza hanno dimostrato inequivocabilmente che i pattern 4MB, 6MB, e 8MB sono dovuti alla suddivisione & dislocazione della cache L3 a "tagli" di 1MB. Come da diagramma che ha riportato qualche utente (LHMC?) qualche giorno fa, e idem per la foto del CCX.

Originariamente inviato da george_p

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?

Al contrario: leggo se qualche caratteristica micro-architetturale possa essere utilizzata allo scopo da un certo tipo di software.

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?

Intel ha introdotto l'SMT col P4, e infatti continua a chiamarsi HyperThreading.

Non so se all'epoca il software dovesse necessariamente controllare la presenza dell'HT, visto che i due thread hardware venivano visti come due core indipendenti. Infatti in genere le applicazioni vengono sviluppate non tenendo dell'SMT, ma rilevando invece il numero di "core" presenti nel sistema, e creando dei processi e/o thread hardware per cercare di usarli tutti, oppure dei generici pool ("worker", in gergo) a cui assegnare dei task da eseguire, e che questi poi smisteranno ai vari "core" via via liberi.

E' il s.o., infatti, che normalmente si prende la briga di allocare i processi/thread hardware nei vari "core" a disposizione, tenendo eventualmente conto di caratteristiche come il NUMA.

Ovviamente son tutte cose che potrebbe fare autonomamente anche un'applicazione, decidendo da sé in quali specifici "core" piazzare i suoi processi / thread hardware.

Ma è una cosa che non rappresenta affatto la norma, per l'appunto, perché è comodo lasciare che il s.o. se ne occupi.

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

Le applicazioni (inclusi i giochi) non hanno a che vedere con driver e BIOS, se non indirettamente, sfruttandoli in maniera trasparente tramite il s.o..

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

Hai fatto un'affermazione e te ne ho semplicemente nonché asetticamente chiesta la motivazione tecnica.

Se vuoi rispondere OK, e possiamo intavolare una discussione. Ma se non vuoi rispondere, allora evita direttamente queste uscite polemiche.

[bjt2]

Originariamente inviato da MiKeLezZ

Bulldozer aveva una pipeline lenght di 16-19 che si trasformava in 19-22 nel caso di misprediction (http://www.agner.org/optimize/microarchitecture.pdf).
AMD ha dichiarato che con Ryzen è riuscita a migliorare notevolmente l'IPC migliorando il branch predictor e ingrandendo la opcache.
In effetti non ha mai parlato direttamente di riduzione di stage di pipeline (la riduzione che intende potrebbe anche derivare dalla scorciatoia della opcache)... per quanto ne sappiamo sia io che te può anche averla lasciata 16-19 oppure averla portata a 14-19, in entrambi i casi non vedo l'importanza della cosa.

L'articolo è paywalled e quello è solo l'abstract. E l'ha scritto David Kanter che non è proprio un blogger qualunque, ma autore di realworldtech. Se hai mai letto quel sito, capirai che sono molto ferrati sull'argomento e credo abbiano anche informazioni privilegiate.

Originariamente inviato da MiKeLezZ

Di certo se voleva migliorare il suo IPC non sarebbe stata l'idea più geniale fare una pipeline a 30 stadi e accoppiarvi CPU da 3 GHz.

Se una pipeline è a 30 stadi, non hai una CPU da 3 GHz. Il prescott che era 31 stadi era 3.8GHz sul 90nm... Non sono scollegate le due cose... Se non comprendi questa cosa, non vedo come tu possa disquisire di pipeline, FO4 e compagnia bella...

Originariamente inviato da MiKeLezZ

Sì hai ragione.
Sempre allo stesso link si evince come il processo a 14nm di AMD sia leggermente meno performante di quello Intel:
http://wccftech.com/ryzen-smaller-di...-not-good-hpc/

In definitiva, che la colpa sia della scarsa maturità dell'architettura, della difficoltà di far dialogare 8 CPU assieme, della maggiormente compressa L2/L3, delle differenze architetturali fra le CPU, della differente abilità produttiva della fonderia... IL PUNTO E' CHE LE CPU RYZEN HANNO QUALCHE CENTINAIO DI MHZ IN MENO RISPETTO LE CPU INTEL e un paragone clock-to-clock non ha senso, se non a fini accademici (visto si tratta di downcloccare una delle due CPU).
Si parlava di questo 2 giorni fa, poi è stato tutto un divagare.
Con Ryzen 2 è possibile risolvano tutto, vada a bomba e tiri a 5 GHz, ma se ne riparla fra 16 mesi.
Ok? La accendiamo?

Ha qualche centinaio di MHz in meno? 8 core vs 4 core! Prendi il 6900K a default e Ryzen a default e poi ne parliamo!
E poi se vedi la densità di transistor è quasi doppia, quindi qualcosa in frequenza la perdi...

[bjt2]

Originariamente inviato da cdimauro

Perché l'L3 non è di esclusiva proprietà di un core, ma le "fette" (slice) vengono usate alla bisogna, dai vari thread hardware.

Inoltre i thread hardware non accedono alla L3 facendo interleaving coi bit bassi. I test sulla latenza hanno dimostrato inequivocabilmente che i pattern 4MB, 6MB, e 8MB sono dovuti alla suddivisione & dislocazione della cache L3 a "tagli" di 1MB. Come da diagramma che ha riportato qualche utente (LHMC?) qualche giorno fa, e idem per la foto del CCX.

Questo è quello che ha dichiarato AMD ad hot chips. Se poi è configurabile come per la RAM ai tempi andati e per qualche ragione è settato diversamente, non lo posso sapere. I gradini al megabyte può anche essere dovuta alle vie: la cache L3 è 2x8MB mi pare o 8 o 16 vie...

[cdimauro]

Originariamente inviato da LMCH

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.

Allora perché la tendenza (e non mi riferisco solo a Intel qui) in ambito rimane quella di avere unità vettoriali sempre più larghe?

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.

OK, ma è dai tempi delle MMX che sono approdate in ambito desktop, e continuano a essere potenziate.

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.

Hum. Ho letto poco, ma da quel che ho capito l'applicazione definisce (a livello di ISA / istruzioni) se usare vettori da 128, 512, o 2048 bit. Poi è l'implementazione specifica che, se ce la fa, esegue in un colpo l'operazione, oppure la suddivide in base alla massima dimensione che riesce a gestire.

Ma ribadisco: è quel ricordo da ciò che lessi tempo fa. Per cui potrei anche sbagliarmi.

In ogni caso il nocciolo della discussione è che pure ARM crede nelle unità SIMD "massicce".

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

Certamente, ma, data la particolarità della micro-architettura, lo scheduler dovrà essere cambiato non poco per alleviare le problematiche emerse in queste particolari situazioni. E non so nemmeno se ne valga la pena (vedi anche sotto).

( e già ora ha buone prestazioni per il prezzo che ha).

Ma infatti se qualcuno pensasse che le prestazioni potrebbero essere rivoluzionate soltanto cambiando lo scheduler, mi sa che peccherebbe d'ingenuità.

Per il resto concordo: ci sono buone prestazioni, e il prezzo rappresenta il vantaggio più grande di questa nuova famiglia di processori.

[cdimauro]

Originariamente inviato da lucusta

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.

No. Da tempo Intel condivide la cache L3 fra CPU e iGPU. E nel caso delle versioni Iris Pro con eDRAM integrata, quest'ultima viene utilizzata trasparentemente come fosse una cache L4 dalla CPU, con un certo vantaggio prestazionale.

Non concordo, poi, che APU = HSA. Anche qui, da tempo le iGPU di Intel possono essere sfruttate con strumenti quali OpenCL o le ben più vecchie (perfino di HSA) Cilk / Cilk+.

per quanto riguarda la gestione delle frequenze di CPU e iGPU di una APU è un altro paio di maniche rispetto alle AWX Intel.

Le AWX non esistono. Immagino che, dal contesto, ti riferissi alle AVX.

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.

Non so che esperienze hai avuto, ma è noto nonché documentato che le APU di AMD abbiano seri problemi di throttling / abbassamento consistente della frequenza della CPU, in particolare usandola al contempo con l'iGPU.

Viceversa, è anch'esso noto e documentato che le frequenze nei processori Intel calino di qualche centinaio di Mhz, ma soltanto usando intensamente le AVX. L'uso dell'iGPU non influisce sulla frequenza del processore.

[cdimauro]

Originariamente inviato da bjt2

Ti ho dimostrato che gli stadi sono 19 e solo per la pipeline intera. Ovviamente quella FP ne ha di più anche perchè lo scheduler è almeno 2 stadi...
EDIT: e quel PPT è quello che ha portato al pentium 4, che ha FO4 di circa 13 (compresi i flip flop intra stadio) e consiglia il FO4 ottimale per avere le massime prestazioni A PRESCINDERE dal consumo... E sappiamo tutti com'è finita con il P4. Bulldozer ha FO4 di circa 17, guarda caso quello ottimale, secondo uno studio IBM, per il miglior rapporto prestazioni/consumo. Zen si muove in quei dintorni. Altrimenti non si spiega come fa ad essere così efficiente.

Infatti Zen non è così efficiente, come s'è visto. Ecco gli ultimi test, effettuati con Photoshop:https://www.pugetsystems.com/pic_dis...1966&width=701
Lightroom:https://www.pugetsystems.com/pic_dis...1990&width=700
Premier:https://www.pugetsystems.com/pic_dis...1990&width=700
e Solidworks:https://www.pugetsystems.com/pic_dis...2009&width=701

dove si vede che è costantemente sotto il 6900K, che però viaggia a frequenze ben inferiori.

La micro-architettura, come già detto, non è efficiente come quella delle CPU Intel. Ma riesce a fare molto bene in ambiti MT, con codice "più lineare".

Comunque nulla che non abbia già detto.

Originariamente inviato da bjt2

L'articolo è paywalled e quello è solo l'abstract. E l'ha scritto David Kanter che non è proprio un blogger qualunque, ma autore di realworldtech. Se hai mai letto quel sito, capirai che sono molto ferrati sull'argomento e credo abbiano anche informazioni privilegiate.

Di questo ne abbiamo già parlato nel thread Aspettando Zen, e ti feci notare che Kanter esprimesse sue opinioni. Dunque non v'era/è alcuna certezza né tanto meno ufficialità.

D'altra parte Bulldozer, sui 32nm SOI, è arrivato a toccare i 4,2Ghz su un TDP di 125W.
Piledriver, sui 28nm BULK, è arrivato a 4,3Ghz sullo stesso TDP.
Zen, invece, è arrivato a stento a 4Ghz, ma a "14"nm e FinFET: più di un nodo di vantaggio nonché l'enorme vantaggio della nuova tecnologia. Dunque ben lontano dalle fantasmagoriche frequenze che avrebbe dovuto raggiungere.

Si vede con Bulldozer & co. non è che abbia poi tanto da spartire.

Se una pipeline è a 30 stadi, non hai una CPU da 3 GHz. Il prescott che era 31 stadi era 3.8GHz sul 90nm... Non sono scollegate le due cose... Se non comprendi questa cosa, non vedo come tu possa disquisire di pipeline, FO4 e compagnia bella...

A quanto è arrivato Northwood, con 20 stadi di pipeline?

Ha qualche centinaio di MHz in meno? 8 core vs 4 core! Prendi il 6900K a default e Ryzen a default e poi ne parliamo!

Fatto: vedi sopra i nuovi test con 4 applicazioni rinomate / blasonate. Guarda pure a quanto arriva il 1800X a default, e a quanto il 6900K.

E poi se vedi la densità di transistor è quasi doppia, quindi qualcosa in frequenza la perdi...

E non dimentichiamo che il processo produttivo è un LP: si comporta benissimo a basse frequenze, dove i consumi sono eccezionalmente bassi (infatti IMO sarà questo il suo vero punto di forza in ambito server, dove Intel non può arrivare a certi livelli di consumo a causa del suo processo HP), ma diventano eccezionalmente alti quando si superano i 3Ghz.

Infatti fra 1700X e 1800X ci sono 200 (base) e 100 (turbo) Mhz di differenza: una miseria. Ma quest'ultimo ha consumi di gran lunga superiori.

Originariamente inviato da bjt2

Questo è quello che ha dichiarato AMD ad hot chips. Se poi è configurabile come per la RAM ai tempi andati e per qualche ragione è settato diversamente, non lo posso sapere.

Non credo che si possa settare alcunché per la cache L3.

I gradini al megabyte può anche essere dovuta alle vie: la cache L3 è 2x8MB mi pare o 8 o 16 vie...

Potrebbe anche essere. AMD pubblicizza la L3 a 16 vie, e guarda caso sono 16 slice da 1MB.

Ma 1MB di cache L3 a una sola via sarebbe troppo poco performante (nel senso che sarebbe troppo soggetto a trashing dei dati).

Purtroppo non ci sono informazioni chiare in merito.

[bjt2]

Originariamente inviato da cdimauro

Infatti Zen non è così efficiente, come s'è visto. Ecco gli ultimi test, effettuati con Photoshop:https://www.pugetsystems.com/pic_dis...1966&width=701
Lightroom:https://www.pugetsystems.com/pic_dis...1990&width=700
Premier:https://www.pugetsystems.com/pic_dis...1990&width=700
e Solidworks:https://www.pugetsystems.com/pic_dis...2009&width=701

dove si vede che è costantemente sotto il 6900K, che però viaggia a frequenze ben inferiori.

La micro-architettura, come già detto, non è efficiente come quella delle CPU Intel. Ma riesce a fare molto bene in ambiti MT, con codice "più lineare".

Comunque nulla che non abbia già detto.
[CUT]

Fatto: vedi sopra i nuovi test con 4 applicazioni rinomate / blasonate. Guarda pure a quanto arriva il 1800X a default, e a quanto il 6900K.

E non dimentichiamo che il processo produttivo è un LP: si comporta benissimo a basse frequenze, dove i consumi sono eccezionalmente bassi (infatti IMO sarà questo il suo vero punto di forza in ambito server, dove Intel non può arrivare a certi livelli di consumo a causa del suo processo HP), ma diventano eccezionalmente alti quando si superano i 3Ghz.

Infatti fra 1700X e 1800X ci sono 200 (base) e 100 (turbo) Mhz di differenza: una miseria. Ma quest'ultimo ha consumi di gran lunga superiori.

Non in tutti i bench. E gli adobe sono sempre andati bene con intel. Supporrei che usi compilatori intel recenti, visto che i suoi clienti sono interessati alle massime prestazioni e comunque suppongo che usi le AVX a 256 bit (vorrei vedere anche le cpu entry level con avx2 disabilitato, IMHO una auto-martellata sui maroni di INTEL). Ci sono test (handbrake ad esempio) in cui l'IPC è superiore. E il tanto osannato cinebench ha pari IPC in ST anche rispetto a kaby lake (o quasi) e maggiore MT grazie all'SMT... Quindi ryzen non fa poi tanto schifo...

E comunque mi riferivo al rapporto prestazioni consumi in ambito server, vedi test vs 44c/88c Xeon...

Originariamente inviato da cdimauro

Di questo ne abbiamo già parlato nel thread Aspettando Zen, e ti feci notare che Kanter esprimesse sue opinioni. Dunque non v'era/è alcuna certezza né tanto meno ufficialità.

E' un articolo paywalled... Non credo ci siano scritte solo sue opinioni. Su realworldtech ho letto dei magnifici articoli, a gratis, su molte architetture moderne...

Originariamente inviato da cdimauro

D'altra parte Bulldozer, sui 32nm SOI, è arrivato a toccare i 4,2Ghz su un TDP di 125W.
Piledriver, sui 28nm BULK, è arrivato a 4,3Ghz sullo stesso TDP.
Zen, invece, è arrivato a stento a 4Ghz, ma a "14"nm e FinFET: più di un nodo di vantaggio nonché l'enorme vantaggio della nuova tecnologia. Dunque ben lontano dalle fantasmagoriche frequenze che avrebbe dovuto raggiungere.

Si vede con Bulldozer & co. non è che abbia poi tanto da spartire. ;

A causa della densità di transistor... Sicuramente il FO4 è inferiore a BDWE, perchè ha clock superiore e TDP nominale inferiore...

Originariamente inviato da cdimauro

A quanto è arrivato Northwood, con 20 stadi di pipeline?

Ho un northwood 2.8GHz con HT in ufficio. 130nm. E l'Athlon64 sul 90nm (e forse anche il 65nm) era sui 2.6GHz...

[NvidiaMen]

Nonostante gli approfondimenti sulle architetture spesso rischino l'off topic è da fare un plauso a tutti i partecipanti del thread che con il loro contributo aiutano a stimolare la mente sui perché di alcune scelte architetturali eseguite dai due maggiori produttori di microchip con licenza x86.

In attesa di alcuni affinamenti software sullo scheduler di Windows 10, un passaggio dovuto per valutare appieno una nuova piattaforma come Ryzen nella quale non si dà priorità ai core fisici rispetto a quelli logici, rimanendo questi inefficaci, ed anzi dovendo gli stessi essere disabilitati, venendo meno alla loro principale funzione di ottimizzazione dei threads paralleli, rimane tuttavia una considerazione che prescinde da tutto ciò in ordine alle scelte che un gamer di alto livello dovrebbe fare.
Mi riferisco alle piattaforme quadcore, che a mio modesto avviso dovrebbero essere messe da parte nei futuri upgrade a favore di quelle octacore, Intel o AMD che siano. In un mondo videoludico con codice ottimizzato per quad core la differenza a vantaggio di un 7700k, che in media lavora in campo videoludico tra il 60 ed il 65%, a differenza del 30-35% di un octacore 1800x o 6800k è assolutamente trascurabile soprattutto con l'avvento del 4k e modesta a 1080p con dettagli al massimo; inoltre le percentuali di occupazione delle risorse la dicono tutta sulla potenzialità inespressa dai processori con il doppio delle unità di calcolo.

Aumentando la base installata di processori ad 8 cores si darebbe modo anche agli sviluppatori di prendere in considerazione un upgrade dei loro motori di gioco per aumentare ancor di più il realismo nei giochi e favorire l'abbandono della tecnica di rasterizzazione a vantaggio di tecniche grafiche fotorealistiche di raytracing in tempo reale supportate da CPU e GPU di alto livello.

Ecco perché sono completamente favorevole all'introduzione di piattaforme octacore nel mercato a prezzi più concorrenziali, consapevole del fatto che se mai si effettuerà il passaggio mai entreremo in una nuova fase.
Giusto per far intuire cosa si intenda per "esperienze videoludiche di nuova generazione" vi lascio dei link a due nuovi e promettenti motori in sviluppo che un giorno non troppo lontano spero possano soppiantare quelli attuali.
Mizuchi Engine
Dream Engine by Vaya