|
|
|
|
Strumenti |
10-10-2009, 17:18 | #101 |
Senior Member
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...)
|
10-10-2009, 17:53 | #102 | |
Senior Member
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6794
|
Quote:
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! IL MIO PLUGIN VST! |
|
10-10-2009, 19:46 | #103 | |
Senior Member
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
|
Quote:
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 19:50. |
|
11-10-2009, 10:23 | #104 | |
Senior Member
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
|
Quote:
__________________
Amore mio, forza ed onore, io sono nel cuore tuo. Insieme ce la possiamo fare, a vincere questa battaglia per la vita |
|
11-10-2009, 15:02 | #105 | |
Senior Member
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6794
|
Quote:
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! IL MIO PLUGIN VST! |
|
11-10-2009, 15:57 | #106 | |
Senior Member
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
|
Quote:
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 |
|
11-10-2009, 20:44 | #107 | |
Senior Member
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6794
|
Quote:
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! IL MIO PLUGIN VST! |
|
11-10-2009, 23:01 | #108 | |
Senior Member
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
|
Quote:
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 |
|
12-10-2009, 09:49 | #109 | |
Senior Member
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6794
|
Quote:
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! IL MIO PLUGIN VST! |
|
12-10-2009, 11:16 | #110 | |
Senior Member
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
|
Quote:
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 |
|
12-10-2009, 15:33 | #111 | |
Senior Member
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6794
|
Quote:
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! IL MIO PLUGIN VST! |
|
12-10-2009, 18:34 | #112 | |
Senior Member
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
|
Quote:
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 |
|
12-10-2009, 19:53 | #113 | |
Senior Member
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6794
|
Quote:
__________________
0 A.D. React OS La vita è troppo bella per rovinarsela per i piccoli problemi quotidiani... IL MIO PROFILO SOUNDCLOUD! IL MIO CANALE YOUTUBE! IL MIO PLUGIN VST! |
|
12-10-2009, 20:11 | #114 |
Senior Member
Iscritto dal: May 2003
Città: (Bari) con Furore
Messaggi: 2014
|
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. |
12-10-2009, 20:21 | #115 |
Senior Member
Iscritto dal: Nov 2003
Messaggi: 24165
|
Lascio ad altri l'onore di aprire e gestire il thread su Sandybridge...
__________________
AMD Ryzen 5600X|Thermalright Macho Rev. B|Gigabyte B550M AORUS PRO-P|2x16GB G.Skill F4-3200C16D-32GIS Aegis @ 3200Mhz|1 M.2 NVMe SK hynix Platinum P41 1TB (OS Win11)|1 M.2 NVMe Silicon Power A60 2TB + 1 SSD Crucial MX500 1TB (Games)|1 HDD SEAGATE IronWolf 2TB|Sapphire【RX6600 PULSE】8GB|MSI Optix MAG241C [144Hz] + AOC G2260VWQ6 [Freesync Ready]|Enermax Revolution D.F. 650W 80+ gold|Case In Win 509|Fans By Noctua|¦ |
12-10-2009, 20:24 | #116 | |
Senior Member
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
|
Quote:
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 |
|
13-10-2009, 07:57 | #117 | |
Senior Member
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6794
|
Quote:
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! IL MIO PLUGIN VST! |
|
13-10-2009, 10:01 | #118 | |
Senior Member
Iscritto dal: Sep 2008
Città: Provincia di reggio, costa dei gelsomini :D
Messaggi: 1691
|
Quote:
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 |
|
13-10-2009, 13:40 | #119 | |
Senior Member
Iscritto dal: Apr 2005
Città: Napoli
Messaggi: 6794
|
Quote:
__________________
0 A.D. React OS La vita è troppo bella per rovinarsela per i piccoli problemi quotidiani... IL MIO PROFILO SOUNDCLOUD! IL MIO CANALE YOUTUBE! IL MIO PLUGIN VST! |
|
16-10-2009, 10:34 | #120 |
Senior Member
Iscritto dal: Nov 2003
Messaggi: 24165
|
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 5600X|Thermalright Macho Rev. B|Gigabyte B550M AORUS PRO-P|2x16GB G.Skill F4-3200C16D-32GIS Aegis @ 3200Mhz|1 M.2 NVMe SK hynix Platinum P41 1TB (OS Win11)|1 M.2 NVMe Silicon Power A60 2TB + 1 SSD Crucial MX500 1TB (Games)|1 HDD SEAGATE IronWolf 2TB|Sapphire【RX6600 PULSE】8GB|MSI Optix MAG241C [144Hz] + AOC G2260VWQ6 [Freesync Ready]|Enermax Revolution D.F. 650W 80+ gold|Case In Win 509|Fans By Noctua|¦ |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 23:32.