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

[LMCH]

Originariamente inviato da cdimauro

Grazie per il documento, che finalmente ha fatto chiarezza su quest'oggetto misterioso.

Ti confermo che NON si tratta di un coprocessore.

Dipende dall'implementazione, non ti fare ingannare dalla mappatura logica dei registi NEON.
Nell' implementazione massima (registri a 2048bit) devono essere per forza un unità funzionale separata, a tutti gli effetti un coprocessore.
Il grosso vantaggio rispetto ad altri approcci è che nelle implementazioni più "spartane"
si possono integrare nei core aggiungendo una manciata di registri dei predicati
senza neanche dove ampliare i datapath e mantenendo piena compatibilità con una implementazione a 2048bit.

Originariamente inviato da cdimauro

Per fare un paragone, SVE sta a NEON come AVX-512 ad SSE/AVX.

Non è un estensione dello stesso concetto, l'idea di base non è "unita SIMD" ma unità ottimizzata per l'elaborazione di vettori di lunghezza variabile che per avere le massime prestazioni non richiede riscrittura o ricompilazione del codice per adattarsi a differenti dimensioni dei registri "interni" come invece succede con le SIMD ( e con la possibilità di cambiare l'ampiezza dei registri e dei datapath come più torna comodo).

Come modello architetturale e modello di programmazione è tutto un altro paio di maniche rispetto ad AVX-512.

O per dirla in un altro modo sarebbe come avere un unico set d'istruzioni
AVX identico per AVX, AVX-512, AVX-768,.., AVX-1024,...,AVX-2048
e con codice ottimizzato esclusivamente per AVX-2048 che gira senza ricompilare e senza degrado di prestazioni (rispetto alla specifica cpu) su un implementazione "solo" AVX.
Questo perche si ragiona, si codifica e si ottimizza il codice SVE in termini di VETTORI (con lunghezza generica), non in termini di registri "multimediali" di lunghezza fissa.

Originariamente inviato da cdimauro

E non a caso, visto che ha preso a piene mani dalle AVX-512 di Intel:
- vettori ampi, che si mappano sugli esistenti registri dell'unità SIMD preesistente;
- registri di maschera che qui vengono chiamati di predizione;
- concetto di lane, con relativa modalità di merge o zeroing;
- istruzioni condizionate che sfruttano i suddetti registri di predizione;
- istruzioni che generano maschere per i registri di predizione;
- istruzioni di loop basate sui registri di predizione;
- modalità d'indirizzamento della memoria con gather/scatter sfruttando registri vettoriali.

Ovviamente ha esteso il tutto, con una versione vector-length agnostic, per l'appunto (e dunque con opportune istruzioni che servono allo scopo).

La mappatura (parziale) sui NEON serve per semplificare l'interscambio dati sui registri interni senza dover aggiungere istruzioni ad hoc e per rendere ancora più compatta l'implementazione minima ( SVE-128 ).

E, ripeto, il fatto che SVE sia vector-lenght agnostic cambia totalmente le carte in tavola rispetto ad un architettura SIMD, specialmente sul lato software.

[george_p]

Originariamente inviato da cdimauro

Ma quali ottimizzazioni avrebbero i giochi per le CPU Intel? Che ciò da cui è partita la nostra (sotto)discussione.

L'SMT, infatti, crea problemi anche alle CPU Intel, com'è stato mostrato con test in cui è stato disattivato, sebbene in misura minore rispetto a Ryzen. Ma il problema è lì, da parecchio tempo, pur tenendo conto che Intel è l'azienda dominante.

Il silicio è ormai maturo, dopo 15 mesi dalla commercializzazione dei primi prodotti da parte di GF, per cui non aspettatevi dei cambiamenti in merito.

Stai rimanendo sempre in ambito grafico, dove è naturale parallelizzare & distribuire i carichi di lavoro. Ovviamente la tecnologia avanza, si affina, arrivano sempre novità per avere prestazioni migliori, ma il trend generale non cambia: sono algoritmi altamente scalabili.

D'altra parte l'evoluzione delle GPU penso sia eloquente: siamo arrivati a migliaia di core integrati, che processano e renderizzano le scena.

Ma in altri ambiti non è affatto così. Anzi, alcuni problemi sono intrinsecamente seriali, e non possono nemmeno avvantaggiarsi di qualche thread hardware in più.

Faccio il classico esempio dell'emulazione: emulare un processore fa parte di queste tipologie di codice assolutamente non parallelizzabili. Puoi metterci tutto l'impegno e le risorse che vuoi: sarà sempre e soltanto un core / thread hardware a potersi fare carico dell'operazione.

Come già detto, sistemi con più core e/o più thread hardware ci sono ormai da più di 15 anni, eppure sono ancora poco sfruttati, e tante volte non certo per la pigrizia dei programmatori (vedi sopra).

Inoltre le software house hanno budget da rispettare, e dunque anche nel caso in cui del codice sia parallelizzabile, bisogna investirci.

Ma non penso ci sia solo l'SMT in una architettura complessa come quelle intel e amd, no?

Non sono io a scrivere questo che riporto ma tante persone che studiano o lavorano nel settore programmazione.

Lato silicio non ho detto che il 14 nm glofo sia immaturo, ovvio deve esserlo abbastanza maturo per aver permesso questi risultati per frequenze e consumi con gli octacore amd che ricordiamo hanno circa 5 miliardi di transistor. Ma penso anche ci sia un ulteriore margine di miglioramento del prodotto nei prossimi mesi... come è accaduto per il 14 nm di intel.
non sarà mica come il 32 nm sempre glofo precedente? Quello non aveva permesso nessun miglioramento o quasi da subito, vedi differenza tra i sample e le cpu BD al loro debutto, e la differenza nel caso di Zen.

[NvidiaMen]

Originariamente inviato da cdimauro

Ma quali ottimizzazioni avrebbero i giochi per le CPU Intel? Che ciò da cui è partita la nostra (sotto)discussione.

L'SMT, infatti, crea problemi anche alle CPU Intel, com'è stato mostrato con test in cui è stato disattivato, sebbene in misura minore rispetto a Ryzen. Ma il problema è lì, da parecchio tempo, pur tenendo conto che Intel è l'azienda dominante.

Il silicio è ormai maturo, dopo 15 mesi dalla commercializzazione dei primi prodotti da parte di GF, per cui non aspettatevi dei cambiamenti in merito.

Quoto in toto circa la poca utilità ad oggi in ambito videoludico delle SMT. Circa le ottimizzazioni ad hoc credo che Intel con le attuali architetture sia circa al 90%, ed AMD solo nei prossimi mesi potrà avvalersi di un tale vantaggio.

Originariamente inviato da cdimauro

Stai rimanendo sempre in ambito grafico, dove è naturale parallelizzare & distribuire i carichi di lavoro. Ovviamente la tecnologia avanza, si affina, arrivano sempre novità per avere prestazioni migliori, ma il trend generale non cambia: sono algoritmi altamente scalabili.
D'altra parte l'evoluzione delle GPU penso sia eloquente: siamo arrivati a migliaia di core integrati, che processano e renderizzano le scena.
Ma in altri ambiti non è affatto così. Anzi, alcuni problemi sono intrinsecamente seriali, e non possono nemmeno avvantaggiarsi di qualche thread hardware in più.

E tu stai rimanendo sempre ancorato alla situazione attuale che è davvero "poco auspicabile" per un appassionato di tecnologia come sembri essere te. Fosse per te ed il tuo ragionamento quasi quasi il mondo videoludico si dovrebbe fermare vita natural durante sui quad core e spingere quest'ultimi magari su frequenze irraggiungibili al silicio.
La legge di Moore secondo la quale il numero di transistori per chip, raddoppi ogni 18 mesi ha necessità del multicore affinché possa avere un senso da un punto di vista prestazionale e, volenti o nolenti, anche il software dovrà seguire questa strada. Ricorda che nella vita ed in ogni ambito tutto è difficile solo per chi non ci crede. Mi chiedo un po', ma la pensavi anche così all'epoca dei single core, dei dual core e dei quad core prima della loro introduzione? Il codice può assolutamente essere parallelizzato anche lato CPU, questo non è un punto di vista ma un dato di fatto in quanto TUTTI gli algoritmi di renderizzazione in ray-tracing lavorano esclusivamente in multithreading sui cores attraverso algoritmi software (vedi il predetto Vray utilizzato anche nel tuo odiato Cinebench). Semmai quest'oggi è vero il contrario: pur disponendo di GPU con elevata prestazione computazionale il codice per sfruttarle via hardware in tale ambito non è a livello di quello utilizzato per il processamento via software mediante CPU. Questo perché stiamo continuando a "perder tempo" in ambito gaming con affinamenti sulla tecnica di rasterizzazione, ambito nel quale girano e si investono un sacco di soldi. Ma quando questi affinamenti grafici non troveranno più ulteriori migliorie apprezzabili dagli utenti si dovrà OBBLIGATORIAMENTE passare oltre.

Originariamente inviato da cdimauro

Faccio il classico esempio dell'emulazione: emulare un processore fa parte di queste tipologie di codice assolutamente non parallelizzabili. Puoi metterci tutto l'impegno e le risorse che vuoi: sarà sempre e soltanto un core / thread hardware a potersi fare carico dell'operazione.

L'emulazione è proprio un discorso che nulla ha a che vedere con la parallelizzazione del codice perché porta un livello di complessità ben diversa e con problematiche molto più delicate e per la quale son pochissime le risorse che si destinano in ambito di sviluppo software. Per tali ambiti si utilizzano più "semplicemente" le virtualizzazioni via hardware che fanno vedere un insieme di risorse (cores) come un'unica unità elaborativa e con risultati molto soddisfacenti rispetto alla originaria macchina emulata.

Originariamente inviato da cdimauro

Come già detto, sistemi con più core e/o più thread hardware ci sono ormai da più di 15 anni, eppure sono ancora poco sfruttati, e tante volte non certo per la pigrizia dei programmatori (vedi sopra).
Inoltre le software house hanno budget da rispettare, e dunque anche nel caso in cui del codice sia parallelizzabile, bisogna investirci.

Nei precedenti 15 anni è stato possibile migliorare le prestazioni dei processori a livello architetturale nel rispetto della Legge di Moore senza affidarsi al multithreading che è rimasto relegato esclusivamente in ambiti specifici della ricerca e per algoritmi progettati ad hoc per i quali era richiesta una elevata capacità computazionale.
Ti assicuro che le case software più che i budget da rispettare devono in primis rispettare le scadenze annuali di immissione sul mercato dei loro prodotti. Ecco il perché ci si ritrova con giochi pieni di bug all'uscita che poi vengono risolti strada facendo. I soldi sono l'ultimo dei problemi in quanto a fine 2016 l'intera industria di gaming ed entrainment mondiale ha raggiunto la stratosferica cifra di 91 Miliardi di dollari ed è in continua ascesa visto l'interesse che si allarga sempre più a macchia d'olio tra i consumatori, praticamente più del fatturato dell'industria cinematografica e musicale mondiali messe insieme tanto per dare un'idea. Parallelamente ad esse (Ubisoft, EA, Activision, ecc.), che nello sviluppo di nuove tecnologie software entrano solo parzialmente occupandosi di mero "assemblaggio" di codice destinando le loro risorse alla realizzazione dei prodotti, operano altre software houses che si dedicano esclusivamente ai motori di fisica, di render, di IA con il fine ultimo di sfruttare sempre più, con algoritmi proprietari ed API, le ultime tecnologie hardware di nuova e prossima introduzione. Sta solo a noi consumatori promuovere attraverso acquisti intelligenti di prodotti con maggior potenziale di crescita al fine di farli diffondere maggiormente e giustificare gli sforzi da destinare a chi opera nel settore. I margini ed il profitto in ambito videoludico si fanno su larga scala ed occorre favorire una diffusione più capillare per contribuire come consumatori che fanno il loro interesse in tutto questo processo. Spero sia stato chiaro e non oggetto di un tuo ulteriore quote che vada a rispondere con altro pur di rispondere.

[Vul]

Interessantissima recensione per chi si preoccupa di Ryzen e il gaming:

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

Riassumendo:
-gli fps medi sono molto più simili fra R7 ed i7 quando si gioca davvero che nei benchmark
-R7 offre molto meno stuttering registrando, usando shadowplay, ecc
-R7 quadruplica a volte le prestazioni di un 7700k in ambito produttività, nel migliore dei casi un i7 distacca un r7 di 10 punti percentuali solo su giochi abbastanza male ottimizzati
-AMD collabora con una valanga di produttori di giochi (che hanno già ufficializzato ottimizzazioni pro Ryzen), Intel non può vantare la stessa cosa
-AM4 è destinato a durare 3-4 generazioni di cpu, con Intel si cambia tutto in continuazione
-il futuro è verso un numero di core/thread superiore

[george_p]

Originariamente inviato da Vul

Interessantissima recensione per chi si preoccupa di Ryzen e il gaming:

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

Riassumendo:
-gli fps medi sono molto più simili fra R7 ed i7 quando si gioca davvero che nei benchmark
-R7 offre molto meno stuttering registrando, usando shadowplay, ecc
-R7 quadruplica a volte le prestazioni di un 7700k in ambito produttività, nel migliore dei casi un i7 distacca un r7 di 10 punti percentuali solo su giochi abbastanza male ottimizzati
-AMD collabora con una valanga di produttori di giochi (che hanno già ufficializzato ottimizzazioni pro Ryzen), Intel non può vantare la stessa cosa
-AM4 è destinato a durare 3-4 generazioni di cpu, con Intel si cambia tutto in continuazione
-il futuro è verso un numero di core/thread superiore

Questo è già stato fatto notare da quasi subito ma si preferisce far pesare i grafici che "congelano" il numero dei frames in un dato intervallo di tempo senza alla fine considerare la realtà del gioco.
Ah si, vero avevo già letto di ottimizzazioni per Ryzen da parte delle software house peraltro annunciate da amd stessa, in "contraddizione" con quello che si scrive qui per certi versi dove non sembrano esistere queste ottimizzazioni per videogames.

[Zappa1981]

Originariamente inviato da nickname88

Lo scopo era un altro.
Quello di mostrato che nei giochi il quad anche con SMT è sfruttato e pesa sul dual, e per giunta alcun di quei titoli sono pure VGA limited.

AoS : 20 vs 38
TW3 : 64 vs 112
Tomb Raider : 54 vs 102
AC : 68 vs 112
Crysis : 30 vs 68

Sinceramente non so dove li vedi i 110fps, e pensare che mancano Total War, BF, Watch Dogs ed Anno.

io volevo vedere il risultato di ungine heaven, io con un phenomII x6 sono già cpu limited per la 1060 e lo noto bene negli fps minimi

[cdimauro]

Originariamente inviato da leoneazzurro

Non proprio... sicuramente si guadagna anche lì (il 7%)

Sì, ma mettiti nei panni dell'utente che dovrà comprare le memorie per Ryzen.

ma il post riguarda soprattutto dei problemi specifici di alcuni giochi e le configurazioni generati da essi e salvate sul cloud. Questo spiega le discrepanze tra le recensioni in quel gioco, e chissà che non salti fuori anche qualche altra magagna del genere in altri giochi.

Se i giochi sono realizzati dalla stessa "mano", potrebbe essere. Ma, per questo motivo, dubito che ce ne siano tanti nella stessa condizione.

Originariamente inviato da LMCH

Dipende dall'implementazione, non ti fare ingannare dalla mappatura logica dei registi NEON.
Nell' implementazione massima (registri a 2048bit) devono essere per forza un unità funzionale separata, a tutti gli effetti un coprocessore.
Il grosso vantaggio rispetto ad altri approcci è che nelle implementazioni più "spartane"
si possono integrare nei core aggiungendo una manciata di registri dei predicati
senza neanche dove ampliare i datapath e mantenendo piena compatibilità con una implementazione a 2048bit.

Dubito che assisteremo a implementazioni così spinte, per i problemi di clock skew di cui abbiamo già parlato.

Ciò premesso, se hai avuto modo di vedere come funziona, anche nel caso di implementazione con vettori particolarmente lunghi, non vedrai comunque implementata quest'unità SIMD come un coprocessore separato, visto che vengono eseguite normali istruzioni dell'ISA ARM, e parecchie di esse riguardano i registri di predizione.

IMO il design sarà molto simile a quello di Larrabee & Xeon Phi, dove l'unità "intera" (classiche istruzioni x86. ARMv8 in questo caso) ha il suo scheduler, mentre l'unità SIMD ha il suo, e comunicano fra di loro quando necessario (ad esempio quando si deve indirizzare la memoria per leggere o scrivere un vettore, ma ovviamente servono i registri GP per calcolare l'indirizzo).

Non è un estensione dello stesso concetto, l'idea di base non è "unita SIMD" ma unità ottimizzata per l'elaborazione di vettori di lunghezza variabile che per avere le massime prestazioni non richiede riscrittura o ricompilazione del codice per adattarsi a differenti dimensioni dei registri "interni" come invece succede con le SIMD ( e con la possibilità di cambiare l'ampiezza dei registri e dei datapath come più torna comodo).

Rimane un'unità SIMD come modello, tant'è che, una volta fissata la lunghezza dell'implementazione, poi elabora comunque istruzioni di tipo SIMD o "scalari" (per i registri di predizioni, e roba associata).

Come modello architetturale e modello di programmazione è tutto un altro paio di maniche rispetto ad AVX-512.

O per dirla in un altro modo sarebbe come avere un unico set d'istruzioni
AVX identico per AVX, AVX-512, AVX-768,.., AVX-1024,...,AVX-2048
e con codice ottimizzato esclusivamente per AVX-2048 che gira senza ricompilare e senza degrado di prestazioni (rispetto alla specifica cpu) su un implementazione "solo" AVX.
Questo perche si ragiona, si codifica e si ottimizza il codice SVE in termini di VETTORI (con lunghezza generica), non in termini di registri "multimediali" di lunghezza fissa.

In realtà se avessi visto come funziona Larrabee/Xeon Phi (KNI come ISA)/AVX-512, il funzionamento di SVE è molto simile al codice di "epilogo" di un loop.

Con le ISA SIMD tradizionali, sei costretto a generare una sequenza di istruzioni che manipolano i dati rimanenti da elaborare, e questo ha un certo costo.

Con AVX-512 ti basta caricare l'opportuno di registro di maschera marcando su quali elementi lavorare, e poi esegui esattamente le stesse istruzioni che hai usato nel loop principale, ovviamente usando l'apposita maschera per lavorare esclusivamente sulle "lane" interessate.

Se vedi SVE, fa esattamente la stessa cosa di quest'ultimo caso, con la differenza che applica a livello generale il concetto di lavorare su un certo insieme di lane. La differenza è che all'inizio i registri di predizione saranno sempre pieni, e dunque lavoreranno su tutti i dati.
Mentre nell'ultima iterazione del ciclo i registri di predizione saranno "automaticamente" (nel senso che ci pensa il codice, scritto in maniera opportuna, a farlo proprio durante la normale esecuzione del ciclo), a riempirli opportunamente con le lane da usare in questo specifico caso.

La mappatura (parziale) sui NEON serve per semplificare l'interscambio dati sui registri interni senza dover aggiungere istruzioni ad hoc e per rendere ancora più compatta l'implementazione minima ( SVE-128 ).

Serve a risparmiare sull'implementazione, non a semplificare l'interscambio coi registri interni. D'altra parte se usi SVE non puoi usare NEON (questo non l'ho letto, ma da come funziona immagino che sia così).

E, ripeto, il fatto che SVE sia vector-lenght agnostic cambia totalmente le carte in tavola rispetto ad un architettura SIMD, specialmente sul lato software.

Questo senz'altro, ed è una gran comodità dover scrivere il codice una volta sola, e lasciare che se lo smazzi poi l'implementazione.

Ma non sono tutte rose e fiori. Se hai visto gli esempi, proprio a causa dell'utilizzo dei registri di predizione per selezionare su quali dati lavorare, si crea una forte dipendenza fra le istruzioni, e inoltre ci sono diverse istruzioni "scalari" da eseguire.

Dunque in ottica di scalabilità / esecuzione parallela di più istruzioni SVE, questo può rappresentare un problema, anche con architetture out-of-order.

Cosa che con un'architettura che utilizza registri SIMD a dimensione fissa, è di gran lunga meno impattante.

Se hai lavorato con unità SIMD, dovresti cogliere la differenza fra i due approcci, coi loro pro e contro.

In ogni caso se ti studi bene il documento che mi hai passato, te ne renderai conto tu stesso, analizzando anche gli esempi che sono stati forniti, che sono utili a capire come funziona il tutto con casi concreti (ci sono pure implementazioni di strcpy e strcmp).

[cdimauro]

Originariamente inviato da NvidiaMen

Quoto in toto circa la poca utilità ad oggi in ambito videoludico delle SMT. Circa le ottimizzazioni ad hoc credo che Intel con le attuali architetture sia circa al 90%, ed AMD solo nei prossimi mesi potrà avvalersi di un tale vantaggio.

Riguardo alle quote di mercato, sicuramente. Quanto ciò si rifletta nelle specifiche ottimizzazioni, è tutto da vedere. E di fatti i problemi con l'SMT le hanno pure le CPU Intel, per l'appunto, che sono le più diffuse in assoluto, come già detto.

Personalmente e da programmatore posso capire che si possa compilare un'applicazione con un compilatore Intel (che a default ottimizza al meglio per ALCUNE delle sue micro-architetture), oppure usando un altro compilatore ma generando codice più ottimizzato per le micro-architetture più utilizzate.

Ma a parte questo, dubito che gli sviluppatori perdano tempo con ottimizzazioni IN CODICE appositamente per Intel.

E tu stai rimanendo sempre ancorato alla situazione attuale che è davvero "poco auspicabile" per un appassionato di tecnologia come sembri essere te. Fosse per te ed il tuo ragionamento quasi quasi il mondo videoludico si dovrebbe fermare vita natural durante sui quad core e spingere quest'ultimi magari su frequenze irraggiungibili al silicio.

Non ho mai detto questo e, al contrario, ho già detto che col tempo ci saranno sempre più giochi ottimizzati per sfruttare più core. Cosa che ho scritto sia qui sia nel thread Aspettando Zen.

La legge di Moore secondo la quale il numero di transistori per chip, raddoppi ogni 18 mesi ha necessità del multicore affinché possa avere un senso da un punto di vista prestazionale e, volenti o nolenti, anche il software dovrà seguire questa strada. Ricorda che nella vita ed in ogni ambito tutto è difficile solo per chi non ci crede. Mi chiedo un po', ma la pensavi anche così all'epoca dei single core, dei dual core e dei quad core prima della loro introduzione?

Da programmatore conosco i benefici nell'avere più core e/o thread hardware a disposizione, e se capita ne faccio anche uso.

Ad esempio, prima di lasciare Intel ho scritto apposito codice che scala in base al numero di core, per alcuni calcoli intensivi (checksum di file). E visto che Python (che ho usato) è intrinsecamente mono-core/thread, ho dovuto lavorare un po' per implementare il tutto. A dimostrazione che non è che la manna scenda dal cielo in questi casi.

Il codice può assolutamente essere parallelizzato anche lato CPU, questo non è un punto di vista ma un dato di fatto in quanto TUTTI gli algoritmi di renderizzazione in ray-tracing lavorano esclusivamente in multithreading sui cores attraverso algoritmi software (vedi il predetto Vray utilizzato anche nel tuo odiato Cinebench).

Ma guarda che ho detto esattamente la stessa cosa, eh!

Mi riquoto: "Stai rimanendo sempre in ambito grafico, dove è naturale parallelizzare & distribuire i carichi di lavoro. ".

Semmai quest'oggi è vero il contrario: pur disponendo di GPU con elevata prestazione computazionale il codice per sfruttarle via hardware in tale ambito non è a livello di quello utilizzato per il processamento via software mediante CPU. Questo perché stiamo continuando a "perder tempo" in ambito gaming con affinamenti sulla tecnica di rasterizzazione, ambito nel quale girano e si investono un sacco di soldi. Ma quando questi affinamenti grafici non troveranno più ulteriori migliorie apprezzabili dagli utenti si dovrà OBBLIGATORIAMENTE passare oltre.

Il futuro è rappresentato dal ray tracing, che consentirà di rimuovere queste problematiche, consentendo un'enorme scalabilità.

Ancora qualche anno, e ci arriveremo.

L'emulazione è proprio un discorso che nulla ha a che vedere con la parallelizzazione del codice perché porta un livello di complessità ben diversa e con problematiche molto più delicate e per la quale son pochissime le risorse che si destinano in ambito di sviluppo software. Per tali ambiti si utilizzano più "semplicemente" le virtualizzazioni via hardware che fanno vedere un insieme di risorse (cores) come un'unica unità elaborativa e con risultati molto soddisfacenti rispetto alla originaria macchina emulata.

Se hai bisogno di eseguire un emulatore, non te ne fai nulla di poter lanciare più istanze dello stesso, assegnandole a core diversi.

Prendi uno che vuole lanciare Dolphin, PCSX2, MAME, WinUAE, ecc.: non è che lancia n istanze di questi emulatori. Ne viene eseguito uno, e l'utente userà quella sola istanza.

E in questi casi, come già detto, non c'è parallellizzazione che tenga: quando devi emulare UN processore della piattaforma emulata, potrai sempre e soltanto sfruttare un solo core/thread hardware.

Non si scappa. E' così perché il codice è intrinsecamente "seriale" / non parallellizzabile, e la situazione non è affatto destinata a cambiare anche fra diversi, e con migliaia di core a disposizione: è questo codice che è così.

Chiunque abbia esperienza in merito te lo potrà confermare.

E idem per diverse altre tipologie di software "seriale".

Nei precedenti 15 anni è stato possibile migliorare le prestazioni dei processori a livello architetturale nel rispetto della Legge di Moore senza affidarsi al multithreading che è rimasto relegato esclusivamente in ambiti specifici della ricerca e per algoritmi progettati ad hoc per i quali era richiesta una elevata capacità computazionale.
Ti assicuro che le case software più che i budget da rispettare devono in primis rispettare le scadenze annuali di immissione sul mercato dei loro prodotti. Ecco il perché ci si ritrova con giochi pieni di bug all'uscita che poi vengono risolti strada facendo. I soldi sono l'ultimo dei problemi in quanto a fine 2016 l'intera industria di gaming ed entrainment mondiale ha raggiunto la stratosferica cifra di 91 Miliardi di dollari ed è in continua ascesa visto l'interesse che si allarga sempre più a macchia d'olio tra i consumatori, praticamente più del fatturato dell'industria cinematografica e musicale mondiali messe insieme tanto per dare un'idea. Parallelamente ad esse (Ubisoft, EA, Activision, ecc.), che nello sviluppo di nuove tecnologie software entrano solo parzialmente occupandosi di mero "assemblaggio" di codice destinando le loro risorse alla realizzazione dei prodotti, operano altre software houses che si dedicano esclusivamente ai motori di fisica, di render, di IA con il fine ultimo di sfruttare sempre più, con algoritmi proprietari ed API, le ultime tecnologie hardware di nuova e prossima introduzione. Sta solo a noi consumatori promuovere attraverso acquisti intelligenti di prodotti con maggior potenziale di crescita al fine di farli diffondere maggiormente e giustificare gli sforzi da destinare a chi opera nel settore. I margini ed il profitto in ambito videoludico si fanno su larga scala ed occorre favorire una diffusione più capillare per contribuire come consumatori che fanno il loro interesse in tutto questo processo.

E questo succede già, ma non è sufficiente, visto che per realizzare un gioco AAA a volte servono più soldi che per realizzare un film AAA.

I costi sono elevatissimi in assoluto, per cui ci sarà sempre da tagliare nelle ottimizzazioni per arrivare prima possibile nel mercato, e recuperare gli investimenti.

Sì, i consumatori possono cercar di dirigere, ma fino a un certo punto.

Spero sia stato chiaro e non oggetto di un tuo ulteriore quote che vada a rispondere con altro pur di rispondere.

Io rispondo perché programmo da 35 anni, e nella mia vita ho sviluppato di tutto: dal bassissimo livello (anche videogiochi. Per Amiga) fino all'altissimo livello. Da codice seriale a parallelo.

E casualmente sono anche appassionato di architetture, micro-architetture, ed emulatori.

Dunque riporto la mia esperienza e la mia visione. Da professionista.

[cdimauro]

Originariamente inviato da george_p

Ma non penso ci sia solo l'SMT in una architettura complessa come quelle intel e amd, no?

No, ma vedi sopra il mio precedente commento.

Non sono io a scrivere questo che riporto ma tante persone che studiano o lavorano nel settore programmazione.

Hai qualche link in merito?

Lato silicio non ho detto che il 14 nm glofo sia immaturo, ovvio deve esserlo abbastanza maturo per aver permesso questi risultati per frequenze e consumi con gli octacore amd che ricordiamo hanno circa 5 miliardi di transistor. Ma penso anche ci sia un ulteriore margine di miglioramento del prodotto nei prossimi mesi... come è accaduto per il 14 nm di intel.
non sarà mica come il 32 nm sempre glofo precedente? Quello non aveva permesso nessun miglioramento o quasi da subito, vedi differenza tra i sample e le cpu BD al loro debutto, e la differenza nel caso di Zen.

Beh, GF potrebbe anche tirare fuori un affinamento dei 14nm, come ha fatto Intel col 14+nm, anche se lo vedo meno plausibile.

Originariamente inviato da Vul

Interessantissima recensione per chi si preoccupa di Ryzen e il gaming:

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

Riassumendo:
-gli fps medi sono molto più simili fra R7 ed i7 quando si gioca davvero che nei benchmark
-R7 offre molto meno stuttering registrando, usando shadowplay, ecc
-R7 quadruplica a volte le prestazioni di un 7700k in ambito produttività, nel migliore dei casi un i7 distacca un r7 di 10 punti percentuali solo su giochi abbastanza male ottimizzati
-AMD collabora con una valanga di produttori di giochi (che hanno già ufficializzato ottimizzazioni pro Ryzen), Intel non può vantare la stessa cosa
-AM4 è destinato a durare 3-4 generazioni di cpu, con Intel si cambia tutto in continuazione
-il futuro è verso un numero di core/thread superiore

Son tutte cose di cui s'è già discusso, incluso l'annuncio di AMD di lavorare con gli sviluppatori per cercare di sfruttare meglio le sue nuove micro-architetture.

Come / cosa / quando è, però, tutto un altro paio di maniche.

Come ho già scritto, aspettiamo...

Originariamente inviato da george_p

Questo è già stato fatto notare da quasi subito ma si preferisce far pesare i grafici che "congelano" il numero dei frames in un dato intervallo di tempo senza alla fine considerare la realtà del gioco.
Ah si, vero avevo già letto di ottimizzazioni per Ryzen da parte delle software house peraltro annunciate da amd stessa, in "contraddizione" con quello che si scrive qui per certi versi dove non sembrano esistere queste ottimizzazioni per videogames.

Vedi sopra anche tu.

Buondì a tutti.

[street]

Originariamente inviato da NvidiaMen

E tu stai rimanendo sempre ancorato alla situazione attuale che è davvero "poco auspicabile" per un appassionato di tecnologia come sembri essere te. Fosse per te ed il tuo ragionamento quasi quasi il mondo videoludico si dovrebbe fermare vita natural durante sui quad core e spingere quest'ultimi magari su frequenze irraggiungibili al silicio.

Guarda, mi sa che nel rispondere a lui ignori (credo tu sia uno dei pochi, per questo ti avverto) che é un ex-ingegnere intel, da poco passato ad altra azienda.
Sicuramente competenza tecnica la ha nel suo campo, ma quando lo leggi é inevitabile fare la tara al discorso considerando questo fatto.
Come lo sarà in futuro se discuteremo su come alfa possa tirar fuori un'auto migliore rispetto a bmw...

[george_p]

Originariamente inviato da cdimauro

Son tutte cose di cui s'è già discusso, incluso l'annuncio di AMD di lavorare con gli sviluppatori per cercare di sfruttare meglio le sue nuove micro-architetture.

Come / cosa / quando è, però, tutto un altro paio di maniche.

Il link a un post di risposta a una mia domanda (il post subito precedente) se è possibile ottimizzare una cpu intel o amd per i videogiochi.
http://www.bitsandchips.it/forum/vie...p=97460#p97460

E ok, ma io parlo di possibilità ossia che ciò sia possibile non di tempo, il tempo sappiamo che non è di due giorni.

[bjt2]

https://twitter.com/mustmann/status/842240026486439937

Il freeze con codice FMA3 scompare disabilitando l'SMT. In arrivo aggiornamento microcodice...

[leoneazzurro]

Originariamente inviato da cdimauro

Sì, ma mettiti nei panni dell'utente che dovrà comprare le memorie per Ryzen.

Se i giochi sono realizzati dalla stessa "mano", potrebbe essere. Ma, per questo motivo, dubito che ce ne siano tanti nella stessa condizione.

Anche Intel guadagna nei giochi usando memorie più veloci, e grossomodo in percentuali simili. Che facciamo, ci mettiamo nei panni di chi deve comprare le memorie per Intel?
No, non serve che i giochi siano realizzati dalla stessa mano, basta che riconoscano erroneamente la topologia della CPU.

[k0nt3]

Originariamente inviato da MiKeLezZ

Perché l'ha detto in un'intervista Jim Anderson (Senior Vice President and General Manager, Computing and Graphics Business Group, AMD), dichiarando che gli R5 avranno un range di prezzo dai 199$ ai 299$. E il top range R5 è appunto il 1600X.

Il tempo è galantuomo

[NvidiaMen]

Originariamente inviato da cdimauro

Io rispondo perché programmo da 35 anni, e nella mia vita ho sviluppato di tutto: dal bassissimo livello (anche videogiochi. Per Amiga) fino all'altissimo livello. Da codice seriale a parallelo.

E casualmente sono anche appassionato di architetture, micro-architetture, ed emulatori.

Dunque riporto la mia esperienza e la mia visione. Da professionista.

Finalmente dopo tanti batti e ribatti sono stato premiato da te con risposte coerenti che per la maggiore mi trovano d'accordo. Solo una cosa tengo a sottolineare, che si sia filoIntel o filoAMD, iniziamo al più presto ad abbandonare le piattaforme quadcore nei prossimi upgrade. I consumatori ed i prodotti che sono i più diffusi la fanno sempre da padrone in tutti i settori del mercato, quindi per chi può è opportuno consigliare prodotti con maggiori margini di sviluppo per il futuro per rendere quest'ultimo (il futuro) il più prossimo possibile e non fare inavvertitamente il gioco di chi vende sempre lo stesso prodotto differenziandolo dal precedente per qualche spicciolo di fps in più.
Ciao e grazie del costruttivo confronto.

[phicrand_6358]

Originariamente inviato da leoneazzurro

cut

OT: sono tornato da poco qua, ma da quand'è che non sei più moderatore? per curiosità...

[NvidiaMen]

Originariamente inviato da street

Guarda, mi sa che nel rispondere a lui ignori (credo tu sia uno dei pochi, per questo ti avverto) che é un ex-ingegnere intel, da poco passato ad altra azienda.
Sicuramente competenza tecnica la ha nel suo campo, ma quando lo leggi é inevitabile fare la tara al discorso considerando questo fatto.
Come lo sarà in futuro se discuteremo su come alfa possa tirar fuori un'auto migliore rispetto a bmw...

Grazie per la dritta, non lo sapevo. In ogni caso io sono dell'avviso che una persona davvero professionale debba esser imparziale quando si discute di fatti oggettivi che possono sol far bene allo sviluppo informatico e che nulla hanno a che vedere con il parlar bene o male di questo o quel produttore. Io mi trovo da almeno cinque generazioni ad acquistare CPU Intel, dopo un lungo passato in cui mi sono affidato ad AMD, ma continuo sempre ad apprezzare molto gli sforzi di AMD che nel suo piccolo riesce sempre a dimostrare la bontà dei propri prodotti ad un prezzo molto più accessibile della concorrenza sia in capo CPU che GPU. Con Ryzen occorre oggettivamente ammettere che si è superata dimostrando che si possono realizzare CPU multicore più prestazionali ed al contempo più accessibili dal punto di vista economico, quasi AMD stessa volesse segnare una strada nuova da seguire. Sta a noi cogliere questo input e dare ragione una volta per tutte a questo nuovo modo di stimolare il mercato. In questo modo anche Intel si adeguerà con la sua serie 6xx0, non tanto dal punto di vista prestazionale, ma soprattutto dal punto di vista del costo d'acquisto dove con Ryzen ha davvero subito un grosso colpo dal suo maggiore competitor. Il mio contributo a questa causa non verrà a mancare in quanto il mio prossimo upgrade, previsto per fine anno sarà basato su un 1800x o superiore se ci sarà.

[street]

Originariamente inviato da NvidiaMen

Grazie per la dritta, non lo sapevo. In ogni caso io sono dell'avviso che una persona davvero professionale debba esser imparziale quando si discute di fatti oggettivi che possono sol far bene allo sviluppo informatico e che nulla hanno a che vedere con il parlar bene o male di questo o quel produttore.

da esterno, si, sono d'accordo.
Ma per me un dipendente può essere al 100% imparziale (in pubblico) solo se non ci mette passione in quel che fa.

[LMCH]

Originariamente inviato da cdimauro

Dubito che assisteremo a implementazioni così spinte, per i problemi di clock skew di cui abbiamo già parlato.

Questo perche continui a ragionare in termini di
"è un unità SIMD con relative estensioni del set d'istruzioni".

Mentre invece a livello di progettazione del set d'istruzioni è un estensione per vector processing generico senza vincoli troppo stretti su COME E DOVE va implementata.

Un vettore è un gruppo di word di una certa dimensione, non necessariamente un unico super-registro.

SVE è pensata per essere implementata in modo semplice ed economico ANCHE come unità SIMD "nel core" ed ovviamente per interoperare agilmente con il set d'istruzioni "standard" (da cui la sovrapposizione dei primi 128bit dei registri Z di SVE con i registri NEON a livello di logica di programmazione), ma non è l'unica implementazione possibile.

E non è un caso che nel documento che avevo linkato dicano esplicitamente
"SVE is not an extension of NEON, but a new set of vector instructions developed to target HPC workloads".

Ad esempio un implementazione a 2048bit in realtà potrebbe generare microOp o macroOp per 16 shadow register a 128bit da/verso fino a 16 unita funzionali e/o accumulando le operazioni nel reorder buffer del core o di un unita di esecuzione separata con datapath separati verso le cache e/o condivisa tra più core.

Immagina ad esempio un core ARM 4-way SMT in cui ogni thread ha un SVE "virtuale"
che in realtà è implementato come 16 unità NEON condivise tra i 4 thread;
dove quindi quando tutti e 4 i thread eseguono istruzioni SVE hanno le prestazioni di un SVE-512 ma quando solo uno di essi sta usando SVE e gli altri operano su interi è come se questo avesse un unità SVE-2048 tutta per se.

Notare che l'unico "aggravio" sarebbe che i registri P dei predicati dovrebbero essere a 128bit ma non si supererebbe il caso peggiore di problemi di clock skew che si avrebbe implementando dei "semplici" core con set d'istruzioni ARMv8 e come detto prima nel caso "peggiore" in cui tutti i thread usano SVE simultaneamene si avrebbero "solo" le prestazioni di un implementazione SVE-512 (oppure SVE-1536 con un thread che usa SVE e gli altri che usano "solo" le NEON).

A parte questo, non mi stupirei se in futuro spuntassero fuori GPU
basate su ARMv8+SVE a gestire le parti più "computazionalmente flessibili"
o anche SoC multicore ottimizzati per il signal processing e cose simili con implementazioni di SVE che dominano sul resto del core ARM vero e proprio.

[cdimauro]

Guarda che siamo sostanzialmente d'accordo su tutto.

Lo so che si può fare "cracking" delle istruzioni, e suddividerle in più micro-op, se le unità SVE sono più piccole della dimensione massima esposta dall'ISA. E' proprio quello che ha fatto Intel quando ha introdotto le SSE (128 bit) col Pentium 3 (unità a 64 bit), ed è quello che ha fatto AMD con Ryzen (unità a 128 bit) per le AVX/-2 (256 bit). Nulla di nuovo qui, e ovviamente i benefici sono quelli che hai esposto (ma ci sono anche i risvolti negativi).

Preciso pure che non ho mai detto che SVE sia un'estensione di NEON. Al contrario, se ho affermato questo:

"se usi SVE non puoi usare NEON"

è proprio per confermare il contrario. IMO se usi SVE non puoi usare NEON, e viceversa, proprio perché sono due cose diverse, anche se condividono il banco di registri vettoriali.

Mentre, come penso saprai, puoi far eseguire codice SSE, AVX, e AVX-512 assieme, perché condividono tutte le risorse SIMD.

L'unico appunto è che non vedo assolutamente SVE come un coprocessore. Anche nello scenario che hai esposto, con SMT4 (ma potrebbe anche essere SMT8 o addirittura SMT16 se si volessero utilizzare unità a 128 bit), rimarrebbero comunque delle normali unità d'esecuzione.

E giusto per essere chiari, per coprocessore intendo un dispositivo esterno al core, come oggi è l'iGPU. Questo proprio per come funziona SVE.

Spero che ci siamo finalmente chiariti.