64 bit

[Unrue]

I nuovi processori a 64 bit hanno il grande vantaggio di poter indirizzare una memoria di 2^64 indirizzi anzichè 2^32, ovvero circa 4,2 gb. Ma è solo questo il vantaggio, seppur notevole? Cosa cambia per esempio nelle istruzioni che elabora il processore rispetto a quelle a 32 bit? E comunque attualmente non credo esistano applicativi a 64 bit, oppure si? Ma gli applicativi a 64 bit che vantaggi hanno rispetto a quelli a 32 bit?

[OverClocK79®]

quello da te elencato è uno degli aspetti in +

diciamo che ce ne sono anke altri
come eseguire + istruzioni nel medesimo ciclo di cloc....
però servono sia SO che programmi a 64bit

ankora nn si sanno gli effettivi guadagni di questi 64bit
in quanto nn è una implementazione totale ma parziale....

quindi aspettiamo i primi so benk ecc ecc

BYEZZZZZZZZZZZZZ

[Unrue]

Originariamente inviato da OverClocK79®
come eseguire + istruzioni nel medesimo ciclo di cloc....

BYEZZZZZZZZZZZZZ

Ma per fare questo non è necessario un dual core? Come fa un singolo core ad eseguire piu' istruzioni per volta? Infatti non ho capito come fa la Intel con l'Hyper threading.

[OverClocK79®]

l'hyperTreading se nn sbaglio sfrutta le 2 ALU che ha il P4
come se fossero 2 CPU

mentre per il discorso 64 bit
sono proprio i 32 bit in + che gli permettono di eseguire + dati nello stesso ciclo di clock

cmq ripeto
per ora finkè nn abbiamo benk e apllicativi stiamo solo valutando su carta quello che possono fare

BYEZZZZZZZZZZZZZZZ

[Unrue]

Originariamente inviato da OverClocK79®
l'hyperTreading se nn sbaglio sfrutta le 2 ALU che ha il P4
come se fossero 2 CPU

Quindi, correggimi se sbaglio, puo' eseguire al massimo due istruzioni per volta? Ma allora che differenza c'e' con il dual core?

[zappy]

Originariamente inviato da Unrue
I nuovi processori a 64 bit hanno il grande vantaggio di poter indirizzare una memoria di 2^64 indirizzi anzichè 2^32, ovvero circa 4,2 gb. Ma è solo questo il vantaggio, seppur notevole? Cosa cambia per esempio nelle istruzioni che elabora il processore rispetto a quelle a 32 bit? E comunque attualmente non credo esistano applicativi a 64 bit, oppure si? Ma gli applicativi a 64 bit che vantaggi hanno rispetto a quelli a 32 bit?

quello dei 4Gb è il meno... a ce servono? poco o nulla x il 99.9% degli utenti.
Piuttosto il raddoppio dei registri generali del processore (da 8 a 16) consente di avere programmi + veloci ed efficenti (xchè sono compilati con meno istruzioni). Sempre che *qualche* soft-house non ne approfitti x creare sw + pachidermico...

ps linux è già sui 64bit. purtroppo IMHO le distro si stanno adeguando al gigantismo M$...

[AnonimoVeneziano]

Guardate che 4Gb erando indirizzabili con gli attuali registri a 32 Bit , infatti 2^32 è uguale a 4294967296 bytes , ossia 4 GB , mentre 2^64 è uguale a 18446744073709551616 bytes che è uguale a un boldello di GB


Comunque il vantaggio nei 64bit sta nei calcoli dove si usano numeri + grossi di 32bit (+ grossi di(unisgned) 4294967296 o di (signed)+/-214748648 ) , magari nelle normali applicazioni desktop di calcoli di questo tipo non se ne trovano , ma in gestione di grossi database e altre tipologie di calcoli sia la memoria superiore a 4GB che i registri a 64bit sono molto di aiuto .

Credo che lo stesso database di questo server abbia problemi con "solo" 4GB di memoria ram .

Per quanto riguarda noi desktop , come già detto, un vantaggio maggiore in prestazione può derivare dall' ottimizzazione delle istruzioni sull'athlon64 e all'aumento del numero di registri che, se ben sfruttato da compilatori e programmatori, può essere veramente un ottimo colpo

Ciao

[Goldrake_xyz]

Se è vero che nei calcoli matematici su interi, non
è molto frequente incontrare numeri così grandi (a 64 bit),
è altrettanto vero che un Floating point può venire caricato
in una sola volta nel registro di CPU, e questo determina
una notevole velocità di calcolo, ma soprattutto un aumento di precisione !
Anche il lavoro di modifica o trasferimento di più byte, avviene
in metà tempo se si usano registri a 64 Bit.

Quindi a parità di clock, un processore 64 bit è il
doppio più veloce di uno a 32 bit, ma questo solo se
il programma lo permette.


ciao.

[AnonimoVeneziano]

Originariamente inviato da Goldrake_xyz
Se è vero che nei calcoli matematici su interi, non
è molto frequente incontrare numeri così grandi (a 64 bit),
è altrettanto vero che un Floating point può venire caricato
in una sola volta nel registro di CPU, e questo determina
una notevole velocità di calcolo, ma soprattutto un aumento di precisione !

Tutto questo sarebbe corretto se la FPU non avesse già i suoi registri .

Dal Pentium la FPU integrata contiene 8 registri propri a 80 bit di precisione da usare per i calcoli in virgola mobile , e che io sappia negli A64 questi non sono cambiati (sono sempre a 80bit ) , perciò non ci sarebbe nessun vantaggio nei calcoli in virgola mobile.

Anche il lavoro di modifica o trasferimento di più byte, avviene
in metà tempo se si usano registri a 64 Bit.

Quindi a parità di clock, un processore 64 bit è il
doppio più veloce di uno a 32 bit, ma questo solo se
il programma lo permette.

Qui non ho capito quello che hai scritto.

Il trasferimento? Cosa intendi? Sul BUS di sistema? Se è quello non c'entra con il fatto che il processore sia a 64bit , e anche la faccenda della modifica dei byte non l'ho capita , perchè le istruzioni che modificano o spostano byte da un registro ad un altro dovrebbero utilizzare meno cicli di clock se usate in registri + ampi?


Ciao

[Goldrake_xyz]

Allora, i registri a 80bit del processore matematico, sono
configurati come un ring stack, e su questi registri non puoi
eseguire le instruzioni del processore principale.
Quindi il dato a 80 bit Float deve venire convertito a 64 bit Float,
e solo a questo punto, può essere elaborato in un solo colpo di
clock in un registro del processore.

Per il secondo caso se devi fare, ad esempio uno AND logico
su 8 Byte, lo fai con un' istruzione sola se hai reg. a 64 bit ,
o lo fai 2 volte se hai registri a 32 bit, o lo fai 4 volte se hai
registri a 16 bit ... ecc. ecc. chiaro no ?


Ciao.

[AnonimoVeneziano]

Originariamente inviato da Goldrake_xyz
Allora, i registri a 80bit del processore matematico, sono
configurati come un ring stack, e su questi registri non puoi
eseguire le instruzioni del processore principale.
Quindi il dato a 80 bit Float deve venire convertito a 64 bit Float,
e solo a questo punto, può essere elaborato in un solo colpo di
clock in un registro del processore.

Scusa, magari sono poco informato io , ma sta roba dove sta scritta? Dov'è che l'hai letto?

CHe io sappia la FPU fa tutti i suoi calcoli indipendentemente dalle altre unità logiche presenti nel core del processore , e con i suoi registri si fa i suoi calcoli in proprio e in parallelo con l'unità ad interi , non deve mica usare i registri dell' unità ad interi per calcolare (sennò i propri registri che li ha a fare? ) . Se mi sbaglio spiega con + precisione che si è capito ancora poco di quello che volevi intendere che è un argomento che mi interessa

Per il secondo caso se devi fare, ad esempio uno AND logico
su 8 Byte, lo fai con un' istruzione sola se hai reg. a 64 bit ,
o lo fai 2 volte se hai registri a 32 bit, o lo fai 4 volte se hai
registri a 16 bit ... ecc. ecc. chiaro no ?


Ciao.

Questo sempre parlando di interi però

[jappilas]

Originariamente inviato da Unrue
Ma per fare questo non è necessario un dual core? Come fa un singolo core ad eseguire piu' istruzioni per volta? Infatti non ho capito come fa la Intel con l'Hyper threading.

il dual core è come avere due procesori gemelli... solo che si riesce a integrarli su un singolo quadrato di silicio

HT invece è un' "espansione" che permette a un processore che implementa una pipeline singola, di tenere traccia di due diversi flussi di istruzioni (appartenenti appunto a due thread) : quello che occorre è avere la nozione di due "stati cpu" contemporaneamente, infatti i set dei registri (8 interi , 8 floating point , le flag ecc) sono duplicati

Originariamente inviato da OverClocK79®
l'hyperTreading se nn sbaglio sfrutta le 2 ALU che ha il P4
come se fossero 2 CPU

il p4 sfrutta le due alu intere, non tanto "come se fossero 2 cpu" ma spingendo solo quelle (che sono le alu per le istruzioni semplici, quindi coem numero di transistor, relativamente pochi) al doppio della frequenza del resto della cpu (3 ghz -> le alu vanno a 6 ghz)

il discorso è che: tramite questo raddoppio, è come se il p4 avesse 4 alu intere, ma siccome le istr x 86 non producono granchè di parallelismo interno, lcapitano dei cicli in cui e alu rimarrebbero inattive
se ho attivi due flussi di istruzioni contemporaneamente, c' è un maggior probabilità di tenerle occupate, sfruttando la capacità dello scheduler

[Goldrake_xyz]

Originariamente inviato da AnonimoVeneziano
CHe io sappia la FPU fa tutti i suoi calcoli indipendentemente dalle
altre unità logiche presenti nel core del processore , e con i suoi
registri si fa i suoi calcoli in proprio e in parallelo con l'unità ad
interi , non deve mica usare i registri dell' unità ad interi per
calcolare (sennò i propri registri che li ha a fare? ) . Se mi sbaglio
spiega con + precisione che si è capito ancora poco di quello che volevi intendere che è un argomento che mi interessa

Si, la FPU ha i suoi registri (ring stack) e le sue istruzioni,
che sono chiaramente rivolte al calcolo matematico in Float P.
Una volta finiti i calcoli il dato deve essere anche usato,
ad esempio per "stamparlo a video" oppure per determinare
dei punti su un disegno (tipicamente CAD).
Siccome le istruzioni del processore principale possono essere
usate solo sui suoi registri, EAX, EBX ... ecc. ecc.
allora bisogna trasferire i dati da registro FPU a registro CPU ...!
è chiaro che 80 bit sono troppo lunghi ...
A questo punto c'è un' istruzione che converte il dato 80 bit FP e
lo manda in memoria nel formato 64 bit FP (o 32 bit FP)
Pronto x essere prelevato da un registro di CPU.

Questo sempre parlando di interi però

Si e no..., cioè il byte in sè stesso può significare, un inero,
un carattere, un istruzione macchina, un colore di un pixel,
ecc.ecc.
e su questo byte o word=2byte o dword=4byte(32 bit).....
si possono compiere molti tipi di operazioni, quali quelle
di tipo logico AND, OR, XOR, ecc,ecc.
Il byte può essere anche comparato con altri, ad esempio
per ricercare un testo in un documento, e se si hanno reg.
a 64 bit è il doppio più veloce di 32 bit !

Ciao, a presto.

[cionci]

Concordo con Goldrake_xyz... Uno dei vantaggi è sicuramente quello...

Ovviamente il vantaggio principale sta negli algoritmi che già ora richiedono interi a 64 bit e che con i 32 bit vengono similuati lavorando con due registri... In questi casi l'aumento di prestazioni può anche superare il 100%... Esempi di queste applicazioni sono algoritmi codifica e decodifica...algoritmi per il criptaggio...algoritmi di compressione...database e tanti altri...

Anche nelle stesse API di Windows sono frequenti chiamati due DWORD (32 bit) che poi venogno trattate come un solo intero a 64 bit... In tal caso anche gli stessi programmi a 32 bit, senza essere ricompilati, ma adattati dal layer apposito alle API a 64 bit ne trarranno grossi vantaggi...

Secondo me c'è una cosa che molti hanno trascurato...
Un tempo quando le CPU non avevano un coprocessore matematico che effettuava le operazioni floating point (fino al 386), le operazioni floating point venivano simulate con gli interi a 32 bit (virgola fissa)... Questo però garantiva una scarsa precisione...
Ora, volendo, 64 bit per un calcolo in virgola fissa cominciano ad essere molti e secondo me una reintroduzione di questo vecchio metodo in algoritmi che non necessitano di una grande precisione (algoritmi che partono da interi ed arrivano ad interi, ma con prodotti intermedi non interi) potranno subire un aumento di prestazioni pari a qualcosa come il 200 o 300% se non di più...

Ah...un altro vantaggio dell'architettura a 64 bit,così come introdotta da AMD, è l'introduzione di ulteriori 8 registri a 64 bit...
Questo comporterà un minore uso dello stack e per questo un riasparmio di bandwidth con la memoria...

[cionci]

Riguado al software... Per Windows c'è ancora poco o nulla...visto che non sono ancora stati rilasciati XP e Server 2003 per Athlon 64...
Se si guarda dal punto di vista Linux...ci sono già un paio di distribuzioni a 64 bit...e poi, visto che la maggior parte dei programmi Linux viene fornita con il codice sorgente, basta una ricompilata...certe volte senza nemmeno troppi sforzi per adattare ilc odice ai 64 bit

[riaw]

il problema del limite massimo dei 4 giga non è un problema.
innanzi tutto non possiamo dire ADESSO se tra un po avremo bisogno di 4 giga o più di ram.
chi lo avrebbe mai detto due anni fa che lo standard per i pc sarebbe stato avere mezzo giga?
al tempo del p133 lo standard era 16mega, quindi vedete voi, se proseguiamo linearmente i 4 giga di ram saranno necessari molto prima di quello che pensate
ma per avere più di 4 giga non è necessario un processore a 64bit

[AnonimoVeneziano]

Originariamente inviato da Goldrake_xyz
Si, la FPU ha i suoi registri (ring stack) e le sue istruzioni,
che sono chiaramente rivolte al calcolo matematico in Float P.
Una volta finiti i calcoli il dato deve essere anche usato,
ad esempio per "stamparlo a video" oppure per determinare
dei punti su un disegno (tipicamente CAD).
Siccome le istruzioni del processore principale possono essere
usate solo sui suoi registri, EAX, EBX ... ecc. ecc.
allora bisogna trasferire i dati da registro FPU a registro CPU ...!
è chiaro che 80 bit sono troppo lunghi ...
A questo punto c'è un' istruzione che converte il dato 80 bit FP e
lo manda in memoria nel formato 64 bit FP (o 32 bit FP)
Pronto x essere prelevato da un registro di CPU.

Ah, effettivamente non avevo pensato a questo

Ciao

[cionci]

Originariamente inviato da riaw
ma per avere più di 4 giga non è necessario un processore a 64bit

Ed invece sì...perchè gli altri metodi (PAE ad esempio) sono complessi da utilizzare per il sistema operativo e sono uno spreco estremo di risorse...

[riaw]

Originariamente inviato da cionci
Ed invece sì...perchè gli altri metodi (PAE ad esempio) sono complessi da utilizzare per il sistema operativo e sono uno spreco estremo di risorse...

rimane il fatto che se l'obbiettivo era usare più di 4 giga di ram allora non serviva creare un processore a 64bit, quindi l'obbiettivo sta da un'altra parte

[jappilas]

Originariamente inviato da riaw
rimane il fatto che se l'obbiettivo era usare più di 4 giga di ram allora non serviva creare un processore a 64bit, quindi l'obbiettivo sta da un'altra parte

intendi che non ne servivano 64, perchè 2^64 bytes di memoria indirizzabile è fin troppo, e magari bastavano chessò, 40 bit?