Torna indietro   Hardware Upgrade Forum > Componenti Hardware > Processori

Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella nostra video anteprima!
Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella nostra video anteprima!
Siamo riusciti ad andare al quartier generale di Milano dove Samsung ci ha permesso di mettere le mani su tutte e tre le versioni dei nuovi smartphone Galaxy S21, S21+ e S21 Ultra. Tre diverse versioni proprio come tre erano gli smartphone lo scorso anno con la serie Galaxy S20. Ecco come sono fatti.
ASUS ZenBook Duo UX482: due schermi e tanta autonomia
ASUS ZenBook Duo UX482: due schermi e tanta autonomia
La nuova gamma di notebook ASUS per il 2021 vede il ritorno di modelli con due schermi, capaci di offrire un livello di produttività ancora più elevato dello standard. ZenBook Duo UX482 abbina uno schermo da 14 pollici Full HD al nuovo ScreenPad +, tutto su piattaforma Intel EVO con processore Core i7 Tiger Lake. Tanta potenza, dimensioni contenute e autonomia con batteria da vendere
Sony FE 35mm F1.4 GMaster, grande risoluzione e sfocato eccellente. La recensione
Sony FE 35mm F1.4 GMaster, grande risoluzione e sfocato eccellente. La recensione
Sony introduce per le sue mirrorless full frame un 35mm della famiglia GMaster, che si distingue per l'elevatissimo potere risolvente e l'eccellente resa dello sfocato.
Tutti gli articoli Tutte le news

Vai al Forum
Discussione Chiusa
 
Strumenti
Old 10-10-2009, 18:18   #101
birmarco
Senior Member
 
L'Avatar di birmarco
 
Iscritto dal: Mar 2008
Città: Milano; 9 Vendite concluse -> Wilde; emmepi; Homerj81; cos1950; mariotanza; Benia; grigor; alekia; ARG0
Messaggi: 11160
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...)
birmarco è offline  
Old 10-10-2009, 18:53   #102
bjt2
Senior Member
 
L'Avatar di bjt2
 
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6793
Quote:
Originariamente inviato da capitan_crasy Guarda i messaggi
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...
__________________
0 A.D. React OS
La vita è troppo bella per rovinarsela per i piccoli problemi quotidiani...
IL MIO PROFILO SOUNDCLOUD! IL MIO CANALE YOUTUBE!
bjt2 è offline  
Old 10-10-2009, 20:46   #103
Pihippo
Senior Member
 
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
Quote:
Originariamente inviato da bjt2 Guarda i messaggi
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à.
__________________
Amore mio, forza ed onore, io sono nel cuore tuo. Insieme ce la possiamo fare, a vincere questa battaglia per la vita

Ultima modifica di Pihippo : 10-10-2009 alle 20:50.
Pihippo è offline  
Old 11-10-2009, 11:23   #104
Pihippo
Senior Member
 
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
Quote:
Originariamente inviato da Pihippo Guarda i messaggi
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..
__________________
Amore mio, forza ed onore, io sono nel cuore tuo. Insieme ce la possiamo fare, a vincere questa battaglia per la vita
Pihippo è offline  
Old 11-10-2009, 16:02   #105
bjt2
Senior Member
 
L'Avatar di bjt2
 
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6793
Quote:
Originariamente inviato da Pihippo Guarda i messaggi
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...
__________________
0 A.D. React OS
La vita è troppo bella per rovinarsela per i piccoli problemi quotidiani...
IL MIO PROFILO SOUNDCLOUD! IL MIO CANALE YOUTUBE!
bjt2 è offline  
Old 11-10-2009, 16:57   #106
Pihippo
Senior Member
 
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
Quote:
Originariamente inviato da bjt2 Guarda i messaggi
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.
__________________
Amore mio, forza ed onore, io sono nel cuore tuo. Insieme ce la possiamo fare, a vincere questa battaglia per la vita
Pihippo è offline  
Old 11-10-2009, 21:44   #107
bjt2
Senior Member
 
L'Avatar di bjt2
 
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6793
Quote:
Originariamente inviato da Pihippo Guarda i messaggi
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...
__________________
0 A.D. React OS
La vita è troppo bella per rovinarsela per i piccoli problemi quotidiani...
IL MIO PROFILO SOUNDCLOUD! IL MIO CANALE YOUTUBE!
bjt2 è offline  
Old 12-10-2009, 00:01   #108
Pihippo
Senior Member
 
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
Quote:
Originariamente inviato da bjt2 Guarda i messaggi
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.
__________________
Amore mio, forza ed onore, io sono nel cuore tuo. Insieme ce la possiamo fare, a vincere questa battaglia per la vita
Pihippo è offline  
Old 12-10-2009, 10:49   #109
bjt2
Senior Member
 
L'Avatar di bjt2
 
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6793
Quote:
Originariamente inviato da Pihippo Guarda i messaggi
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...
__________________
0 A.D. React OS
La vita è troppo bella per rovinarsela per i piccoli problemi quotidiani...
IL MIO PROFILO SOUNDCLOUD! IL MIO CANALE YOUTUBE!
bjt2 è offline  
Old 12-10-2009, 12:16   #110
Pihippo
Senior Member
 
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
Quote:
Originariamente inviato da bjt2 Guarda i messaggi
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
__________________
Amore mio, forza ed onore, io sono nel cuore tuo. Insieme ce la possiamo fare, a vincere questa battaglia per la vita
Pihippo è offline  
Old 12-10-2009, 16:33   #111
bjt2
Senior Member
 
L'Avatar di bjt2
 
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6793
Quote:
Originariamente inviato da Pihippo Guarda i messaggi
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.
__________________
0 A.D. React OS
La vita è troppo bella per rovinarsela per i piccoli problemi quotidiani...
IL MIO PROFILO SOUNDCLOUD! IL MIO CANALE YOUTUBE!
bjt2 è offline  
Old 12-10-2009, 19:34   #112
Pihippo
Senior Member
 
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
Quote:
Originariamente inviato da bjt2 Guarda i messaggi
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?
__________________
Amore mio, forza ed onore, io sono nel cuore tuo. Insieme ce la possiamo fare, a vincere questa battaglia per la vita
Pihippo è offline  
Old 12-10-2009, 20:53   #113
bjt2
Senior Member
 
L'Avatar di bjt2
 
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6793
Quote:
Originariamente inviato da Pihippo Guarda i messaggi
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...
__________________
0 A.D. React OS
La vita è troppo bella per rovinarsela per i piccoli problemi quotidiani...
IL MIO PROFILO SOUNDCLOUD! IL MIO CANALE YOUTUBE!
bjt2 è offline  
Old 12-10-2009, 21:11   #114
gervi
Senior Member
 
L'Avatar di gervi
 
Iscritto dal: May 2003
Città: (Bari) con Furore
Messaggi: 2008
scusate se lo chiedo, ma non 'è ancora il topic

"aspettando sandy bridge di intel" ???

Poichè sarà l'architettura concorrente du bulldozer???
__________________
Macbook Pro 15" Retina Late 2013;iPhone 6s-64GB.
gervi è offline  
Old 12-10-2009, 21:21   #115
capitan_crasy
Senior Member
 
L'Avatar di capitan_crasy
 
Iscritto dal: Nov 2003
Messaggi: 23955
Quote:
Originariamente inviato da gervi Guarda i messaggi
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...
__________________
AMD Ryzen 3600|Thermalright Macho Rev. B|Gigabyte GA-AX370-Gaming 5 (bios F50E)|2x8GB Corsair Vengeance LPX 3200 @ 3200Mhz|1 M.2 NVMe ADATA SX8200PNP 250GB (OS)|1 SSD Crucial MX500 1TB + 1 SSD Crucial MX300 750MB (Games)|1 HDD SEAGATE IronWolf 2TB|Sapphire【RX480 NITRO】8GB|MSI Optix MAG241C [144Hz] + AOC G2260VWQ6 [Freesync Ready]|Corsair CS 750M|Case In Win 509|Fans By Noctua
capitan_crasy è offline  
Old 12-10-2009, 21:24   #116
Pihippo
Senior Member
 
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
Quote:
Originariamente inviato da bjt2 Guarda i messaggi
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ù
__________________
Amore mio, forza ed onore, io sono nel cuore tuo. Insieme ce la possiamo fare, a vincere questa battaglia per la vita
Pihippo è offline  
Old 13-10-2009, 08:57   #117
bjt2
Senior Member
 
L'Avatar di bjt2
 
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6793
Quote:
Originariamente inviato da Pihippo Guarda i messaggi
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...
__________________
0 A.D. React OS
La vita è troppo bella per rovinarsela per i piccoli problemi quotidiani...
IL MIO PROFILO SOUNDCLOUD! IL MIO CANALE YOUTUBE!
bjt2 è offline  
Old 13-10-2009, 11:01   #118
Pihippo
Senior Member
 
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
Quote:
Originariamente inviato da bjt2 Guarda i messaggi
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.
__________________
Amore mio, forza ed onore, io sono nel cuore tuo. Insieme ce la possiamo fare, a vincere questa battaglia per la vita
Pihippo è offline  
Old 13-10-2009, 14:40   #119
bjt2
Senior Member
 
L'Avatar di bjt2
 
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6793
Quote:
Originariamente inviato da Pihippo Guarda i messaggi
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...
__________________
0 A.D. React OS
La vita è troppo bella per rovinarsela per i piccoli problemi quotidiani...
IL MIO PROFILO SOUNDCLOUD! IL MIO CANALE YOUTUBE!
bjt2 è offline  
Old 16-10-2009, 11:34   #120
capitan_crasy
Senior Member
 
L'Avatar di capitan_crasy
 
Iscritto dal: Nov 2003
Messaggi: 23955
APU Llano: Primi passi verso le GPU con tecnologia produttiva SOI!

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...
__________________
AMD Ryzen 3600|Thermalright Macho Rev. B|Gigabyte GA-AX370-Gaming 5 (bios F50E)|2x8GB Corsair Vengeance LPX 3200 @ 3200Mhz|1 M.2 NVMe ADATA SX8200PNP 250GB (OS)|1 SSD Crucial MX500 1TB + 1 SSD Crucial MX300 750MB (Games)|1 HDD SEAGATE IronWolf 2TB|Sapphire【RX480 NITRO】8GB|MSI Optix MAG241C [144Hz] + AOC G2260VWQ6 [Freesync Ready]|Corsair CS 750M|Case In Win 509|Fans By Noctua
capitan_crasy è offline  
 Discussione Chiusa


Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella nostra video anteprima! Samsung Galaxy S21, S21+ S21 Ultra: eccoli nella...
ASUS ZenBook Duo UX482: due schermi e tanta autonomia ASUS ZenBook Duo UX482: due schermi e tanta auto...
Sony FE 35mm F1.4 GMaster, grande risoluzione e sfocato eccellente. La recensione Sony FE 35mm F1.4 GMaster, grande risoluzione e ...
Motorola moto g 5G: vincente per l’autonomia incredibile! La recensione Motorola moto g 5G: vincente per l’autonomia inc...
Elgato 4K60 Pro: come registrare gameplay di qualità su PS5 e Xbox Series X Elgato 4K60 Pro: come registrare gameplay di qua...
La 'talpa' fallisce: la NASA rinuncia a ...
2020, uno degli anni più caldi mai regis...
Samsung Galaxy Fit2, è un'ottima ...
Nasce Stellantis, da oggi effettiva la f...
Corsair 5000, ancora più spazio p...
OneDrive, nuovo limite per il caricament...
Cyberpunk 2077: lavori a pieno regime so...
The Medium: nuovo trailer live action, a...
Il MIT ha ideato un aereo ibrido-elettri...
Audi, BMW, Ford: lo smartphone sar&agrav...
Toyota: negli USA multa da 180 milioni d...
Avira fa il punto sulle minacce informat...
Le novità di S-Mart per il 2021, ...
WhatsApp e privacy: non più 8 febbraio, ...
Amazon, weekend di sconti pazzi: Echo Do...
BurnAware Premium
BurnAware Free
K-Lite Codec Pack Update
K-Lite Mega Codec Pack
K-Lite Codec Pack Full
IObit Uninstaller
IObit Smart Defrag
Opera Portable
3DMark
Opera 73
Prime95
CCleaner Portable
CCleaner Standard
Advanced SystemCare
IrfanView
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 08:32.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Served by www2v