[Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*

[birmarco]

Cmq il fatto che windows 8 sarà compatibile con CPU 128bit non vuol dire che sarà a 128... ma che potrà funzionare ANCHE su CPU a 128bit. Quindi non è detto nè che ci saranno OS a 128bit nè CPU a 128bit. Considerando che Win8 uscirà ipoteticamente tra 2 anni e che durerà per 2 anni prima che arrivi il suo successore (OT: che sarà ancora Windows?? ). QUindi Microsoft avrebbe messo le mani avanti per i prossimi 4 anni (2014). Le CPU a 32nm esistono circa dal 1990 e le 64bit dal 2004 (14 anni di 32bit). Se intorno al 2014 ci saranno CPU a 128bit la "tabella di marcia" sarebbe rispettata (le CPU a 16bit sono durate 12 anni...)

[bjt2]

Originariamente inviato da capitan_crasy

Notizia da prendere con le dovute cautele:
(era un bel pò che non usavo questa frase )

Clicca qui...

bjt2, che ne pensi dell'ipotesi di Bulldozer a 128bit?

Se per 128 bit indica l'estensione dei 16 GPR a 128 bit, non vedo questa grande rivoluzione, a meno che questo non voglia dire poter usare le istruzioni SIMD anche con i GPR. Sicuramente gli indirizzi NON saranno estesi a 128 bit (troppo spazio e comunque non sarà necessario per moooolti anni farlo). Estendere l'architettura a 128 bit può avere qualche vantaggio: poter usare anche i 16 GPR come registri per le SSE a 128 bit (MA NON PER QUELLE a 256 BIT), quindi per come è fatta l'architettura K10 (e probabilmente anche buldozer) poter far eseguire queste istruzioni nelle pipeline intere, raddoppiando di fatto il throughput SSE 128 bit (ma è una ipotesi).

Anche se non vengono estese le SSE 128 bit ai registri GPR, possono comunque essere create istruzioni intere a 128 bit oppure intere SIMD a 8-16-32-64 bit...

I vantaggi sono pochi, comunque. Forse per la crittografia, istruzioni intere a 128 bit accelererebbero di molto il calcolo, ma non vedo altre applicazioni eclatanti, a meno che non introducano, appunto, istruzioni SIMD sui GPR...

Il supporto da parte del SO si riduce solo a prevedere lo spazio necessario sullo stack kernel per i registri allargati, perchè esistono istruzioni CPU per fare il task switch...

[Pihippo]

Originariamente inviato da bjt2

Se per 128 bit indica l'estensione dei 16 GPR a 128 bit, non vedo questa grande rivoluzione, a meno che questo non voglia dire poter usare le istruzioni SIMD anche con i GPR. Sicuramente gli indirizzi NON saranno estesi a 128 bit (troppo spazio e comunque non sarà necessario per moooolti anni farlo). Estendere l'architettura a 128 bit può avere qualche vantaggio: poter usare anche i 16 GPR come registri per le SSE a 128 bit (MA NON PER QUELLE a 256 BIT), quindi per come è fatta l'architettura K10 (e probabilmente anche buldozer) poter far eseguire queste istruzioni nelle pipeline intere, raddoppiando di fatto il throughput SSE 128 bit (ma è una ipotesi).

Anche se non vengono estese le SSE 128 bit ai registri GPR, possono comunque essere create istruzioni intere a 128 bit oppure intere SIMD a 8-16-32-64 bit...

I vantaggi sono pochi, comunque. Forse per la crittografia, istruzioni intere a 128 bit accelererebbero di molto il calcolo, ma non vedo altre applicazioni eclatanti, a meno che non introducano, appunto, istruzioni SIMD sui GPR...

Il supporto da parte del SO si riduce solo a prevedere lo spazio necessario sullo stack kernel per i registri allargati, perchè esistono istruzioni CPU per fare il task switch...

Ciao
In effetti penso anch'io che l'allargamento dei gprs a 128bit porti vantaggi marginali, basta pensare che gli int a 64bit vengono utlizzati solo in crittografia od HPC per il resto ci sono i valori in float che garantiscono una simulazione maggiore dei numeri reali. Gia a 64bit si possono rappresentare integers con range elevatissimi, poi, secondo me, utilizzare gprs per operazioni matematiche non è che sia il massimo, sono gia pochi (quando si possono usare i registri mmx, xmm delle simd, ed addirittura quelli dell'x87)
Sinceramente non penso che con l'IA a 128 bit estenderanno i gprs ad operazioni con le simd, questo soprattuto considerando che con le AVX si avranno vettori a 256bit. Oltrettuto dovrebbero cambiare molte cose nelle architettura, ovvero come esegui operazioni int a 64-32 bit se i gprs vengono occupati da istruzioni SimD? A meno che non si aumentino i gprs totali di cui alcuni di quelli introdotti (ipotetici RAX-EAX17 ad RAX-EAX32 se li radoppiano da 16 a 32) utilizzati solo per quello, e l'os per poterli utilizzare dovrebbe operare in una long mode simile a quella che si utlizza in abiente x64...
Inoltre avere un radoppio dei registri condurrebbe ad uno snellimento del codice, sempre che gli sviluppatori abbiano voglia di "ricompilare" il codice, ovvero meno LOAD e STORE perchè hai più gprs per metterci dentro i dati, quindi anche più velocità.

[Pihippo]

Originariamente inviato da Pihippo

Ciao
In effetti penso anch'io che l'allargamento dei gprs a 128bit porti vantaggi marginali, basta pensare che gli int a 64bit vengono utlizzati solo in crittografia od HPC per il resto ci sono i valori in float che garantiscono una simulazione maggiore dei numeri reali. Gia a 64bit si possono rappresentare integers con range elevatissimi, poi, secondo me, utilizzare gprs per operazioni matematiche non è che sia il massimo, sono gia pochi (quando si possono usare i registri mmx, xmm delle simd, ed addirittura quelli dell'x87)
Sinceramente non penso che con l'IA a 128 bit estenderanno i gprs ad operazioni con le simd, questo soprattuto considerando che con le AVX si avranno vettori a 256bit. Oltrettuto dovrebbero cambiare molte cose nelle architettura, ovvero come esegui operazioni int a 64-32 bit se i gprs vengono occupati da istruzioni SimD? A meno che non si aumentino i gprs totali di cui alcuni di quelli introdotti (ipotetici RAX-EAX17 ad RAX-EAX32 se li radoppiano da 16 a 32) utilizzati solo per quello, e l'os per poterli utilizzare dovrebbe operare in una long mode simile a quella che si utlizza in abiente x64...
Inoltre avere un radoppio dei registri condurrebbe ad uno snellimento del codice, sempre che gli sviluppatori abbiano voglia di "ricompilare" il codice, ovvero meno LOAD e STORE perchè hai più gprs per metterci dentro i dati, quindi anche più velocità.

Mi quoto per specficare una cosa, dopo ricerche non proprio approfonditissime posso affermare con assoluta, quasi , certezza che i programmatori di giochini se ne sbattono altamente di ricompilare i loro codici per avere maggiori performance..

[bjt2]

Originariamente inviato da Pihippo

Ciao
In effetti penso anch'io che l'allargamento dei gprs a 128bit porti vantaggi marginali, basta pensare che gli int a 64bit vengono utlizzati solo in crittografia od HPC per il resto ci sono i valori in float che garantiscono una simulazione maggiore dei numeri reali. Gia a 64bit si possono rappresentare integers con range elevatissimi, poi, secondo me, utilizzare gprs per operazioni matematiche non è che sia il massimo, sono gia pochi (quando si possono usare i registri mmx, xmm delle simd, ed addirittura quelli dell'x87)
Sinceramente non penso che con l'IA a 128 bit estenderanno i gprs ad operazioni con le simd, questo soprattuto considerando che con le AVX si avranno vettori a 256bit. Oltrettuto dovrebbero cambiare molte cose nelle architettura, ovvero come esegui operazioni int a 64-32 bit se i gprs vengono occupati da istruzioni SimD? A meno che non si aumentino i gprs totali di cui alcuni di quelli introdotti (ipotetici RAX-EAX17 ad RAX-EAX32 se li radoppiano da 16 a 32) utilizzati solo per quello, e l'os per poterli utilizzare dovrebbe operare in una long mode simile a quella che si utlizza in abiente x64...
Inoltre avere un radoppio dei registri condurrebbe ad uno snellimento del codice, sempre che gli sviluppatori abbiano voglia di "ricompilare" il codice, ovvero meno LOAD e STORE perchè hai più gprs per metterci dentro i dati, quindi anche più velocità.

Portare i registri GPR e le attuali ALU int a 128 bit e renderle SIMD non è poi tutta questa complicazione... Non c'è alcuna penalità ad usare i GPR prima per operazioni normali e poi SIMD. Raddoppiare i registri non so se porti a un grosso vantaggio. Già adesso con 16 GPR, 16 registri SIMD a 128 bit (prossimamente a 256 bit e oltre) non c'è poi tutto questa necessità. Aumentare i regitri GPR o allargare i registri aumenta il tempo di task switch e può aumentare i tempi di cambio di privilegio (una routine IRQ deve salvare almeno i registri che usa prima di sovrascriverli, e se sono a 128 bit ci mette il doppio), quindi non sempre il gioco vale la candela.
Concettualmente rendere SIMD una ALU intera è molto semplice, anche perchè l'addizionatore, ad esempio, è già diviso in blocchi da 8, 16, 32 e 64 bit perchè si usa lo stesso addizionatore per tutte le istruzioni. E' abbastanza banale prendere un addizionatore a 64 bit e dividerlo in 8 addizionatori 8 bit, ad esempio...

[Pihippo]

Originariamente inviato da bjt2

Portare i registri GPR e le attuali ALU int a 128 bit e renderle SIMD non è poi tutta questa complicazione... Non c'è alcuna penalità ad usare i GPR prima per operazioni normali e poi SIMD. Raddoppiare i registri non so se porti a un grosso vantaggio. Già adesso con 16 GPR, 16 registri SIMD a 128 bit (prossimamente a 256 bit e oltre) non c'è poi tutto questa necessità. Aumentare i regitri GPR o allargare i registri aumenta il tempo di task switch e può aumentare i tempi di cambio di privilegio (una routine IRQ deve salvare almeno i registri che usa prima di sovrascriverli, e se sono a 128 bit ci mette il doppio), quindi non sempre il gioco vale la candela.
Concettualmente rendere SIMD una ALU intera è molto semplice, anche perchè l'addizionatore, ad esempio, è già diviso in blocchi da 8, 16, 32 e 64 bit perchè si usa lo stesso addizionatore per tutte le istruzioni. E' abbastanza banale prendere un addizionatore a 64 bit e dividerlo in 8 addizionatori 8 bit, ad esempio...

Ciao
E' sempre un piacere parlare con te, anche perchè cosi approfondisco\imparo cose di cui prima ne sapevo nulla
Comunque per quanto possa essere lungo il task switch verrebbe gestito dall'os prima che una applicazione possa effettivamente richiedere i registri a 128 bit a meno che la cpu non deve fare ping pong perchè l'applicazione in questione vuole sia i gpr a 64 che a 128bit, che, dato lo stato attuale del software è possibile. Questo gia succede con le interruption request in vista x64 a meno che non vi sia solo una linea ma penso ve ne siano 256. Per quanto ne so anche l'adder degli interi deve essere a 128bit quindi bisognerebbe per avere full performance in 128bit inserire nelle alu un adder a 128bit, ed allargare il datapath a 128bit quindi code a 128bit degli issue slot ed anche degli scheduler. Non so se sia complicato o meno ma certo ci vogliono transistor e si avvantaggierebbero poche applicazioni che nel desktop servono poco. Guarda io invece ritengo che più registri sono meglio è, alla fine dei conti 1\3 delle operazioni x86 nei programmi comuni non sono ne di aritmetica ne di logica sono load e Store(ed operazioni di memoria quindi pure con i registri gprs) con eventuale trip verso la ram se per disgrazia il dato\operando non è presente nella cache.

[bjt2]

Originariamente inviato da Pihippo

Ciao
E' sempre un piacere parlare con te, anche perchè cosi approfondisco\imparo cose di cui prima ne sapevo nulla
Comunque per quanto possa essere lungo il task switch verrebbe gestito dall'os prima che una applicazione possa effettivamente richiedere i registri a 128 bit a meno che la cpu non deve fare ping pong perchè l'applicazione in questione vuole sia i gpr a 64 che a 128bit, che, dato lo stato attuale del software è possibile. Questo gia succede con le interruption request in vista x64 a meno che non vi sia solo una linea ma penso ve ne siano 256. Per quanto ne so anche l'adder degli interi deve essere a 128bit quindi bisognerebbe per avere full performance in 128bit inserire nelle alu un adder a 128bit, ed allargare il datapath a 128bit quindi code a 128bit degli issue slot ed anche degli scheduler. Non so se sia complicato o meno ma certo ci vogliono transistor e si avvantaggierebbero poche applicazioni che nel desktop servono poco. Guarda io invece ritengo che più registri sono meglio è, alla fine dei conti 1\3 delle operazioni x86 nei programmi comuni non sono ne di aritmetica ne di logica sono load e Store(ed operazioni di memoria quindi pure con i registri gprs) con eventuale trip verso la ram se per disgrazia il dato\operando non è presente nella cache.

Per il task switch esiste una istruzione in linguaggio macchina per salvare tutti i registri. Per passare da un processo a 32 bit a uno a 64 bit (o da uno a 64 a uno ipotetico a 128 bit) la sequenza è <salva stato> (che nella modalità a 32 bit salva solo 32 bit per registro), <passa a modalità 64 bit>, <ripristina stato> (che nella modalità a 64 bit ripristina tutti i 64 bit), e viceversa per passare da un task a 64 bit a uno a 32 bit.

Per quanto riguarda le considerazioni sul data path: sono tutte giuste. E' un piccolo vantaggio avere ALU a 128 bit. Mi viene in mente solo la crittografia oppure l'uso di istruzioni SIMD. Per quanto riguarda l'ALU a 128 bit, si può sempre fare che le addizioni a 128 bit abbiano latenza di due cicli, cosi' da non dover rallentare troppo la pipeline...

[Pihippo]

Originariamente inviato da bjt2

Per il task switch esiste una istruzione in linguaggio macchina per salvare tutti i registri. Per passare da un processo a 32 bit a uno a 64 bit (o da uno a 64 a uno ipotetico a 128 bit) la sequenza è <salva stato> (che nella modalità a 32 bit salva solo 32 bit per registro), <passa a modalità 64 bit>, <ripristina stato> (che nella modalità a 64 bit ripristina tutti i 64 bit), e viceversa per passare da un task a 64 bit a uno a 32 bit.

Per quanto riguarda le considerazioni sul data path: sono tutte giuste. E' un piccolo vantaggio avere ALU a 128 bit. Mi viene in mente solo la crittografia oppure l'uso di istruzioni SIMD. Per quanto riguarda l'ALU a 128 bit, si può sempre fare che le addizioni a 128 bit abbiano latenza di due cicli, cosi' da non dover rallentare troppo la pipeline...

Ciao
Veramente costruttivo parlare con te. Poi magari anche altri leggendo si potrebbero appassionare a ste cosuccie qui rendendo il thread ancora più interessante.
Ritornando al discorso sul task switch, io non pensavo che esistesse addirittura una istruzione a livello dell'isa che consente ciò e ti ringrazio per averlo specificato.
Per le latenze di un ipotetico ADD r,ri a 128bit secondo me chiederlo in 2 cicli è rallentare troppo la pipeline un add r,ri con operandi a 64bit (e dunque uso di gprs REX-EAX dal 8 in poi sino al 16) richeide 1 ciclo, si avrebbè un aumento del 50% di latenze che per operazioni abbastanza comuni come ADD è troppo.
Se casomai davvero buldozzer dovesse essere a 128bit, con isa a 128bit, mi aspetterei quanto meno che le istruzioni a 128bit richiedano latenze vicine a quelle a 64bit, poi aggiungendoci più gprs ed eliminando altre load e store magari si potrebbe avere un vantaggio consistente, ma di certo non dato da operazioni a 128 bit, magari server ed HPC ringrazieranno il desktop non so quanto.

[bjt2]

Originariamente inviato da Pihippo

Ciao
Veramente costruttivo parlare con te. Poi magari anche altri leggendo si potrebbero appassionare a ste cosuccie qui rendendo il thread ancora più interessante.
Ritornando al discorso sul task switch, io non pensavo che esistesse addirittura una istruzione a livello dell'isa che consente ciò e ti ringrazio per averlo specificato.
Per le latenze di un ipotetico ADD r,ri a 128bit secondo me chiederlo in 2 cicli è rallentare troppo la pipeline un add r,ri con operandi a 64bit (e dunque uso di gprs REX-EAX dal 8 in poi sino al 16) richeide 1 ciclo, si avrebbè un aumento del 50% di latenze che per operazioni abbastanza comuni come ADD è troppo.
Se casomai davvero buldozzer dovesse essere a 128bit, con isa a 128bit, mi aspetterei quanto meno che le istruzioni a 128bit richiedano latenze vicine a quelle a 64bit, poi aggiungendoci più gprs ed eliminando altre load e store magari si potrebbe avere un vantaggio consistente, ma di certo non dato da operazioni a 128 bit, magari server ed HPC ringrazieranno il desktop non so quanto.

Se non mi sbaglio gli mnemonici sono XSAVE e XRESTORE...
Per quanto riguarda la latenza... Io intendevo latenza di 2 cicli solo per la istruzione a 128 bit, lasciando 1 ciclo per quella a 64 bit... Se fosse per me, andrei all'estremo: velocizzerei le pipeline in modo che istruzioni a 8/16/32 bit richiedano un ciclo e istruzioni a 64 bit 2 cicli (ed eventualmente 4 cicli per quelle a 128 bit), cosi' da poter salire ancora di clock... Teoricamente si potrebbe avere il doppio del clock...
Non è conveniente far avere stessa latenza per istruzioni a differente ampiezza, perchè cosi' devi abbassare il clock... Le uniche istruzioni per cui non cambia la latenza sono quelle logiche...

[Pihippo]

Originariamente inviato da bjt2

Se non mi sbaglio gli mnemonici sono XSAVE e XRESTORE...
Per quanto riguarda la latenza... Io intendevo latenza di 2 cicli solo per la istruzione a 128 bit, lasciando 1 ciclo per quella a 64 bit... Se fosse per me, andrei all'estremo: velocizzerei le pipeline in modo che istruzioni a 8/16/32 bit richiedano un ciclo e istruzioni a 64 bit 2 cicli (ed eventualmente 4 cicli per quelle a 128 bit), cosi' da poter salire ancora di clock... Teoricamente si potrebbe avere il doppio del clock...
Non è conveniente far avere stessa latenza per istruzioni a differente ampiezza, perchè cosi' devi abbassare il clock... Le uniche istruzioni per cui non cambia la latenza sono quelle logiche...

Ciao
Interessante il discorso che fai tu, alla fine non si penalizzerebbe molto nulla e si potrebbe salire di clock che non fa mai male.
Magari potrebbero fare pure cosi, ovvero allungare le lateze di un pochino ma salire molto di clock, che non è male. Chissà cosa sarà davvero buldozer ovvero clock speed alti e latenze un pò maggiorate, oppure latenze molto conservative(basse) ma da i clock speed limitati?
Secondo me intrapenderanno una via di mezzo

[bjt2]

Originariamente inviato da Pihippo

Ciao
Interessante il discorso che fai tu, alla fine non si penalizzerebbe molto nulla e si potrebbe salire di clock che non fa mai male.
Magari potrebbero fare pure cosi, ovvero allungare le lateze di un pochino ma salire molto di clock, che non è male. Chissà cosa sarà davvero buldozer ovvero clock speed alti e latenze un pò maggiorate, oppure latenze molto conservative(basse) ma da i clock speed limitati?
Secondo me intrapenderanno una via di mezzo

Il processore ideale è quello asincrono, dove ogni dato è processato alla massima velocità possibile e alla fine se è richiesto il ritiro in order delle istruzioni (come nell'architettura x86), è li che avviene il riordinamento.

Per avvicinarsi basterebbe avere un clock molto elevato e ogni operazione fattibile in un multiplo di cicli dove solo l'operazione più semplice di tutte richiede esattamente un ciclo (penso alle AND, OR, XOR, NOT, Shift di un solo bit) e le altre di più... Teoricamente si potrebbe arrivare a svariati GHz.

Però poi si arriva al limite del silicio e quindi ci si accontenta di frequenze di qualche GHz dove le operazioni più semplici ci mettono una frazione di clock per essere completate.

[Pihippo]

Originariamente inviato da bjt2

Il processore ideale è quello asincrono, dove ogni dato è processato alla massima velocità possibile e alla fine se è richiesto il ritiro in order delle istruzioni (come nell'architettura x86), è li che avviene il riordinamento.

Per avvicinarsi basterebbe avere un clock molto elevato e ogni operazione fattibile in un multiplo di cicli dove solo l'operazione più semplice di tutte richiede esattamente un ciclo (penso alle AND, OR, XOR, NOT, Shift di un solo bit) e le altre di più... Teoricamente si potrebbe arrivare a svariati GHz.

Però poi si arriva al limite del silicio e quindi ci si accontenta di frequenze di qualche GHz dove le operazioni più semplici ci mettono una frazione di clock per essere completate.

Ciao
Come sempre spunti molto interassanti di discussione.
Penso, sottolineo penso, che quello che chiedi tu è non sia il processore ideale per quelli pipelined, mi spiego:
Se ogni istruzione fosse un multiplo esatto di un altra istruzione, si potrebbero avrebbero le temutissime bolle nella pipeline che sono quelle che ammazzano un pò tutta l'idea di base di avere pipeline. Mettiamo caso che ho una pipeline con 4 issue slot, mi arrivano 4 istruzioni e io pipeline sono contento perchè posso operare al massimo, nello specifico, per culo o miracolo del compiler queste istruzioni non hanno nessun input di dipendenza e quindi le posso processare come mi piace (out of order), sono 2 ADD r,ri un LEA + JMP
ADD mi richiede 2 cicli, LEA mi richiede 4 cicli ed il JMP 2 cicli(magari..) inizio col lea perchè è una operazione di memoria e sono quelle che rompono di più c"£$0ni, inizio ad eseguirla e siccome sono una pipeline fortunata e c'ho 4 issue slot pieni con operazioni indipendenti il ciclo dopo inizio l'add mentre la LEA è ancora in pipeline( e ci mancano 2 cicli) clock successivo mi inizio l'altro ADD r,ri, ma catastrofe a al prossimo inizio di clock ho 2 operazioni completate, siccome non posso salvarle nel retirement buffer mi stallo e le blocco nello stage di pipeline che sono arrivate. E questo nel caso migliore, ovviamente la pipeline si stalla anche se per esempio l'add ha bisogno del risultato del lea per essere completato.
Ovviamente ciò a mia opinione, cosa ne pensi?

[bjt2]

Originariamente inviato da Pihippo

Ciao
Come sempre spunti molto interassanti di discussione.
Penso, sottolineo penso, che quello che chiedi tu è non sia il processore ideale per quelli pipelined, mi spiego:
Se ogni istruzione fosse un multiplo esatto di un altra istruzione, si potrebbero avrebbero le temutissime bolle nella pipeline che sono quelle che ammazzano un pò tutta l'idea di base di avere pipeline. Mettiamo caso che ho una pipeline con 4 issue slot, mi arrivano 4 istruzioni e io pipeline sono contento perchè posso operare al massimo, nello specifico, per culo o miracolo del compiler queste istruzioni non hanno nessun input di dipendenza e quindi le posso processare come mi piace (out of order), sono 2 ADD r,ri un LEA + JMP
ADD mi richiede 2 cicli, LEA mi richiede 4 cicli ed il JMP 2 cicli(magari..) inizio col lea perchè è una operazione di memoria e sono quelle che rompono di più c"£$0ni, inizio ad eseguirla e siccome sono una pipeline fortunata e c'ho 4 issue slot pieni con operazioni indipendenti il ciclo dopo inizio l'add mentre la LEA è ancora in pipeline( e ci mancano 2 cicli) clock successivo mi inizio l'altro ADD r,ri, ma catastrofe a al prossimo inizio di clock ho 2 operazioni completate, siccome non posso salvarle nel retirement buffer mi stallo e le blocco nello stage di pipeline che sono arrivate. E questo nel caso migliore, ovviamente la pipeline si stalla anche se per esempio l'add ha bisogno del risultato del lea per essere completato.
Ovviamente ciò a mia opinione, cosa ne pensi?

Ovviamente sarebbe peggiorativo se il clock fosse lo stesso. Ma spezzettando l'istruzione si potrebbero avere clock più elevati. Quindi pipeline più lunghe. Ma ciò poi ci porta all'incubo del pentium 4: i salti... Per fare questo con pipeline corte, si dovrebbero introdurre unità più complesse che facciano le varie operazioni con latenze di clock diverse, ovviamente fatte in modo che il clock possa essere elevato. Ma ciò porta a una notevole complicazione: un conto è un addizionatore che fa tutte le addizioni in un solo ciclo, anche se "lungo". Un conto è un addizionatore che fa le addizioni ad 8 bit in un ciclo, quelle a 16 in due, anche se il ciclo è molto più corto... Oltre ad essere più complesso, il clock dovrebbe essere velocissimo per avere velocità comparabili al caso precedente... Questo probabilmente porterebbe a grosse dissipazioni...

[gervi]

scusate se lo chiedo, ma non 'è ancora il topic

"aspettando sandy bridge di intel" ???

Poichè sarà l'architettura concorrente du bulldozer???

[capitan_crasy]

Originariamente inviato da gervi

scusate se lo chiedo, ma non 'è ancora il topic

"aspettando sandy bridge di intel" ???

Poichè sarà l'architettura concorrente du bulldozer???

Lascio ad altri l'onore di aprire e gestire il thread su Sandybridge...

[Pihippo]

Originariamente inviato da bjt2

Ovviamente sarebbe peggiorativo se il clock fosse lo stesso. Ma spezzettando l'istruzione si potrebbero avere clock più elevati. Quindi pipeline più lunghe. Ma ciò poi ci porta all'incubo del pentium 4: i salti... Per fare questo con pipeline corte, si dovrebbero introdurre unità più complesse che facciano le varie operazioni con latenze di clock diverse, ovviamente fatte in modo che il clock possa essere elevato. Ma ciò porta a una notevole complicazione: un conto è un addizionatore che fa tutte le addizioni in un solo ciclo, anche se "lungo". Un conto è un addizionatore che fa le addizioni ad 8 bit in un ciclo, quelle a 16 in due, anche se il ciclo è molto più corto... Oltre ad essere più complesso, il clock dovrebbe essere velocissimo per avere velocità comparabili al caso precedente... Questo probabilmente porterebbe a grosse dissipazioni...

Ciao
Hai perfettamente ragione, per implementare un sistema cosi ci dovrebbero spendere parecchi transistor con conseguente aumento del die, consumi maggiori e temperature maggiori, sembra che tutte le architetture debbano fare un compromesso tra IPC clock ed ovviamente consumi, però sarebbè bello avere un ipotetico procio che non stalla mai e viaggia a clock pazzeschi.
Oppure potrebbero fare anche cosi, si utilizza come core di base i k10 che per quanto sfigati hanno una buona efficienza di base, tweakkarli in modo da essere anche leggermente (10-15%) più efficienti, magari migliorare l'unità dei salti allungare un pò la pipeline e farlo girare questo ipotetico bulldozer a 5ghz e più

[bjt2]

Originariamente inviato da Pihippo

Ciao
Hai perfettamente ragione, per implementare un sistema cosi ci dovrebbero spendere parecchi transistor con conseguente aumento del die, consumi maggiori e temperature maggiori, sembra che tutte le architetture debbano fare un compromesso tra IPC clock ed ovviamente consumi, però sarebbè bello avere un ipotetico procio che non stalla mai e viaggia a clock pazzeschi.
Oppure potrebbero fare anche cosi, si utilizza come core di base i k10 che per quanto sfigati hanno una buona efficienza di base, tweakkarli in modo da essere anche leggermente (10-15%) più efficienti, magari migliorare l'unità dei salti allungare un pò la pipeline e farlo girare questo ipotetico bulldozer a 5ghz e più

Mi è venuta in mente una soluzione alternativa, che non richiede stravolgimenti: la vettorizzazione automatica. Mi spiego:
Supponiamo che tutte le ALU a 64 bit intere siano fatte in modo da poter fare anche 2 operazioni a 32 bit in parallelo. Con un po' di logica in più si potrebbero accorpare istruzioni uguali su dati diversi e farle in parallelo, mantenendo unità con latenze da 1 cliclo su tutte le istruzioni. E' una complicazione a livello di dispatch e ritiro, ma potrebbe aumentare le prestazioni. A maggior ragione con ALU a 128 bit e magari sfruttando anche le ALU SSE che sono nella FPU...

[Pihippo]

Originariamente inviato da bjt2

Mi è venuta in mente una soluzione alternativa, che non richiede stravolgimenti: la vettorizzazione automatica. Mi spiego:
Supponiamo che tutte le ALU a 64 bit intere siano fatte in modo da poter fare anche 2 operazioni a 32 bit in parallelo. Con un po' di logica in più si potrebbero accorpare istruzioni uguali su dati diversi e farle in parallelo, mantenendo unità con latenze da 1 cliclo su tutte le istruzioni. E' una complicazione a livello di dispatch e ritiro, ma potrebbe aumentare le prestazioni. A maggior ragione con ALU a 128 bit e magari sfruttando anche le ALU SSE che sono nella FPU...

Ciao.
Molto interessante questa proposta. Alu simd like possono essere molto più efficienti quando c'è un minimo di parallelismo nel codice ( ed i compilernon sono taroccati )
In effetti penso anche io che bisognerebbe "potenziare" un pochetto di più gli scheduler vari e le dispatch unit. Le prestazioni auemnterebbero di sicuro, utilizzare una alu che esegue due operazioni in parallelo potrebbe pure evitare stalli che sprecano performance, comunque in vista di questa tua idea che a me piace moltissimo, e visto che di bjt2 te ne intendi , ciò , non vorrebbe dire a fronte di una maggiore complessità di logica si avrebbero anche clock minori? Cioè pensavo che le parti di logica dei core sono quelle più "sensibili" e magari a clock alti schiattano prima delle pipeline e delle cache o sbaglio? Non vorrei che bulldozer se magari fosse cosi come ipotizziamo sia un k10 a 65nm v2 ovvero buona architettura di base ma che non saliva manco pregando in aramaico.

[bjt2]

Originariamente inviato da Pihippo

Ciao.
Molto interessante questa proposta. Alu simd like possono essere molto più efficienti quando c'è un minimo di parallelismo nel codice ( ed i compilernon sono taroccati )
In effetti penso anche io che bisognerebbe "potenziare" un pochetto di più gli scheduler vari e le dispatch unit. Le prestazioni auemnterebbero di sicuro, utilizzare una alu che esegue due operazioni in parallelo potrebbe pure evitare stalli che sprecano performance, comunque in vista di questa tua idea che a me piace moltissimo, e visto che di bjt2 te ne intendi , ciò , non vorrebbe dire a fronte di una maggiore complessità di logica si avrebbero anche clock minori? Cioè pensavo che le parti di logica dei core sono quelle più "sensibili" e magari a clock alti schiattano prima delle pipeline e delle cache o sbaglio? Non vorrei che bulldozer se magari fosse cosi come ipotizziamo sia un k10 a 65nm v2 ovvero buona architettura di base ma che non saliva manco pregando in aramaico.

Queste complicazioni aggiungono solo transistors. Non dovrebbero impattare più di tanto sul consumo...

[capitan_crasy]

Il sito X-bit labs pubblica delle dichiarazioni di Dirk Meyer (CEO AMD) sulle prossime CPU+GPU in uscita nel 2011.
Meyer dice chiaramente che le prossime APU nome in codice Llano, primo chip ad utilizzare la tecnologia "Fusion", saranno realizzati utilizzando la tecnologia produttiva 32nm SOI (silicon-on-insulator).
Finalmente ci sono le prime conferme di una GPU pensata e costruita con lo stesso silicio utilizzato per la produzione delle CPU AMD.
Per il momento non si sa se tale GPU compatibile con le DX 11 sia un RV8x0 ridisegnato oppure derivi da un nuovo progetto.
Il sito conclude che con tutta probabilità sarà usato una CPU con architettura K10 con tecnologia produttiva a 32nm; tuttavia nessuno smentisce che la parte X86 delle APU Llano sia basata sull'architettura Bulldozer prevista anch'essa nel 2011 con tecnologia produttiva a 32nm SOI.

Clicca qui...