Broadwell e Skylake: le future CPU Intel per il 2015

[cdimauro]

Originariamente inviato da Mparlav

Non sono così convinto che non ci possano essere più rivoluzioni sull'IPC da parte d'Intel

Non solo di Intel, visto che anche la concorrenza non è messa male con le proprie microarchitetture.

Diciamo pure che non c'è una spinta in tal senso (ma resta forte in campo gpu, soprattutto sui notebook), piuttosto è meno dispendioso aumentare le SIMD, aumentare i core (ma solo in fascia enterprise o ws di fascia alta), aumentare la quantità e l'architettura della cache, che danno benefici più immediati.
Tanto più quando c'è di mezzo il die shrink.

Esattamente, perché fare interventi "miracolosi" nel resto del sistema è alquanto improbabile. Basti disassemblare un po' di codice delle applicazioni per comprendere quanto intricata possa essere la foresta di istruzioni che si susseguono durante l'esecuzione, con le numerose dipendenze fra di essere che si vanno formando, e le esecuzioni condizionate (salti).

L'esecuzione out-of-order ha dato una gran mano per cercare di sfruttare il più possibile le unità di calcolo a disposizione, mantenendo in sospeso le istruzioni in attesa a causa delle dipendenze, ma ha praticamente esaurito il suo compito.

Continuare ad aggiungere decoder (per decodificare più istruzioni di quelle che è possibile adesso), unità di calcolo, pipeline, code per mantenere le istruzioni "congelate", ecc. porta ben pochi vantaggi rispetto all'incremento della complessità della circuiteria. E questo, ribadisco, dipende dal fatto che il codice "general purpose" è abbastanza "frastagliato".

Se, per fare un altro esempio totalmente diverso, si va a vedere il disassemblato del codice che fa uso (massiccio) del paradigma SIMD, si può vedere quanto sia molto più semplice e lineare, per cui aumentare il numero di unità d'esecuzione SIMD porta a un notevole incremento delle prestazioni.

Lo stesso dicasi quando si aggiungono core a un chip, nel caso in cui si eseguano applicazioni che si prestano alla distribuzione del carico di lavoro, oppure se è possibile eseguire più applicazioni, anche eterogenee, che impegnano per bene i core a disposizione.

Ma, ribadisco, non ci sono ricette miracolose per aumentare le prestazioni su singolo core/thread. Siamo arrivati sostanzialmente al capolinea.

Se qualcuno le conoscesse, posso assicurare che farebbe soldi a palate. Ma dopo più di 3 decadi che studio e lavoro con le architetture dei calcolatori, la mia esperienza mi fa intuire che ciò non sarà possibile.

Felice di essere smentito. Vuol dire che avrò ancora altro da imparare (che non guasta mai: fossilizzarsi per un informatico è deleterio).

[MiKeLezZ]

Originariamente inviato da Catens

penso che con skylake forse si inizia a vedre un passo piu avanti a livello di performance visto che cambia di molto la progettazione e con le ddr4 un po di incremento ci sarà. Broadwell sarà poco diverso dal Devil's Canyon attuale anche se sarà a 14 nm.

Le DDR4 sono il solito capriccio commerciale per costringere al cambio di motherboard. La banda ne avevamo già a sufficienza con le DDR3, con le DDR4 ce ne avanza.

Originariamente inviato da Mparlav

Non sono così convinto che non ci possano essere più rivoluzioni sull'IPC da parte d'Intel
Diciamo pure che non c'è una spinta in tal senso (ma resta forte in campo gpu, soprattutto sui notebook), piuttosto è meno dispendioso aumentare le SIMD, aumentare i core (ma solo in fascia enterprise o ws di fascia alta), aumentare la quantità e l'architettura della cache, che danno benefici più immediati.
Tanto più quando c'è di mezzo il die shrink.

Non vedo come possano migliorare l'IPC.
Quello che possono fare è aumentare le istruzioni speciali per avvantaggiarsi in ambiti specifici, infatti è quello che stanno facendo (e con l'evoluzione tecnologica continueranno a fare, in ottica di crittografia, decoding, etc)... ma per usarle serve anche un codice specifico.
Possono aumentare la cache, ma oltre a una certa percentuale non serve a nulla (e ci sono praticamente arrivati, infatti lo spazio per aumentarla ce l'avrebbero anche, ma invece l'hanno diminuita).
Aggiungere core non serve a nulla perché come si è visto già 4 si fatica ad usarli (e sono tutti un inutile dispendio in idle).
Per migliorare l'IPC dovrebbero cambiare architettura, ma un'architettura diversa dal x86 e più ottimizzata ce l'abbiamo già: ARM.
Intel ha venduto la sua share nel ARM (XSCALE) proprio perché scelse di spingere solo sul x86, quindi non aspettiamoci cambi di rotta.
Aumenti di frequenza non ne parliamo, già hanno messo il turbo boost.
L'unica cosa è che potrebbero ridurre la latenza nell'esecuzione di alcune operazioni fondamentali, diminuire i miss e i flush... ma sono tutte cose che poi rientrano nell'ormai tipico 5% di miglioramento di generazione in generazione.
La strada della GPU integrata non solo è quella vincente, ma è anche l'unica al momento veramente percorribile.
Come nella visione di AMD, CPU+GPU che possono accedere agli stessi spazi di memoria e che condividono una gigantesca L4... una enorme potenza elaborativa in floating point! E' solo questione di un paio di iterazioni ancora!

[cdimauro]

Originariamente inviato da MiKeLezZ

Le DDR4 sono il solito capriccio commerciale per costringere al cambio di motherboard. La banda ne avevamo già a sufficienza con le DDR3, con le DDR4 ce ne avanza.

Ma anche no, perché:
- le unità SIMD sempre più potenti sono castrate dalla banda verso la memoria;
- le CPU integrano da tempo una GPU che è affamatissima di banda.

Ben vengano le DDR4, quindi, che tra l'altro portano anche a una riduzione dei consumi che, di questi tempi, è molto importante.

Non vedo come possano migliorare l'IPC.
Quello che possono fare è aumentare le istruzioni speciali per avvantaggiarsi in ambiti specifici, infatti è quello che stanno facendo (e con l'evoluzione tecnologica continueranno a fare, in ottica di crittografia, decoding, etc)... ma per usarle serve anche un codice specifico.
Possono aumentare la cache, ma oltre a una certa percentuale non serve a nulla (e ci sono praticamente arrivati, infatti lo spazio per aumentarla ce l'avrebbero anche, ma invece l'hanno diminuita).

Le cache non sono tutte uguali. Se la nuova cache è più efficiente/veloce di quella che va a sostituire, la si può diminuire pur ottenendo prestazioni simili o addirittura migliori.

Aggiungere core non serve a nulla perché come si è visto già 4 si fatica ad usarli (e sono tutti un inutile dispendio in idle).

Vero, ma dipende da quello che ci fai. In ambito consumer non si usano tanti core, per cui 4 sono già un'enormità, ma almeno 2 sono necessari per distribuire i processi/thread e garantire un'esperienza più fluida.

Per migliorare l'IPC dovrebbero cambiare architettura, ma un'architettura diversa dal x86 e più ottimizzata ce l'abbiamo già: ARM.
Intel ha venduto la sua share nel ARM (XSCALE) proprio perché scelse di spingere solo sul x86, quindi non aspettiamoci cambi di rotta.

E non ci saranno perché, al contrario di quello che dici, non ne ha proprio bisogno: ha già un'architettura notevolmente efficiente, anche più di quelle ARM. Sono gli altri che devono rincorrere Intel, e presentare microarchitetture sempre più spinte, con un gran numero di decoder, unità d'esecuzione, e unità di retire.

A parità di numero di pipeline & paradigma (in-order o out-of-order), l'architettura x86 in generale s'è dimostrata sempre più efficiente rispetto alle altre.

Aumenti di frequenza non ne parliamo, già hanno messo il turbo boost.

Le frequenze sono limitate perché non si può fare a cazzotti con le leggi della fisica, ed è un problema comune.

Il turbo boost serve a migliorare l'efficienza in ambito single core/thread, che è fondamentale negli scenari più comuni.

L'unica cosa è che potrebbero ridurre la latenza nell'esecuzione di alcune operazioni fondamentali, diminuire i miss e i flush... ma sono tutte cose che poi rientrano nell'ormai tipico 5% di miglioramento di generazione in generazione.

E sono cose che possono fare, e fanno, tutti.

La strada della GPU integrata non solo è quella vincente, ma è anche l'unica al momento veramente percorribile.
Come nella visione di AMD, CPU+GPU che possono accedere agli stessi spazi di memoria e che condividono una gigantesca L4... una enorme potenza elaborativa in floating point! E' solo questione di un paio di iterazioni ancora!

Perdonami, ma vedi sopra: è la strada che, però, richiede più banda verso la memoria.

A parte questo, anche Intel integra da tempo la GPU, e condivide lo spazio d'indirizzamento e la cache L3. Inoltre con OpenCL 2.0 è possibile eliminare le copie durante le operazioni, dunque ci sono ampi margini di miglioramento nell'utilizzo della GPU integrata.

[AceGranger]

Originariamente inviato da MiKeLezZ

La strada della GPU integrata non solo è quella vincente, ma è anche l'unica al momento veramente percorribile.
Come nella visione di AMD, CPU+GPU che possono accedere agli stessi spazi di memoria e che condividono una gigantesca L4... una enorme potenza elaborativa in floating point! E' solo questione di un paio di iterazioni ancora!

nVidia e IBM stanno percorrendo la strada di una nuova interconnessione fra CPU e GPU che è una soluzione di gran lunga migliore al vincolo che ci si ritrova con le APU AMD dove hai una GPU e una CPU che non puoi aggiornare o ampliare e che entrambe non brillano per prestazioni.

La memoria condivisa la si avra ( gia la si ha a livello software con CUDA ) anche con le GPU discrete che pero potranno contare su una potenza nettamente superiore delle integrate; potranno essere veloci quanto vuoi come interconnessioni ma quello che potranno calcolare sara sempre limitato all'integrata e, generalmente, ai software GPGPU serve potenza bruta; il nulla cosmico di HSA dopo quasi 2 anni dalla presentazione dovrebbe far riflettere sulla scarsa quantita di codice che realmente è in grado di trarne beneficio.

mi sembra tutto fuorchè la panacea dei problemi di potenza di AMD; X86 e GPU discrete avranno ancora vita lunga, molto lunga.

[MiKeLezZ]

Originariamente inviato da cdimauro

Ma anche no, perché:
- le unità SIMD sempre più potenti sono castrate dalla banda verso la memoria;
- le CPU integrano da tempo una GPU che è affamatissima di banda.

Ben vengano le DDR4, quindi, che tra l'altro portano anche a una riduzione dei consumi che, di questi tempi, è molto importante.

Ben vengano le riduzioni di consumi e aumenti di frequenze, ma i primi sono semplicemente dovuti ai miglioramenti dei processi produttivi e quindi discesa in nanometria che si traduce in inferiori tensioni operative... Non a caso esistono già le DDR3 low power che sarebbero delle DDR3 a nanometria inferiore che lavorano a tensione inferiore (e quindi consumano meno)... molto simili alle DDR4!
Ovviamente di questa mancanza di flessibilità ai produttori di motherboard e CPU va più che bene, così che possano spingere la vendita di nuovi sistemi piuttosto che l'upgrade dei vecchi.
Ovvero quando saremo ai 10nm e quindi tensioni operative di 0,9V/1V tireranno nuovamente fuori le "nuove" DDR5......
Mentre gli aumenti di frequenza delle RAM puoi constatare tu stesso con i vari benchmark che non sono particolarmente interessanti se non in determinati ambiti (gaming, se si usa la memoria di sistema come memoria per la GPU).

Originariamente inviato da AceGranger

nVidia e IBM stanno percorrendo la strada di una nuova interconnessione fra CPU e GPU che è una soluzione di gran lunga migliore al vincolo che ci si ritrova con le APU AMD dove hai una GPU e una CPU che non puoi aggiornare o ampliare e che entrambe non brillano per prestazioni.

La memoria condivisa la si avra ( gia la si ha a livello software con CUDA ) anche con le GPU discrete che pero potranno contare su una potenza nettamente superiore delle integrate; potranno essere veloci quanto vuoi come interconnessioni ma quello che potranno calcolare sara sempre limitato all'integrata e, generalmente, ai software GPGPU serve potenza bruta; il nulla cosmico di HSA dopo quasi 2 anni dalla presentazione dovrebbe far riflettere sulla scarsa quantita di codice che realmente è in grado di trarne beneficio.

mi sembra tutto fuorchè la panacea dei problemi di potenza di AMD; X86 e GPU discrete avranno ancora vita lunga, molto lunga.

Bhe diciamo che sono abbastanza vecchio (pur non così tanto) da ricordarmi le prime CPU senza il coprocessore matematico, ovvero che non facevano calcoli in virgola mobile in hardware (successivamente integrato all'interno, poi grandemente migliorato, infine affiancato da un set di istruzioni speciali che avvantaggiavano anche altri ambiti) nonché la cache L2 esterna (di "ben" 512kB)... giganteschi moduli che si connettevano tramite "pettine" alla motherboard e che poi comunicavano fra loro tramite FSB... Insomma, tecnologia passata!!
I sistemi attuali sostanzialmente stanno percorrendo lo stesso sviluppo, da gigantesche GPU (ovvero grandi motori di calcoli in virgola mobile) che si connettono esternamente al sistema siamo passati a un'integrazione tramite link veloce a fianco della CPU, poi ancora integrata nello stesso die... stessa cosa la vediamo con la eDRAM/L4 che da esterna diventerà interna!
Insomma da qui ai 10nm, ai 7nm e infine ai 5nm, possibilità di integrazione non mancheranno di certo! Visto anche è uno dei modi più semplici per abbassare i costi di produzione!
Certo, magari farà ancora comodo avere moduli aggiuntivi GPU per aumentare le capacità di floating point (da qui i progetti NVIDIA e IBM), ma considera anche il segmento enterprise, dove servono enormi capacità in floating poit, certamente più semplici da ottenere con GPU adatte allo scopo, che aumentando il numero di core x86 (per quando la loro GPU e capacità in floating possa migliorare).

[cdimauro]

Originariamente inviato da MiKeLezZ

Ben vengano le riduzioni di consumi e aumenti di frequenze, ma i primi sono semplicemente dovuti ai miglioramenti dei processi produttivi e quindi discesa in nanometria che si traduce in inferiori tensioni operative... Non a caso esistono già le DDR3 low power che sarebbero delle DDR3 a nanometria inferiore che lavorano a tensione inferiore (e quindi consumano meno)... molto simili alle DDR4!

Ma a parità di voltaggio, le DDR4 consentono comunque di trasferire più dati, e dunque complessivamente consumano di meno e sono più performanti.

Ovviamente di questa mancanza di flessibilità ai produttori di motherboard e CPU va più che bene, così che possano spingere la vendita di nuovi sistemi piuttosto che l'upgrade dei vecchi.
Ovvero quando saremo ai 10nm e quindi tensioni operative di 0,9V/1V tireranno nuovamente fuori le "nuove" DDR5......

Mi pare anche giusto e sensato. Se scendi troppo con le tensioni operative devi comunque cambiare scheda madre, processore, e memorie, perché quelli attuali non sono in grado di funzionare con tensioni che si discostano troppo da quelle in grado di sostenere. A quel punto introduci anche una nuova tipologia di memoria che aumenta il numero di dati trasferiti.

Mentre gli aumenti di frequenza delle RAM puoi constatare tu stesso con i vari benchmark che non sono particolarmente interessanti se non in determinati ambiti (gaming, se si usa la memoria di sistema come memoria per la GPU).

Si diceva lo stesso quando c'erano le SDR e arrivarono le DDR. Poi per le DDR2, le 3, e adesso con le 4.

E' chiaro che te ne fai poco con un uso normale / leggero, ma nel momento in cui devi fare delle operazioni più pesanti, poi? Con le vecchie memorie ti metti ad aspettare e basta (perché non hai alternative), mentre con le nuove hai per lo meno la possibilità di sfruttarle e ottenere i risultati più velocemente o migliorare l'esperienza utente.

Bhe diciamo che sono abbastanza vecchio (pur non così tanto) da ricordarmi le prime CPU senza il coprocessore matematico, ovvero che non facevano calcoli in virgola mobile in hardware (successivamente integrato all'interno, poi grandemente migliorato, infine affiancato da un set di istruzioni speciali che avvantaggiavano anche altri ambiti) nonché la cache L2 esterna (di "ben" 512kB)... giganteschi moduli che si connettevano tramite "pettine" alla motherboard e che poi comunicavano fra loro tramite FSB... Insomma, tecnologia passata!!
I sistemi attuali sostanzialmente stanno percorrendo lo stesso sviluppo, da gigantesche GPU (ovvero grandi motori di calcoli in virgola mobile) che si connettono esternamente al sistema siamo passati a un'integrazione tramite link veloce a fianco della CPU, poi ancora integrata nello stesso die... stessa cosa la vediamo con la eDRAM/L4 che da esterna diventerà interna!
Insomma da qui ai 10nm, ai 7nm e infine ai 5nm, possibilità di integrazione non mancheranno di certo! Visto anche è uno dei modi più semplici per abbassare i costi di produzione!

Per chi riuscirà ad arrivarci ai 5nm. A parte questo, non puoi comunque integrare nella CPU tutti i core presenti in una GPU discreta, per ovvi motivi. Dunque queste ultime manterranno sempre un certo vantaggio prestazionale.

Certo, magari farà ancora comodo avere moduli aggiuntivi GPU per aumentare le capacità di floating point (da qui i progetti NVIDIA e IBM), ma considera anche il segmento enterprise, dove servono enormi capacità in floating poit, certamente più semplici da ottenere con GPU adatte allo scopo, che aumentando il numero di core x86 (per quando la loro GPU e capacità in floating possa migliorare).

Xeon Phi dimostra il contrario: anche i core x86 sono capaci di macinare numeri competendo con quanto offerto dalle GPU. E lo fanno in maniera molto più semplice e flessibile: bastano poche righe di codice da aggiungere a quello che hai già scritto, per ottenere immediatamente dei risultati.

[MiKeLezZ]

Originariamente inviato da cdimauro

Ma a parità di voltaggio, le DDR4 consentono comunque di trasferire più dati, e dunque complessivamente consumano di meno e sono più performanti.

Questo comunicato stampa te l'ha passata il JEDEC?

Mi pare anche giusto e sensato. Se scendi troppo con le tensioni operative devi comunque cambiare scheda madre, processore, e memorie, perché quelli attuali non sono in grado di funzionare con tensioni che si discostano troppo da quelle in grado di sostenere. A quel punto introduci anche una nuova tipologia di memoria che aumenta il numero di dati trasferiti.

Semmai il problema ce l'hai aumentando le tensioni operative, non diminuendole. Infatti CPU e componentistica varia già lavorano con livelli di tensione variabile a seconda del carico! Implementare un regolatore di tensione che a seconda della scrittura nel SPD (ovvero la nanometria dei chip) regoli la tensione di voltaggio sui giusti valori è banale (e in effetti già accade con le DDR3-LP e i moduli DDR3 overclock).

Si diceva lo stesso quando c'erano le SDR e arrivarono le DDR. Poi per le DDR2, le 3, e adesso con le 4.
E' chiaro che te ne fai poco con un uso normale / leggero, ma nel momento in cui devi fare delle operazioni più pesanti, poi? Con le vecchie memorie ti metti ad aspettare e basta (perché non hai alternative), mentre con le nuove hai per lo meno la possibilità di sfruttarle e ottenere i risultati più velocemente o migliorare l'esperienza utente.

Con le SDR e DDR1 si era un po' in affanno di banda... ma già dalle DDR2 questa non è mai stata un problema e tutte le varie iterazioni ottengono quei immensi GB/s sacrificando cicli di clock in latenza! Le DDR4 che a te e ai non addetti ai lavori sembrano infatti raggiungere velocità astronomiche, lo fanno adottando il solito stratagemma del raddoppio della latenza grazie al raddoppio del moltiplicatore. Come hai detto te, c'è un limite fisico nelle frequenze, è come una coperta che se tiri da una parte si scopre l'altra!
Le DDR3 da 1600MHz hanno infatti un base clock di 200MHz (che si moltiplica per 2, il double rate e per 4, il moltiplicatore), lo stesso delle DDR2 da 800MHz e lo stesso che avranno delle ipotetiche DDR4 da 3200MHz (ipotetiche in quanto le prime si aspetta viaggeranno addirittura meno)!!!
Anzi bassa latenza o gigantesche frequenze operative? In una GPU anzi la seconda, in quanto bus da 256 bit e risoluzioni da 1080p cominciano a creare precise necessità, ma un comune sistema non processa tutti quei GB di informazioni e quando si hanno a disposizione quei (200x2x4x128)/8 = 25,6 GB/s direi che se ne ha ampiamente a sufficienza... e diventa invece, paradossalmente, più utile una minore latenza! Così come puoi vedere dai test reali:
http://www.anandtech.com/show/6372/m...with-gskill/11
(il risultato di winrar è teorico, usano il benchmark interno)

Xeon Phi dimostra il contrario: anche i core x86 sono capaci di macinare numeri competendo con quanto offerto dalle GPU. E lo fanno in maniera molto più semplice e flessibile: bastano poche righe di codice da aggiungere a quello che hai già scritto, per ottenere immediatamente dei risultati.

Vedo che finalmente il prototipo di Larrabee ha visto la luce... non ero aggiornato... ma parliamo di x86 fortemente modificati (i primi progetti utilizzavano infatti VLIW!)... 2.000 euro di costo per produrre 1TFDP, lo stesso di una HD8970 a singolo chip! Direi ben lungi dall'essere un successo!

[cdimauro]

Originariamente inviato da MiKeLezZ

Questo comunicato stampa te l'ha passata il JEDEC?

Il buon senso.

Semmai il problema ce l'hai aumentando le tensioni operative, non diminuendole. Infatti CPU e componentistica varia già lavorano con livelli di tensione variabile a seconda del carico! Implementare un regolatore di tensione che a seconda della scrittura nel SPD (ovvero la nanometria dei chip)

L'SPD contiene le impostazioni della memoria; in particolare i timing. Non la nanometria.

regoli la tensione di voltaggio sui giusti valori è banale (e in effetti già accade con le DDR3-LP e i moduli DDR3 overclock).

Non sono pratico di elettronica, ma non credo che basti un regolatore di tensione per poter ottenere una piattaforma stabile a livelli di voltaggio inferiori a quelli supportati normalmente.

Ma mi fermo qui perché, come ho detto, non mi occupo di elettronica.

Con le SDR e DDR1 si era un po' in affanno di banda... ma già dalle DDR2 questa non è mai stata un problema e tutte le varie iterazioni ottengono quei immensi GB/s sacrificando cicli di clock in latenza! Le DDR4 che a te e ai non addetti ai lavori sembrano infatti raggiungere velocità astronomiche, lo fanno adottando il solito stratagemma del raddoppio della latenza grazie al raddoppio del moltiplicatore. Come hai detto te, c'è un limite fisico nelle frequenze, è come una coperta che se tiri da una parte si scopre l'altra!
Le DDR3 da 1600MHz hanno infatti un base clock di 200MHz (che si moltiplica per 2, il double rate e per 4, il moltiplicatore), lo stesso delle DDR2 da 800MHz e lo stesso che avranno delle ipotetiche DDR4 da 3200MHz (ipotetiche in quanto le prime si aspetta viaggeranno addirittura meno)!!!

Non sono un addetto ai lavori, ma la latenza non raddoppia affatto. Il clock principale, come tu stesso hai detto, rimane lo stesso: 200Mhz. Ergo: l'invio dei comandi alla memoria impiega lo stesso tempo. E' il tempo di trasferimento dei dati che, invece, si dimezza.

Anzi bassa latenza o gigantesche frequenze operative? In una GPU anzi la seconda, in quanto bus da 256 bit e risoluzioni da 1080p cominciano a creare precise necessità, ma un comune sistema non processa tutti quei GB di informazioni e quando si hanno a disposizione quei (200x2x4x128)/8 = 25,6 GB/s direi che se ne ha ampiamente a sufficienza...

Prendiamo un singolo core/thread che gira 2Ghz (dunque un processore molto economico e di fascia bassa), e che è in grado di eseguire un'istruzione AVX2 per ciclo di clock. AVX2 = registri a 256 bit = 32 byte.

Supponiamo di voler effettuare una banale copia di un blocco di memoria usando le AVX2, e dunque di:
- leggere 32 byte dalla memoria (depositandoli in un registro AVX2);
- incrementare il registro puntatore sorgente di 32 byte;
- scrivere 32 byte in memoria (dal registro precedente);
- incrementare il registro puntatore destinazione di 32 byte;
- decrementare il registro contatore del numero di blocchi da 32 byte da trasferire;
- controllare se il registro contatore non è ancora zero (lavoro finito), e in questo caso continuare nuovamente dall'inizio.

Una buona architettura out-of-order è in grado di "spalmare" queste istruzioni in un paio di cicli di clock. Al momento non consideriamo le problematiche di prefetch dei dati dalla memoria, e consideriamo il processore che lavora a regime.

Dunque in 2 cicli di clock trasferiamo 32 byte alla volta. Quindi a 2Ghz trasferiamo 1G x 32 byte = 32GB/s di roba. Poiché stiamo leggendo e scrivendo 32 byte alla volta, la banda richiesta sarà di 32 + 32 = 64GB/s. Anche se raddoppiassimo il numero di cicli di clock per ogni blocco di 32 byte da spostare, servirebbero comunque 32GB/s.

E questa è la possibile (e teorica) richiesta di banda che potrebbe esercitare UN singolo core/thread. Immagina quando ci sono più core e/o thread con le loro rispettive richieste...

e diventa invece, paradossalmente, più utile una minore latenza!

Per la latenza vedi sopra.

Così come puoi vedere dai test reali:
http://www.anandtech.com/show/6372/m...with-gskill/11
(il risultato di winrar è teorico, usano il benchmark interno)

Anche se teorico, è un test che è molto influenzato dalla banda di memoria. Lo stesso avviene per 7-zip, che è pure lui un de/compressore.

Aggiungiamo altri 2 risultati:
http://www.anandtech.com/show/6372/m...-with-gskill/9
http://www.anandtech.com/show/6372/m...with-gskill/12
Batman e Maya presentano notevoli incrementi.

Dunque, e come dicevo, ci sono scenari in cui la banda di memoria fa la differenza.

Vedo che finalmente il prototipo di Larrabee ha visto la luce... non ero aggiornato...

Ehm... no. Larrabee non è mai nato. Xeon Phi è nato dalle sue ceneri, ma è un progetto abbastanza diverso.

ma parliamo di x86 fortemente modificati (i primi progetti utilizzavano infatti VLIW!)...

No anche qui: non hanno mai utilizzato VLIW. Sempre e solo core Pentium modificati e aggiornati con 64-bit e qualche altra cosa.

2.000 euro di costo per produrre 1TFDP, lo stesso di una HD8970 a singolo chip! Direi ben lungi dall'essere un successo!

Stai confrontando schede completamente diverse. Xeon Phi non è una GPU e non opera nel mercato delle schede video. Il suo mercato di riferimento è quello delle schede Tesla di nVidia, dunque high performance computing.

[AceGranger]

Originariamente inviato da MiKeLezZ

2.000 euro di costo per produrre 1TFDP, lo stesso di una HD8970 a singolo chip! Direi ben lungi dall'essere un successo!

guardando quante FirePRO vende AMD nel mercato HPC e nei supercomputer e quante Xeon PHI Intel, direi che l'insuccesso è di AMD .

Originariamente inviato da MiKeLezZ

Bhe diciamo che sono abbastanza vecchio (pur non così tanto) da ricordarmi le prime CPU senza il coprocessore matematico, ovvero che non facevano calcoli in virgola mobile in hardware (successivamente integrato all'interno, poi grandemente migliorato, infine affiancato da un set di istruzioni speciali che avvantaggiavano anche altri ambiti) nonché la cache L2 esterna (di "ben" 512kB)... giganteschi moduli che si connettevano tramite "pettine" alla motherboard e che poi comunicavano fra loro tramite FSB... Insomma, tecnologia passata!!
I sistemi attuali sostanzialmente stanno percorrendo lo stesso sviluppo, da gigantesche GPU (ovvero grandi motori di calcoli in virgola mobile) che si connettono esternamente al sistema siamo passati a un'integrazione tramite link veloce a fianco della CPU, poi ancora integrata nello stesso die... stessa cosa la vediamo con la eDRAM/L4 che da esterna diventerà interna!
Insomma da qui ai 10nm, ai 7nm e infine ai 5nm, possibilità di integrazione non mancheranno di certo! Visto anche è uno dei modi più semplici per abbassare i costi di produzione!
Certo, magari farà ancora comodo avere moduli aggiuntivi GPU per aumentare le capacità di floating point (da qui i progetti NVIDIA e IBM), ma considera anche il segmento enterprise, dove servono enormi capacità in floating poit, certamente più semplici da ottenere con GPU adatte allo scopo, che aumentando il numero di core x86 (per quando la loro GPU e capacità in floating possa migliorare).

è una cosa molto diversa rispetto al passato; l'integrazione della GPU nelle CPU è avvenuto per motivi economici e di consumi, prestazionalmente c'è solo da perderci scendendo a compromessi. Dai su, son 2 anni che di HSA nemmeno l'ombra e nemmeno AMD ha avuto al decenza di presentarlo con gia qualcosa di tangibile da mostrare per il quale valesse la pena averlo, visto che si parla solo di un OpenCL migliorato dall'accesso alal memoria... io vedo solo tanto marketing e stop.

[MiKeLezZ]

Originariamente inviato da cdimauro

L'SPD contiene le impostazioni della memoria; in particolare i timing. Non la nanometria.

Ovvero è da intendersi come oppure (che è infatti la sua prima definizione).
http://dizionari.corriere.it/diziona...O/ovvero.shtml

Non sono pratico di elettronica, ma non credo che basti un regolatore di tensione per poter ottenere una piattaforma stabile a livelli di voltaggio inferiori a quelli supportati normalmente.
Ma mi fermo qui perché, come ho detto, non mi occupo di elettronica.

Se non sei pratico, non commentare, no?

Non sono un addetto ai lavori, ma la latenza non raddoppia affatto. Il clock principale, come tu stesso hai detto, rimane lo stesso: 200Mhz. Ergo: l'invio dei comandi alla memoria impiega lo stesso tempo. E' il tempo di trasferimento dei dati che, invece, si dimezza.

Se le frequenze operative sono le stesse, ovvero 200MHz e da una parte (esempio) si aspettano 4 cicli di clock (Column Access Strobe) prima di recuperare e quindi inviare i dati (DDR2), mentre dall'altra se ne aspettano 8 (DDR3)... Dovrebbe essere facile capire che, in soldoni, è come se la seconda lavorasse a frequenza dimezzata (poi nella realtà è un briciolo più complicato e spesso da iterazione a iterazione si riesce a limare quei valori). E' una coperta.
Poi chiaramente l'evoluzione tecnologica porta a rendere obsoleta l'una e a migliorare l'altra (infatti per le memorie vi è un preciso limite di frequenze operative raggiungibili e si preferisce adottare moltiplicatori più alti e cercare di limare i tempi di accesso, piuttosto che alzare le frequenze di base).

Prendiamo un singolo core/thread che gira 2Ghz (dunque un processore molto economico e di fascia bassa), e che è in grado di eseguire un'istruzione AVX2 per ciclo di clock. AVX2 = registri a 256 bit = 32 byte.

Supponiamo di voler effettuare una banale copia di un blocco di memoria usando le AVX2, e dunque di:
- leggere 32 byte dalla memoria (depositandoli in un registro AVX2);
- incrementare il registro puntatore sorgente di 32 byte;
- scrivere 32 byte in memoria (dal registro precedente);
- incrementare il registro puntatore destinazione di 32 byte;
- decrementare il registro contatore del numero di blocchi da 32 byte da trasferire;
- controllare se il registro contatore non è ancora zero (lavoro finito), e in questo caso continuare nuovamente dall'inizio.

Una buona architettura out-of-order è in grado di "spalmare" queste istruzioni in un paio di cicli di clock. Al momento non consideriamo le problematiche di prefetch dei dati dalla memoria, e consideriamo il processore che lavora a regime.

Dunque in 2 cicli di clock trasferiamo 32 byte alla volta. Quindi a 2Ghz trasferiamo 1G x 32 byte = 32GB/s di roba. Poiché stiamo leggendo e scrivendo 32 byte alla volta, la banda richiesta sarà di 32 + 32 = 64GB/s. Anche se raddoppiassimo il numero di cicli di clock per ogni blocco di 32 byte da spostare, servirebbero comunque 32GB/s.

E questa è la possibile (e teorica) richiesta di banda che potrebbe esercitare UN singolo core/thread. Immagina quando ci sono più core e/o thread con le loro rispettive richieste...

L'instruction stage pipeline è di circa 14, altro che 2... Significa che possiamo anche prendere processori da 3GHz piuttosto che 2GHz (+50%) e con 4 core core piuttosto che 1 (+400%) ed ottenere un valore comunque inferiore al tuo!
E parliamo di un caso teoretico in cui si spostano (senza motivo) blocchi di memoria (presi apposta perché unici ottenibili così facilmente e in grande numero). I test reali sono linkati e sono quelli che contano!

Aggiungiamo altri 2 risultati:
http://www.anandtech.com/show/6372/m...-with-gskill/9

Ti sembra logico uno adotti RAM ultraveloci SOLO per aumentare i FPS della scheda grafica integrata da 14 (ingiocabile) a 15 (ingiocabile)? Suvvia...
E parliamo di velocità della RAM (quasi) RADDOPPIATA cioè banda totale (quasi) RADDOPPIATA...

Dunque, e come dicevo, ci sono scenari in cui la banda di memoria fa la differenza.

Sì, scriviamolo a tutti:
RAGAZZI, SE VOLETE CHE I GIOCHETTI FATTI PARTIRE CON LA GRAFICA INTEGRATA GUADAGNINO 1% DI PRESTAZIONI, COMPRATEVI RAM CHE VADA IL DOPPIO PIU' VELOCE DELLA PRECEDENTE!!!!

No anche qui: non hanno mai utilizzato VLIW. Sempre e solo core Pentium modificati e aggiornati con 64-bit e qualche altra cosa.

Larrabee era VLIW. Poi evidentemente si sono accorti che non funzionava abbastanza bene e hanno cambiato rotta.
http://arstechnica.com/uncategorized/2007/02/8824/
The Processing Engine implements a non-x86, VLIW ISA that uses a 96-bit instruction word containing up to up to 8 ops/cycle.

Stai confrontando schede completamente diverse. Xeon Phi non è una GPU e non opera nel mercato delle schede video. Il suo mercato di riferimento è quello delle schede Tesla di nVidia, dunque high performance computing.

Mi cadi dalle nuvole o cosa? Xeon Phi è un macinatore di DPFP, stessa cosa la puoi ottenere tramite GPGPU dalle schede video NVIDIA e ATI, oppure ovviamente ti puoi rivolgere nel settore professionale comprando le stesse schede grafiche NVIDIA e ATI opportunamente modificate (maggiori quantitativi di RAM, abilitazione dell'ECC su cache e/o RAM, rimozione del RAMDAC):
http://www.tomshw.it/cont/articolo/r...e/58874/1.html

Originariamente inviato da AceGranger

è una cosa molto diversa rispetto al passato; l'integrazione della GPU nelle CPU è avvenuto per motivi economici e di consumi, prestazionalmente c'è solo da perderci scendendo a compromessi. Dai su, son 2 anni che di HSA nemmeno l'ombra e nemmeno AMD ha avuto al decenza di presentarlo con gia qualcosa di tangibile da mostrare per il quale valesse la pena averlo, visto che si parla solo di un OpenCL migliorato dall'accesso alal memoria... io vedo solo tanto marketing e stop.

Integrando la CPU nella GPU ti garantisci l'accesso da parte di circuiteria altamente specializzata nel calcolo in virgola mobile alla stessa porzione dati che usa la CPU e senza aggiungere latenze al sistema... Nessuno poi ti vieta di aggiungere ANCHE una VGA adibita al macinare dati grafici. Chiaro che se la CPU+GPU la vedi solo come SoC per portatili non sarai d'accordo, ma se la vedessi come "anzi CPU e basta, oppure CPU+GPU?" sapendo che magari esistono programmi capaci di andare più veloci con la seconda (idealmente, come se fossero nuove istruzioni SSE), allora cambieresti idea...
Ovvio che ad oggi è solo fuffa, l'HSA non è servito a nulla e pure Intel non ci ha cavato un ragno dal buco, ma le potenzialità ci sono tutte e secondo me è solo questione di tempo (Intel si sta costruendo la via, poi quando sarà pronta darà la botta finale ad AMD).

[cdimauro]

Originariamente inviato da MiKeLezZ

Ovvero è da intendersi come oppure (che è infatti la sua prima definizione).
http://dizionari.corriere.it/diziona...O/ovvero.shtml

In quel contesto vale la terza definizione, quindi cioé, perché stavi chiarendo il significato di quello che avevi appena iscritto.

D'altra parte col significato di oppure la frase non avrebbe alcun senso. Ecco qui come verrebbe:

"Implementare un regolatore di tensione che a seconda della scrittura nel SPD oppure la nanometria dei chip"

Mi spiegherai in che modo un regolatore di tensione (come pure una scheda madre, se vogliamo estendere il concetto) potrebbe essere a conoscenza dei nanometri dei chip che vengono utilizzati...

Se non sei pratico, non commentare, no?

Nervosetto? E' un forum e stiamo discutendo. Stai tranquillo.

A parte questo, non sono pratico ma nemmeno digiuno di elettronica (sono pur sempre un perito in automatica elettronica, anche se il mio dominio d'elezione rimane l'informatica).

Diminuendo il voltaggio i segnali diventano più sensibili alle interferenze, per cui è più difficile mantenerne l'integrità. Dunque dubito fortemente che la stessa circuiteria sia in grado, così com'è, di poter supportare chip che lavorano a voltaggi inferiori a quelli per la quale è stata progettata.

Ma visto che affermi che non dovrei commentare, mentre tu l'hai fatto, immagino che tu sia uno che ne mastica in materia. Esponi pure le motivazioni per cui la circuiteria esistente potrebbe supportare chip con qualunque voltaggio.

Se le frequenze operative sono le stesse, ovvero 200MHz e da una parte (esempio) si aspettano 4 cicli di clock (Column Access Strobe) prima di recuperare e quindi inviare i dati (DDR2), mentre dall'altra se ne aspettano 8 (DDR3)... Dovrebbe essere facile capire che, in soldoni, è come se la seconda lavorasse a frequenza dimezzata (poi nella realtà è un briciolo più complicato e spesso da iterazione a iterazione si riesce a limare quei valori). E' una coperta.

Il problema è che le frequenze operative NON sono affatto le stesse, perché quelle delle DDR4 sono attualmente inferiori a quelle delle DDR3. Ecco perché le DDR4 presentano latenze superiori.

Per quanto riguarda quest'aspetto, i confronti fra DDR3 e 4 andrebbero fatti a parità di clock principale. Le DDR3 sono state introdotte a 800Mhz, quindi con clock principale a 200Mhz (100Mhz SDRAM). A parità di clock principale, i confronti andrebbero fatti con DDR4 che operano a 1600Mhz. E così via con le altre frequenze.

Poi chiaramente l'evoluzione tecnologica porta a rendere obsoleta l'una e a migliorare l'altra (infatti per le memorie vi è un preciso limite di frequenze operative raggiungibili e si preferisce adottare moltiplicatori più alti e cercare di limare i tempi di accesso, piuttosto che alzare le frequenze di base).

Per questo si alzano le frequenze con le nuove memorie: la tendenza è quella di trasportare più dati rispetto al clock principale, mentre la frequenza di trasferimento dei dati raddoppia rispetto alla generazione precedente.

L'instruction stage pipeline è di circa 14, altro che 2... Significa che possiamo anche prendere processori da 3GHz piuttosto che 2GHz (+50%) e con 4 core core piuttosto che 1 (+400%) ed ottenere un valore comunque inferiore al tuo!

Non ho mai parlato di stage delle pipeline, per cui non capisco da dove l'hai tirato fuori. Infatti:

"Una buona architettura out-of-order è in grado di "spalmare" queste istruzioni in un paio di cicli di clock."

Parlo del numero di cicli di clock necessari a per eseguire le operazioni che avevo elencato.

Inoltre:

"consideriamo il processore che lavora a regime"

che chiarisce le condizioni di funzionamento (pipeline a regime, per l'appunto).

Dunque quello che hai scritto non è attinente a quanto avevo detto in precedenza. E comunque non si capisce dove vorresti arrivare coi "calcoli" che hai riportato.

E parliamo di un caso teoretico in cui si spostano (senza motivo) blocchi di memoria (presi apposta perché unici ottenibili così facilmente e in grande numero).

Spostare blocchi di memoria è un'operazione molto comune in un'applicazione. Ma questa è una cosa ben nota a chi ne mastica un po' di programmazione.

E' talmente importante che la routine presente nella libreria standard (memcpy per C/C++, ad esempio) è particolarmente ottimizzata per cercare di massimizzare le prestazioni. Ed è talmente importante che, ove possibile, si cerca di accelerarla in hardware (vedi Haswell, ad esempio; in particolare nel manuale per le ottimizzazioni che Intel mette a disposizione).

I test reali sono linkati e sono quelli che contano!

E che riportano anche miglioramenti sensibili in alcuni casi, non "teoretici".

Ti sembra logico uno adotti RAM ultraveloci SOLO per aumentare i FPS della scheda grafica integrata da 14 (ingiocabile) a 15 (ingiocabile)? Suvvia...
E parliamo di velocità della RAM (quasi) RADDOPPIATA cioè banda totale (quasi) RADDOPPIATA...

Sì, scriviamolo a tutti:
RAGAZZI, SE VOLETE CHE I GIOCHETTI FATTI PARTIRE CON LA GRAFICA INTEGRATA GUADAGNINO 1% DI PRESTAZIONI, COMPRATEVI RAM CHE VADA IL DOPPIO PIU' VELOCE DELLA PRECEDENTE!!!!

Perché "gridi"? Stai perdendo la pazienza? Stai calmo. Come dicevo prima, stiamo semplicemente discutendo in un forum.

Comunque quel che scrivi è falso, e infatti hai "stranamente" eliminato quanto avevo scritto in merito.

Rieccolo qui:

"Batman e Maya presentano notevoli incrementi."

Riprendendo dal link di Anandtech:

"Batman: AA represents some of the best increases of any application in our testing. Jumps from 1333 C9 to 1600 C9 and 1866 C9 gives an 8% then another 7% boost, ending with a 21% increase in frame rates moving from 1333 C9 to 2400 C10."

21%. Altro che 1%.

E per Maya:

"The biggest gain was using Maya where a 22% increase was observed."

22%.

Direi che i risultati si commentano da sé, checché tu ne possa dire.

Larrabee era VLIW. Poi evidentemente si sono accorti che non funzionava abbastanza bene e hanno cambiato rotta.
http://arstechnica.com/uncategorized/2007/02/8824/
The Processing Engine implements a non-x86, VLIW ISA that uses a 96-bit instruction word containing up to up to 8 ops/cycle.

E' evidente che nemmeno leggi quello che riporti: quel Processing Engine si riferisce a UN ALTRO progetto sperimentale di Intel, che non ha NULLA a che vedere con Larrabee (e tanto meno con Xeon Phi). Difatti sempre da Ars Technica alla notizia che hai riportato, ne aveva pubblicata un'altra che aveva parlato esplicitamente di Larrabee: http://arstechnica.com/uncategorized/2007/02/8810/

"these sixteen cores are small, in-order x86 cores with a short pipeline and lots of vector hardware that implement some GPU-oriented extension of the x86 instruction set"

Dunque niente VLIW, di cui non c'è nemmeno l'ombra. E non poteva essere altrimenti...

Mi cadi dalle nuvole o cosa?

Hai perso nuovamente la pazienza. Segno che stai soffrendo questa discussione, e cerchi di sfogarti spostandoti sul piano personale, sulla presa in giro.

Ma io non ho bisogno di "argomentare" in questo modo.

Xeon Phi è un macinatore di DPFP, stessa cosa la puoi ottenere tramite GPGPU dalle schede video NVIDIA e ATI, oppure ovviamente ti puoi rivolgere nel settore professionale comprando le stesse schede grafiche NVIDIA e ATI opportunamente modificate (maggiori quantitativi di RAM, abilitazione dell'ECC su cache e/o RAM, rimozione del RAMDAC):
http://www.tomshw.it/cont/articolo/r...e/58874/1.html

Interessante. Dovremmo, quindi, segnalare a nVidia che smetta di produrre schede di classe "Tesla", poiché sono sufficienti le sue GPU consumer per coprire il mercato workstation & HPC...

Integrando la CPU nella GPU

Ma non è il contrario che si fa? Da quando la CPU è divenuta "serva" della GPU?

ti garantisci l'accesso da parte di circuiteria altamente specializzata nel calcolo in virgola mobile alla stessa porzione dati che usa la CPU e senza aggiungere latenze al sistema...

E in che modo succederebbe questo miracolo? Scendi pure nei dettagli, perché l'argomento è molto interessante.

Nessuno poi ti vieta di aggiungere ANCHE una VGA adibita al macinare dati grafici. Chiaro che se la CPU+GPU la vedi solo come SoC per portatili non sarai d'accordo, ma se la vedessi come "anzi CPU e basta, oppure CPU+GPU?" sapendo che magari esistono programmi capaci di andare più veloci con la seconda (idealmente, come se fossero nuove istruzioni SSE), allora cambieresti idea...

Se spiegassi meglio come dovrebbe succedere il tutto, e in particolare riguardo alla parte che ho evidenziato, potremmo capire cosa intendi. Potresti anche illustrare un esempio pratico.

Ovvio che ad oggi è solo fuffa, l'HSA non è servito a nulla e pure Intel non ci ha cavato un ragno dal buco,

Da quando Intel supporta / implementa l'HSA? Non ne è a conoscenza nemmeno un collega col quale ho discusso dell'argomento giusto un paio di giorni fa, e che lavora proprio sulle nostre GPU...

ma le potenzialità ci sono tutte e secondo me è solo questione di tempo (Intel si sta costruendo la via, poi quando sarà pronta darà la botta finale ad AMD).

Quante cose si vengono a scoprire in un forum. Come dicevo prima, non ne è a conoscenza nemmeno uno che ci lavora tutti i giorni proprio con queste cose. Hai fonti migliori riguardo a questa presunta via? Riportale pure, che sono curiosissimo di conoscerle (così mi faccio un'altra chiacchierata col mio collega, sul tema).

[devil_mcry]

Originariamente inviato da [K]iT[o]

Senza un'adeguata concorrenza si è fermato tutto, ho comprato il 2600k 4 anni fa ma a prestazioni è come se l'avessi preso adesso. Sapevo di fare un buon acquisto, ma così è eccessivo.

Si vabeh... queste CPU hanno un IPC più elevato di SB di un 30% e oltre, un 2600k nemmeno in OC riesce a fare le performance di un 6770k default. Se non ci credi, ovviamente se sono veri i leak, siamo ad oltre 10.5pti al cinebench r11.5 ad esempio, per dare un metro di paragone il WorldRecord su Sandy Bridge è appena di 11.7 punti e in OC stabile medio (4.5-4.6) non si arrivava oltre i 9 punti praticamente.

Originariamente inviato da AceGranger

e credo che ci rimarremo fermi per almeno un'altro millennio; le novita le sta introducendo nella piattaforma 2011 con il taglio consistente alla CPU 6 core e con l'itroduzione di 8 core; la piattaforma consumer è condivisa con quella mobile e di 6 core non se ne sente proprio l'esigenza, visto che gia c'è la piattaforma 2011.

Beh in realtà in termini stretti stretti di novità, Intel le introduce un po' sulla 115x un po' sulla 2011. Vedi le DDR4 prima sulla fascia professionale e le architetture nuove sulla fascia consumer.

Sicuramente però almeno per altri 2 anni non arriverà un 6/12 sulla fascia consumer, è stato appena introdotto per la fascia pro (ed è scalato di segmento prestazioni in 3 generazioni di fatto) come CPU entry dopo 3 generazioni quindi hai voglia...

[bongo74]

quindi quando escono i 14nm desktop?