Chipset SiS per Hammer: nuovi dettagli emergono

[Redazione di Hardware Upg]

Link alla notizia: http://news.hwupgrade.it/8771.html

Anche SiS prepara nuove armi per il 2003, anno importante per AMD con il lancio delle prime cpu x86-64

Click sul link per visualizzare la notizia.

[SENTINELLA]

Speriamo arrivi presto Hammer...

[Silvia]

Come sopra....

[Sig. Stroboscopico]

l'unico peccato è che amd non ha intenzione di fare a gara per il clock + alto con intel... in questo modo mi sa che nel prossimo anno non vedremo una crescita esponenziale come negli ultimi due anni... con uno stabilizzarsi dei pc di fascia + alta.

sigh!

secondo me i vantaggi più grandi dell'hammer saranno prima di tutto il passaggio dell'attuale athlon a 32 bit a fascia new entry (athlon 32 bit con prezzi celeron) e poi l'avvio alla migrazione da sistemi 32 bit a quelli 64 bit (con un bel incentivo nell'investimento per la creazione di nuove versioni di programmi).

quindi pc di fascia bassa estremamante più performanti

^__-

ciao!

[SENTINELLA]

Mi sembra proprio che la corsa al clock più alto si sia arrestata. Nei prossimi due anni i sistemi a 64 bit spodesteranno quelli a 32. Vedremo come reagirà Intel e AMD

[atragon]

--Nei prossimi due anni i sistemi a 64 bit spodesteranno quelli a 32. --

Non ne sono tanto sicuro...innanzitutto perchè le versioni dei principali applicativi (Windows.Net / LongHorn, Office, Visual Studio, Delphi, Oracle...tanto per citarne alcuni) sono già previsti per quanto riguarda gli immediati sviluppi futuri, nelle versioni a 32 bit e questa architettura prospererà ancora per un bel pezzo...poi perchè bisogna vedere come Intel entrerà nel mondo 64 bit; bisogna tenere presente che se Intel tenterà di spingere verso il basso l'architettura Itanium ci saranno 2 diverse implementazioni delle architetture 64bit, con conseguenti casini anche a livello di codice compilato, nel senso che ci vorrà un po' di tempo prima di avere stabilità a livello di prodotti. Certo, se Hammer / Opteron dovessero fare il vuoto sul mercato le cose potrebbero anche subire una svolta imprevista....

[bicco]

cmq con tutti i numeri che sono disponibili,lo dovevano chiamare proprio con lo stesso numero del vecchio chipset amd760??

[magomerlinopaolo]

comunque sia una cosa che mi sembra certa è che il futuro ci promette non una corsa ai Ghz, ma una ottimizzazione sempre + raffinata dei processori, qualsiasi sia il tipo di 64bit che la spunterà...

[bs82]

in questi giorni sto studiando il funzionamneto delle cpu a 16 bit vs quelle a 32. il codice a 16 bit eseguito su cpu a 32 risulta essere eseguito in modo più veloce perchè non occupa per intero i registri eliminando gli errori di overflow. Lo stesso vale per il passaggio da 32 a 64. Poi esiste il fatto che i registri di una cpu a 32 bit sono parzilamente ortogonali (ossia quasi tutti possono essere usati per qualsiasi operazione di tipo diverso). I registri sono la parte più importante del processore dove tutta l'elaborazione dei datai avviene. Un proc a 64 bit avrà sicuramente una ortogonalità completa dei registri rendendo più facile l'uso del linguaggio macchina. Con questo tipo di registri un software a 32bit occupera relativamente la metà di memoria che occupava su un proc a 32bit e le operazioni su di esso avverrano più velocemente (sarebbe meglio dire con meno latenze). Ovviamente chi ha linux beneficerà maggiormente del passaggio a 64 perchè potrà ricompilare ogni software a 64 bit.
Il futuro sono i 64 bit. Da notare che le directx saranno compatibili a 64bit...il che vuol dire maggior precisione nei calcoli 3d, miglior calcolo in virgola mobile ecc....
Inoltre un software compilato a 64 bit occupa meno spazio di uno compilato a 32 bit! infatti se prima facevo una somma con dei numeri che erano maggiori di 32bit dovevo dividerli in più parti e poi sommarle (per esempio 5 istruzioni); con un proc a 64bit posso fare lo stesso conto con due sole istruzioni. Lo so è un esempio del ca**o....ma è vero! Se qualcuno sa usare l'assembler può comfermare!

[cdimauro]

Originariamente inviato da bs82
[b]in questi giorni sto studiando il funzionamneto delle cpu a 16 bit vs quelle a 32. il codice a 16 bit eseguito su cpu a 32 risulta essere eseguito in modo più veloce perchè non occupa per intero i registri eliminando gli errori di overflow.

Dipende dall'implementazione. Prima di tutto che ci sia overflow o meno, non è di alcuna rilevanza, perché i flag vengono comunque aggiornati in un certo stadio della pipeline.

Inoltre, in genere, si verifica proprio il contrario di quello che hai scritto: il codice a 16 bit, eseguito su una CPU a 32 bit, viene eseguito più lentamente. Come ho già detto, dipende dall'implementazione. Infatti il PentiumPro era veramente scarso nell'esecuzione di codice (e istruzioni in generale) a 16 bit.

[b]

Lo stesso vale per il passaggio da 32 a 64.

Vedi sopra...

[b]

Poi esiste il fatto che i registri di una cpu a 32 bit sono parzilamente ortogonali (ossia quasi tutti possono essere usati per qualsiasi operazione di tipo diverso).

Dipende dall'implementazione: se stiamo parlando esclusivamente dell'architettura x86, siamo d'accordo...

[b]

I registri sono la parte più importante del processore dove tutta l'elaborazione dei datai avviene. Un proc a 64 bit avrà sicuramente una ortogonalità completa dei registri rendendo più facile l'uso del linguaggio macchina.

Piu che altro renderà il lavoro più facile ai compilatori: ormai di gente che lavora in assembly ce n'è poca. Col la velocità che s'è raggiunta, non ci sono più tutti quei i vantaggi, perché scrivere codice ottimizzato in assembly richiede MOLTO più tempo rispetto ad un linguaggio ad alto livello, e il tempo è denaro...

L'Hammer, comunque, avrà un'architettura ancora più ortogonale rispetto agli attuali x86 a 32 bit...

[b]

Con questo tipo di registri un software a 32bit occupera relativamente la metà di memoria che occupava su un proc a 32bit e le operazioni su di esso avverrano più velocemente (sarebbe meglio dire con meno latenze).

Scusa, ma potresti essere più chiaro? Cosa intendi dire col fatto che occupano metà di memoria? Ti riferisci allo spazio d'indirizzamento? Se è questo, non è che sia tanto importante per un'applicazione: i puntatori vengono sempre gestiti in maniera trasparente, che siano a 32 o 64 bit. Ne possono "risentire" le applicazioni che richiedono molta memoria, come i server, ma questo è un altro discorso...

[b]

Ovviamente chi ha linux beneficerà maggiormente del passaggio a 64 perchè potrà ricompilare ogni software a 64 bit.

Lo stesso si potrà dire per Windows XP/64...

[b]

Il futuro sono i 64 bit.

Su questo non c'è dubbio: giocoforza, causa avanzata tecnologica, i limiti dei 32 bit diventeranno troppo stretti nel giro di 2/3 anni...

[b]

Da notare che le directx saranno compatibili a 64bit...il che vuol dire maggior precisione nei calcoli 3d, miglior calcolo in virgola mobile ecc....

In parte di do ragione, anche se i calcoli in virgola mobile sono già a 64 bit, per cui per l'FPU il passaggio da 32 a 64 bit non comporterà nessun cambiamento.

Il cambiamento vero sarà dato dalla possibilità, per l'ALU, di poter muovere dati a 64 bit con l'FPU in modo molto semplice, visto che finalmente potranno "dialogare" usando quantità della stessa dimensione...

[b]

Inoltre un software compilato a 64 bit occupa meno spazio di uno compilato a 32 bit!

Falso: il codice a 64 occuperà un 5-10% (dipende dall'applicazione) in più di spazio proprio a causa dei nuovi prefissi che saranno necessari per accedere ai 64 bit (non in tutti i casi) e ai nuovi registri (in tutti i casi). Parlo dell'Hammer, ovviamente. Però i vantaggi prestazionali della nuova architettura annulleranno del tutto la maggior dimensione del codice richiesta...

[b]

infatti se prima facevo una somma con dei numeri che erano maggiori di 32bit dovevo dividerli in più parti e poi sommarle (per esempio 5 istruzioni); con un proc a 64bit posso fare lo stesso conto con due sole istruzioni. Lo so è un esempio del ca**o....ma è vero! Se qualcuno sa usare l'assembler può comfermare!

Posso confermare, come pure confermo che utilizzare somme a 64 bit è un evento più raro, nella programmazione di tutti i giorni, rispetto a quelle a 32 bit...