64 bit [Archivio] - Hardware Upgrade Forum

zappy

23-06-2004, 12:40

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... :rolleyes:

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

AnonimoVeneziano

23-06-2004, 13:33

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 :p

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

23-06-2004, 19:21

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

23-06-2004, 20:08

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

23-06-2004, 20:43

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

23-06-2004, 21:51

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? :confused:

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

23-06-2004, 22:12

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

24-06-2004, 20:59

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 ...:D
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...:D, 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

25-06-2004, 11:21

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

25-06-2004, 11:25

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

25-06-2004, 11:56

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 :D
ma per avere più di 4 giga non è necessario un processore a 64bit ;)

AnonimoVeneziano

25-06-2004, 12:27

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 ...:D
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 :D

Ciao

cionci

25-06-2004, 14:27

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

25-06-2004, 14:44

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

25-06-2004, 15:08

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? :confused:

cionci

25-06-2004, 15:11

Ovviamente non era solamente quello l'obiettivo, ma è sicuramente uno dei princiapali... Per il utilizzare il PAE bisogna progettare hardware e software ad hoc...quindi, non solo è lento, ma anche non economicamente vantaggioso !!!
Con una CPU a 64 bit non c'è alcun bisogno di fare questi sforzi...

Quanti di voi hanno 1 Gb di Ram sul proprio PC ? Quanti professionisti ne hanno due sulle proprie workstation ? Qaunti server hanno 4 Gb di Ram ?
Siamo vicini a questo limite ed il PAE sicuramente non era il modo per superarlo...

cionci

25-06-2004, 15:13

Originariamente inviato da jappilas
intendi che non ne servivano 64, perchè 2^64 bytes di memoria indirizzabile è fin troppo, e magari bastavano chessò, 40 bit? :confused:
La massima quantità di memoria fisica indirizzabile da AMD64 è comunque 2^40 ;) 1 TeraByte... Conil PAE se nons baglio 2^48...

riaw

25-06-2004, 15:25

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

no, intendo che anche con i processori a 32 bit è possibile indirizzare più di 4 giga di ram, quindi il passaggio ai 64 non è strettamente necessario, almeno non è solo quello l'obbiettivo ;)

riaw

25-06-2004, 15:26

Originariamente inviato da cionci
Ovviamente non era solamente quello l'obiettivo, ma è sicuramente uno dei princiapali... Per il utilizzare il PAE bisogna progettare hardware e software ad hoc...quindi, non solo è lento, ma anche non economicamente vantaggioso !!!
Con una CPU a 64 bit non c'è alcun bisogno di fare questi sforzi...

Quanti di voi hanno 1 Gb di Ram sul proprio PC ? Quanti professionisti ne hanno due sulle proprie workstation ? Qaunti server hanno 4 Gb di Ram ?
Siamo vicini a questo limite ed il PAE sicuramente non era il modo per superarlo...

infatti, non era il modo per superarlo, ma per metterci una pezza SE la necessità era quella ;)

il mio intervento era solo per chiarire che il passaggio a 64 bit non è STRETTAMENTE NECESSARIO per le macchine che necessitano di più di 4 giga, tutto qua ;)

jappilas

25-06-2004, 15:37

Originariamente inviato da cionci
La massima quantità di memoria fisica indirizzabile da AMD64 è comunque 2^40 ;) 1 TeraByte... Conil PAE se nons baglio 2^48...

lo so ;)
amd ha ripreso vari dettagli costruttivi dai progetti di Alpha, per cui i 2^40 byte indirizzabili fisicamente mi suonano conosciuti ;)

sì che 2o me abbiamo ancora un po' di tempo prima che lo standard per i banchi di RAM sia il TB (quanto c' è voluto per passare dal MB al GB? ) ma cmq prevedere più di 32 bit permette di non limitare la crescita dello spazio totale che le applicazioni vedono a disposizione

uhmmm 2^48 mi pare fosse invece lo spazio d' indirizzamento virtuale di itanium, mentre il PAE dello xeon permetterebbe di gestire fino a 64 GB , cioè 2^36, tramite bank switching: che consisterebbe nel partizionare la memoria fisica in tot banchi di dimensione pari allo spazio virtuale, e in ognuno tenere un set di processi e una copia del SO in esecuzione.. la commutazione tra un banco e l' altro è fonte di overhead

riaw

25-06-2004, 15:39

Originariamente inviato da jappilas
lo so ;)
amd ha ripreso vari dettagli costruttivi dai progetti di Alpha, per cui i 2^40 byte indirizzabili fisicamente mi suonano conosciuti ;)

sì che 2o me abbiamo ancora un po' di tempo prima che lo standard per i banchi di RAM sia il TB (quanto c' è voluto per passare dal MB al GB? ) ma cmq prevedere più di 32 bit permette di non limitare la crescita dello spazio totale che le applicazioni vedono a disposizione

uhmmm 2^48 mi pare fosse invece lo spazio d' indirizzamento virtuale di itanium, mentre il PAE dello xeon permetterebbe di gestire fino a 64 GB , cioè 2^36, tramite bank switching: che consisterebbe nel partizionare la memoria fisica in tot banchi di dimensione pari allo spazio virtuale, e in ognuno tenere un set di processi e una copia del SO in esecuzione.. la commutazione tra un banco e l' altro è fonte di overhead

ma lo xeon non era 2^34? cioè 16 giga? o ricordo male?

jappilas

25-06-2004, 15:47

Originariamente inviato da riaw
no, intendo che anche con i processori a 32 bit è possibile indirizzare più di 4 giga di ram, quindi il passaggio ai 64 non è strettamente necessario, almeno non è solo quello l'obbiettivo ;)
sì ma (almeno, con la tecnica usata al momento sugli x86) è un tapullo...
perchè non è la memoria virtuale ad andare oltre i 32 bit, quindi le applicazioni vedono sempre i soliti 4 GB e il kernel del SO è l' unico a conoscenza della reale quantità di celle presente sui moduli dimm
cmq ci sono ambiti dove i 4 GB cominciano a stare stretti, e dove anche 64 GB lo diventerebbero dopo poco tempo
quindi meglio orientarsi verso qualcosa di più nuovo e più facilemte scalabile
Originariamente inviato da riaw
ma lo xeon non era 2^34? cioè 16 giga? o ricordo male?
no si chiama PAE 36 (phisical address extension ) ;)

http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx
PAE maps up to 64 GB of physical memory into a 32-bit (4 GB) virtual address space using either 4-KB or 2-MB pages. The Page directories and the page tables are extended to 8 byte formats, allowing the extension of the base addresses of page tables and page frames to 24 bits (from 20 bits). This is where the extra four bits are introduced to complete the 36-bit physical address. Windows supports PAE with 4-KB pages. PAE also supports a mode where 2-MB pages are supported. Many of the UNIX operating systems rely on the 2 MB-page mode. The address translation is done without the use of page tables (the PDE supplies the page frame address directly).

cionci

25-06-2004, 18:21

Avete visto che il prossimo sistema Quad Opteron di Sun supporta moduli Registered da 4 Gb ciuascuno ?
4 x 16 slot = 64 Gb ;)

Chissà sei mai potremo vedere un sistema con 8 Opteron :confused:

bomber84

26-06-2004, 12:05

Si sa già qualcosa sull'usita del so e delle applicazioni a 64bit?
Io dovrei acuistare un nuovo sistema ma sono indeciso proprio per questo fattore ossia aquistare una cpu con delle nuove istruzioni e non poterle sfruttare. :confused:
Se non ho capito male il primo sistema operativo con istruzioni a 64bit dovrebbe uscire intorno al 2006 o sbaglio?:confused: :mc:

cionci

26-06-2004, 12:14

No, prima...
Linux a 64 bit c'è già da un anno...
Per Windows bisogna aspettare credo fra Settembre e Novembre di questo anno... Ci sono già le varie beta di XP a 64 bit che hanno raggiunto un discreto livello di stabilità...

cionci

26-06-2004, 12:16

khri81

26-06-2004, 14:41

ma una domanda se io metto gentoo su di un athlon 64 e parto dallo stage1 quindi ricompilo tutto, gentoo diventa un os a 64bit oppure no?
cioè tutte le applicazioni che vengono ricompilate su di un athlon 64 diventano a 64 bit?

Slamdunk

26-06-2004, 14:44

Originariamente inviato da cionci
Avete visto che il prossimo sistema Quad Opteron di Sun supporta moduli Registered da 4 Gb ciuascuno ?
4 x 16 slot = 64 Gb ;)Ci manca solo il sistema dual graphic visto al Computex con due X800XT, 10 litri d'acqua per raffreddare il tutto, e puoi farci girare FarCry a 5000x4000 con 300fps fissi :sisi:

AnonimoVeneziano

26-06-2004, 17:48

Originariamente inviato da khri81
ma una domanda se io metto gentoo su di un athlon 64 e parto dallo stage1 quindi ricompilo tutto, gentoo diventa un os a 64bit oppure no?
cioè tutte le applicazioni che vengono ricompilate su di un athlon 64 diventano a 64 bit?

Se imposti il GCC per generare codice a 64bit specifico per AMD64 si.

Ciao

ev8

27-06-2004, 14:53

Originariamente inviato da cionci
Avete visto che il prossimo sistema Quad Opteron di Sun supporta moduli Registered da 4 Gb ciuascuno ?
4 x 16 slot = 64 Gb ;)
Se ti accontenti di PC2100 e case 4U puoi già prenderti questo che non è male
http://h18004.www1.hp.com/products/servers/proliantdl585/index.html

Chissà sei mai potremo vedere un sistema con 8 Opteron :confused:

Mason

28-06-2004, 02:47

non erano necessari i 64 per poter lavorare 2 data da 32 in parallelo in unico registro. le mmx e discententi sono nate per quello.

sinceramente, a parte la possibilita' del parallelismo (cmq penso che mmx sse cazzi e mazzi sia piu efficenti) non vedo molte motivazioni per un proci a 64bit per uso desktop.

con questo non volgio sminure il procio, che da sentito dire viaggia(e ci mancherebbe), pero il fattoche sia buono dipende in primis dalla sua architettura, e in maniera minore dal 64 bit.
il 90% della gente penso che non usi il computer oggi al limite di quei 32 bit, penso che i 64 bit sia stati dettati da un risparmi economico per unificare le tecnologie (opteron e amd64), e naturalmente il marketing penso lo sfruttti quel (64>32)

ricordiamoci che e il primo procio 64 bit per desktop, sicramente non il primo a 64 in assoluto.

zappy

30-06-2004, 12:07

Originariamente inviato da riaw
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 :D
Appunto, bastavano 16mb e si faceva quasi tutto quello che si fa oggi con 512. Questa corsa al gigantismo fine a se stesso IMHO è assurda. Sembra che il sw sia fatto apposta x sperecare + risorse (pagate profumatamente in ? ed in kW) possibile... :rolleyes:

cionci

30-06-2004, 12:52

Originariamente inviato da Mason
non erano necessari i 64 per poter lavorare 2 data da 32 in parallelo in unico registro. le mmx e discententi sono nate per quello.

:confused: e questo chi l'ha detto ? E' possibile fare una cosa del genre, ma fra tutti i controlli che si devono fare si perde ogni vantaggio rpestazionale...
Originariamente inviato da Mason
sinceramente, a parte la possibilita' del parallelismo (cmq penso che mmx sse cazzi e mazzi sia piu efficenti) non vedo molte motivazioni per un proci a 64bit per uso desktop.

Quale parallelismo ? Comunque mmx, sse e C. operano sui floating point ;)
Originariamente inviato da Mason
con questo non volgio sminure il procio, che da sentito dire viaggia(e ci mancherebbe), pero il fattoche sia buono dipende in primis dalla sua architettura, e in maniera minore dal 64 bit.

Certo...infatti la maggior parte della gente lo sta facendo funziona a 32 bit ;)
Originariamente inviato da Mason
il 90% della gente penso che non usi il computer oggi al limite di quei 32 bit, penso che i 64 bit sia stati dettati da un risparmi economico per unificare le tecnologie (opteron e amd64), e naturalmente il marketing penso lo sfruttti quel (64>32)
Penso che primo o poi i 64 bit dovevano essere introdotti... Dopo tutto anche Intel aveva nei propri piani l'introduzione di IA64 nel desktop (doveva avvenire nel 2005, ma, per lo scarso successo di Itanium e la concorrenza di AMD è slittato tutto)...

jappilas

30-06-2004, 13:45

Originariamente inviato da cionci
Comunque mmx, sse e C. operano sui floating point ;)

mmx opera su interi a 8/16/32bit vettorizzati in registri a 64 bit che costituiscono alias dei registri FP (questo per compatibilità a livello sw, ma con lo svantaggio che l' unità mmx e quella fp non avrebbero potuto operare contemporaneamente)

sse aggiunge i nuovi registri xmm a 128 bit, una nuova modalità operativa (unità sse "in parallelo" a quella mmx/fpu) e operava sulle floating point a 16 e 32 bit

sse2 ha esteso l' uso dei registri xmm128 a operazioni su interi anche a 64 e 128 bit (cosa utile in ambito crittografia, tanto è vero che c' è anche un' istruzione di "shuffle" combinatoria) e alle floating point a 32/64 , che così diventano ieee-compliant

cionci

30-06-2004, 14:30

Anche su interi...non mi sembrava...sorry ;)

homero

01-07-2004, 18:51

digital e' di proprietà della intel, che l'ha smantellata.
amd con digital c'entra poco, almeno oggi, ha solo acquistato alcuni brevetti alla fine degli anni '90.

Goldrake_xyz

01-07-2004, 19:03

Originariamente inviato da homero
digital e' di proprietà della intel, che l'ha smantellata.
amd con digital c'entra poco, almeno oggi, ha solo acquistato alcuni brevetti alla fine degli anni '90.

Uhm, per quello che so io , la digital, cioè quella dei vax,
è ora di proprietà HP, basta andare al sito ....
Poi se alcuni ingegneri di digital sono andati in AMD ... non lo sò.

ciao.

jappilas

01-07-2004, 19:20

Originariamente inviato da homero
digital e' di proprietà della intel, che l'ha smantellata.
amd con digital c'entra poco, almeno oggi, ha solo acquistato alcuni brevetti alla fine degli anni '90.

mi risultava (mo' controllo nella caterva di pcweek di quegli anni...) che alla fine degli anni 90, qualcosa del genere:
digital equipment (DEC) fa causa a intel per una presunta violazione di brevetti che la seconda avrebbe indebitamente sfruttao nella realizzazione di pentium pro e II
la causa si risolve in breve tempo con l' acquisto della divisione semiconduttori di digital da parte di intel, che in tal modo subentra a digital all' interno del consorzio Alphaprocessor nella produzione (ma guarda) di cpu Alpha, insieme a mitsubishi (che dopo un po' si chiama fuori) e Samsung, che continua a far uscire il 21264 e prosegue con compaq prima e HP dopo, la ricerca sui '364 e '464
intel, non ha smantellato lei digital: ha incamerato una fabbrica (negli USA) e la produzione di una cosa che le si sta rivelando molto utile... sa1100 anche detto StrongArm...

Goldrake_xyz

01-07-2004, 20:36

Originariamente inviato da jappilas
mi risultava (mo' controllo nella caterva di pcweek di quegli anni...) che alla fine degli anni 90, qualcosa del genere:
digital equipment (DEC) fa causa a intel per una presunta violazione di brevetti che la seconda avrebbe indebitamente sfruttao nella realizzazione di pentium pro e II .....
Vero, letto anch'io, Intel sfruttava Soluzioni RISC di proprietà
Digital, o per lo meno così diceva la digital che gli fece causa ...
Adesso i VAX della digital sono commercializzati da HP,
e quindi presumo che Digital sia stata in seguito inglobata
da HP. (vedere sito HP)
Mah talvolta accadono strane cose ...
e pensare che l'ALPHA era già a 64 bit nel lontano "94...:(

ciao.

jappilas

01-07-2004, 21:08

Originariamente inviato da Goldrake_xyz
Vero, letto anch'io, Intel sfruttava Soluzioni RISC di proprietà
Digital, o per lo meno così diceva la digital che gli fece causa ...
Adesso i VAX della digital sono commercializzati da HP,
e quindi presumo che Digital sia stata in seguito inglobata
da HP. (vedere sito HP)
Mah talvolta accadono strane cose ...
e pensare che l'ALPHA era già a 64 bit nel lontano "94...:(

ciao.

infatti...mentre intel acquisì il silicio di DEC, dopo poco Compaq acquisì le attività riguardanti le linee di macchine server e workstation alpha based ...
quindi Compaq le portò in dote all' operazione di "fusione" con HP...
HP infine , ha recentemente annunciato la cessazione della produzione di macchine alpha e il porting di openvms e true64 unix a Itanium

cionci

02-07-2004, 00:04

Originariamente inviato da jappilas
HP infine , ha recentemente annunciato la cessazione della produzione di macchine alpha e il porting di openvms e true64 unix a Itanium
Guarda caso HP ha collaborato con Intel per la creazione di IA64 ;)

Mason

02-07-2004, 16:25

Originariamente inviato da cionci
:confused: e questo chi l'ha detto ? E' possibile fare una cosa del genre, ma fra tutti i controlli che si devono fare si perde ogni vantaggio rpestazionale...

goldrake aveva citato un operazione tipica su bitmask in cui si poteva vedere un operazione di bit logico su 8 byte come un unica op
su questo tipo di operazioni non ci sono eccezioni, e per quento ci penso sono le uniche che non generano questo tipo di eccezioni, era riferito a quello.
ora, al di la del fatto che seppure il guadagno prestazionale sia del 100% nel caso di maschere > 32 bit, sia la frequenza di questo tipo di operazioni sia la effetiva presenza di questa lunghezza di maschere penso porti ad una presenza minore del %1 in un campione casuale di codice(e penso di aver essere stano molto molto alto come percentuale), in questi casi la frequenza di tale operazione e minima.

per le restanti operazioni aritmentiche concordo pienamente, logicamente si puo usare l'unico da 64 come un vettore di 2 da 32, ma tutti i controlli eccezioni svolti in soft renderebbe il tutto sconveniente.

Quale parallelismo ? Comunque mmx, sse e C. operano sui floating point ;)

il parallelismo di trattare i dati come un vettore, il simd.

questo era per tirare l'acqua al mio mulino sul fatto del loading del fpu nella meta del tempo rispetto ai 32 bit.
sinceramente non conosco molto come funziona l'fpu, ma penso che in molti casi si possa sfruttare 2 vettori da 64 e operare in parallelo su questi per compensare i tempi di unloading\loading.
ci sono naturalemtne dei casi (tipicamente la ricorsivita' del dato nel elaborazione, tipico questo del incremento di precisione,penso superpi e giusto?) dove i dati non possono essere visti in vettori per elaborarli.

Certo...infatti la maggior parte della gente lo sta facendo funziona a 32 bit ;)

Penso che primo o poi i 64 bit dovevano essere introdotti... Dopo tutto anche Intel aveva nei propri piani l'introduzione di IA64 nel desktop (doveva avvenire nel 2005, ma, per lo scarso successo di Itanium e la concorrenza di AMD è slittato tutto)...

non concordo totalmente che i 64 siano utili nel uso che oggi fa la maggiorparte della gente, che fossero introdotti si, per certi tipi di applicazioni i 64 bit sono una manna.

discorso diverso e la richiesta di operazioni di tipo vettoriale, infatti si pensa di usare la gpu per le operazioni vettoriali general purpose, che puo essere applicata in molti campi(www.gpgpu.org).

quello che volevo precisare cmq e che secondo me i vantaggi dei 64 bit non sono velocistici, ma solamente spaziali.
naturalmente dove lo spazio non basta si deve perdere in tempo per emularlo\comprimerlo\ecc.
oggigiorno non ci sono richieste di spazio, se non per problemi che esulano dal normale utilizzo che un utente fa, e, non ne vedo all'orizzonte.

con questo ripeto, no dico che amd64 faccia cagare o intel sia meglio perche non inganna, non me ne frega nulla, ripeto che secondo me quei 64 bit non sono la soluzione alle richieste computazionali di oggi (velocistiche), poiche queste sono sopratutto vettoriali come tipo di trattazione (multimediale).

poi che amd abbia introdotto i 64 perche lo riteneva giusto(probabilmente per se, non per portare la razza umana avanti in una corsa tecnologica) e che questa me la dia al prezzo dei 32 son contento.

questo e come la penso, mi sembra coerente, naturalmente a controesempio lo ricorstruisco.

Goldrake_xyz

02-07-2004, 21:01

Originariamente inviato da Mason
goldrake aveva citato un operazione tipica su bitmask in cui si poteva vedere un operazione di bit logico su 8 byte come un unica op

Mah, il problema è che esistono molti software scritti a 64 bit
pensa alle workstation con Itanium2 ....

Se è vero che non si incontrano numeri interi così grossi,
d'altra parte si possono usare i 64bit per i grandi database ...

è un pò il discorso di quando intel mise in commercio il 386 ....
allora, tutti i programmi erano a 16bit e non si sentiva il
bisogno dei 32.. (memoria a parte !)
Oggi chi è che ritornerebbe ai processori a 16 bit ?

Ciao.

cionci

03-07-2004, 02:36

Originariamente inviato da Goldrake_xyz
Mah, il problema è che esistono molti software scritti a 64 bit
pensa alle workstation con Itanium2 ....
Vabbè...non hai citato certo le workstation più diffuse al mondo :D
Comunque sono convinto che il software magari non il 100%, ma arriverebbe presto... C'è tanto software OpenSource anche per Windows... Per quello basterebbe la solita ricompilata o poco più...

cionci

03-07-2004, 02:45

Ma riguardo all'utilizzo dei numeri a virgola fissa in alcuni algoritmi (chiaramente non è possibile in tutti), cosa ne pensate ? Secondo me sarebbe una furbata incredibile...

ev8

03-07-2004, 15:46

Originariamente inviato da cionci
Ma riguardo all'utilizzo dei numeri a virgola fissa in alcuni algoritmi (chiaramente non è possibile in tutti), cosa ne pensate ? Secondo me sarebbe una furbata incredibile...

Ai tempi del Pentium si. Il problema è che oggigiorno le CPU puntano molto sul FP, in genere possono eseguire lo stesso numero di operazioni simultanee su I64 o su FP64. Quindi il vantaggio c'è solo nelle latenze delle operazioni di somma/confronto ecc..
Una somma di interi a 64bit ha latency di 1-2 cicli mentre un'equivalente in virgola mobile dai 3 ai 6 cicli a seconda dell'implementazione.
Qundi il gioco di riprogrammare quelli algoritmi applicabili agli interi spesso non vale la candela delle prestazioni.

Goldrake_xyz

03-07-2004, 19:23

Originariamente inviato da cionci
Ma riguardo all'utilizzo dei numeri a virgola fissa in alcuni algoritmi (chiaramente non è possibile in tutti), cosa ne pensate ? Secondo me sarebbe una furbata incredibile...

virgola fissa :eek:
ehm, e la precisione ? i floating point con esponente e mantissa
sono stati pensati proprio x quello ....
(tranne i videogiochi ne avrebbero un sicuro beneficio...)

Comunque c'entra anche "l'anima del commercio" ,
Perciò la uSoft passerà al Winpest...64 bit così tutti saranno
obbligati a cambiare il proprio P4 ... !
Oramai penso che lo abbiamo capito tutti....

ciao.

cionci

03-07-2004, 23:33

Originariamente inviato da Goldrake_xyz
virgola fissa :eek:
ehm, e la precisione ? i floating point con esponente e mantissa
sono stati pensati proprio x quello ....
(tranne i videogiochi ne avrebbero un sicuro beneficio...)
Non dico tutti le applicazioni in generale, ma solo alcune in cui limite inferiore e superiore sono calcolabili a priori... Ad esempio l'elaborazione delle immagini, algoritmi di compressione lossy... Tutti campi in cui il rrange dei numeri in gioco è ben controllabile ed in cui non servono numeri troppo piccoli o troppo grandi...
Un tempo l'utilizzo dei fixed point era d'obbligo, quando non c'era l'unità FPU, ma la dimensione dei registri in gioco era troppo piccola !
Ora con gli interi a 64 bit, si potrebbero gestire anche numeri con buona precisione... Ad esempio 32 bit per la parte intera e 32 per la parte decimale... Certo ci sarebbe una minore precisione, ma secondo me sarebbe un avanzamento prestazionale importante per alcuni algortimi...

von Clausewitz

04-07-2004, 15:28

non per dire, anzi per dire, ma voi conoscete qualche mdello attuale di schede madri per computer desktop che riesca ha installare il limite fatidico dei 4 GB di memoria ram?
se si ditemi il modello
in particolare vi sono problemi di compatibilità per via del controller integrato sull'athlon 64 (e infatti amd ha introdotto nuovi step per migliorarne la compatibilità) con vari moduli e marche di memoria ram
tomshardware ha fatto varie prove in merito e per le schede madri athlon 64 socket 754 il limite invalicabile e di 2 GB e mezzo
la prova di una scheda madre socket 939 su questo sito ha dato risultati ancora più sconfortanti, funzionavano 2 slot di memoria su 4, altro che oltre 4 GB di memoria ram è già troppo installarne due
fate ragionamenti troppo astratti senza tener conto della realtà dell'hardware esistente
per cui i fatidici 64 bit, almeno per la memoria installabile sui computer desktop, sono completamente inutili
si presume che questa inutilità permanga almeno anche per qualche anno a venire

cionci

05-07-2004, 02:54

Originariamente inviato da von Clausewitz
non per dire, anzi per dire, ma voi conoscete qualche mdello attuale di schede madri per computer desktop che riesca ha installare il limite fatidico dei 4 GB di memoria ram?
se si ditemi il modello
Questa: http://www.asus.com/prog/spec.asp?m=SK8N&langs=01#
Con della registered PC2100 non ci dovrebbero essere prolemi (avevo visto una configurazione con 4 Gb tempo fa su un sito che non mi riesce più trovare)...
Il problema della Ram c'è purtroppo su molte piattaforme per AMD...e non solo per Athlon 64...
Originariamente inviato da von Clausewitz
fate ragionamenti troppo astratti senza tener conto della realtà dell'hardware esistente
per cui i fatidici 64 bit, almeno per la memoria installabile sui computer desktop, sono completamente inutili

Il limite non sta stretto ORA per i sistemi desktop (ma lo diventerà fra un paio di anni)...ma ORA sta stretto per i sistemi server...e per qualche workstation...
Tutti i sistemi quad e dual Opteron non hanno alcun problema a montare anche oltre 4 Gb di Ram...
von Clausewitz: ti prego non comnciare con i soliti discorsi antiAMD triti e ritriti...che ormai ti sentiamo fare da troppo tempo...

^TiGeRShArK^

05-07-2004, 13:01

Originariamente inviato da von Clausewitz
in particolare vi sono problemi di compatibilità per via del controller integrato sull'athlon 64 (e infatti amd ha introdotto nuovi step per migliorarne la compatibilità) con vari moduli e marche di memoria ram
tomshardware ha fatto varie prove in merito e per le schede madri athlon 64 socket 754 il limite invalicabile e di 2 GB e mezzo
la prova di una scheda madre socket 939 su questo sito ha dato risultati ancora più sconfortanti, funzionavano 2 slot di memoria su 4, altro che oltre 4 GB di memoria ram è già troppo installarne due
fate ragionamenti troppo astratti senza tener conto della realtà dell'hardware esistente
per cui i fatidici 64 bit, almeno per la memoria installabile sui computer desktop, sono completamente inutili
si presume che questa inutilità permanga almeno anche per qualche anno a venire

x quanto riguarda i "vari step" da te citati.... in realtà è stato solo uno precisamente si è passati dallo step C0 allo step CG....magari ti starai confondendo col prescott ke è già arrivato allo step D0 e ancora non si è visto ALCUN miglioramento .... ke SI SPERA possa avvenire con lo step E0 (se e quando uscirà) :rolleyes:
per quanto riguarda la questione ram ora mi sa ke si è fottuta la dorsale estera del collegamento di Alice (o si è 'mpaddata la connessione del mio pc dopo 4 giorni ke è collegato :muro: ) e non ti posso dare i link....
cmq su anandtech hanno fatto delle prove su varie skede madri socket 754 di seconda generazione e non risultavano problemi anke con tutti gli slot occupati.....
certo ora non ricordo ke tipo di moduli hanno usato, quindi non saprei la dimensione massima di mem ke hanno installato, ma cmq i settaggi ke utilizzavano erano MOLTO spinti :p
x quanto riguarda l'inutilità dei 64 bit mi sa ke ti sei perso qualke test su anandtech in cui già con programmi non ottimizzati x i 64 bit si avevano degli incrementi prestazionali assurdi solo per il fatto di usare win64 (preview version con driver tutt'altro ke definitivi...) ke andavano dal 15% nella compressione divx al 34% nell'uso di lame.....
prova un pò ad immaginare cosa accadrà all'uscita di programmi ottimizzati......
certo potrai dire ... ma tanto non usciranno mai, ci vorranno anni e anni.....
e vabbè intanto ke escono (anke se ottimisticamente ci metteranno molto meno) si avranno incrementi prestazionali gratuiti fino al 34% :p

Mason

05-07-2004, 15:50

mumble, dichiarazioni sicuramente pesanti :)

puoi linkare la prova su anandtech? un po ho cercato un po ma non ho trovato quasi nulla.

un incremento nelle sole chiamate a sistema del 34% in alcuni casi e un incremento eclatante in un sistema operativo, non so come ne esca fuori, visto che il programma come dici e sempre a 32 bit(non e stato ricompilato o si?).

cmq secondo me, tra i vari incrementi che si possono fare in un procio, i 64 bit in hardware sono una delle ultime cose che vorrei, anzi, ad essere sincero la prima idea che mi viene in mente con la parola 64 e la tabella delle pagine inversa, fai tu.

cmq mi piacerebbe vedere alcuni comportamenti di alcuni prg tipo mencoder o un render(yafray) programmati in thread/processi (mencoder non so se e stato programmato in mutlithread, sicuramente yafray si) in guadagno che hanno passando da 32 a 64 e da 32 a ht (o biprocio), oppure usando spec con i prg e kernel compilati su "misura" per i proci, anche se mi sembra che nessuno dei test di spec siano multithreaddati.

infine rispondo un po piu sopra a goldrake, concordo sul fatto, come ha anche detto cionci, che prima o poi i 64 sarebbero dovuti arrivare e di questo ne son contento, sicuramente sento meno il passaggio da 32 a 64 rispetto di quello da 16 a 32, cosi come sentiro meno il passaggio da 64 a 128(se mai ci sara), e visto il prezzo del procio in questione, vista l'effetiva velocita' del procio(secondo me abbastanza indipendente dai 64 bit, non hanno mica aggiunto dei registri?) non escludo che in futuro un 64 bit sara' mio.
Personalmente io son piu attirato da piu core (logici/reali) che dai 64 bit, come programmatore.

infine un paio di domande ai vari programmatori , voi cambierete qualcosa nella programmazione per questi 64 bit?
sinceramente non vedo grossi stravolgimenti a meno di aver a che fare con l'assembly proprio, ma forse mi sbaglio.

cionci

05-07-2004, 16:09

Originariamente inviato da Mason
infine un paio di domande ai vari programmatori , voi cambierete qualcosa nella programmazione per questi 64 bit?
sinceramente non vedo grossi stravolgimenti a meno di aver a che fare con l'assembly proprio, ma forse mi sbaglio.
Al massimo questa storia dei fixed point che mi incuriosisce parecchio...
Riguardo alla ricompilazione...non c'è molto da dire... Tutti i programmi che non fanno alcuna supposizione sulla dimensione dei vari tipi (ad esempio i puntatori saranno a 64 bit) avranno bisogno solamente di una ricompilata...

Alcuni vantaggi prestazionali dovuti all'introduzione dei 64 bit si potranno avere su quasi tutti i programmi... Infatti ora ci sono 16 registri nella ALU...e questo diminuirà sicuramente l'uso dello stack e toglierà un po' di carico alla memoria...

Riguardo ai programmi a 32 bit che girano su WinXP 64 bit: il layer che traduce le chiamate alle API a 32 bit in chaimate a lle API a 64 bit sicuramente porta un leggero overhead...ma in certi casi, se le API chiamate lavorano possono essere implementate sfruttando interi a 64 bit (prima venivano usati due interi a 32 bit, più vari controlli), l'aumento potrebbe essere discreto...

Mason

05-07-2004, 17:01

mi hai incuriosito con sta storia dei fixed point, intendi senza esponente? senza traslare la parte di mantissa ma mantenerla fissa rispetto a 1 e sfruttare tutti i bit per la mantissa?leggero' qualcosa premesso, dovrei cmq rinfrescare :), per ora mi lascia un poco perplesso, non riesco a ben capire cosa tu intenda, cmq devo leggere un poco, anche se mi sembra un po ot :)

per lo stack, si e vero che lo stack sara' meno usato ma questo e dovuto ai piu registri, non ai 64, anzi i registri che mettero nello stack occuperanno il doppio in mem per via dei 64.
diciamo che l'x86-64 la apprezzo piu per i maggiori registri che per i 64.
ricordiamoci che probabilmente sara' l'arcghitettura di riferimento per un normale pc per un po di tempo penso, quindi dovra durare :)

concordo che l'aumento se si usa 2 da 32 per simulare un singolo a 64 sia molto apprezzabille, ma aspetto il link di anadtech per vedere come spiega questo incremento secondo me ingiustificato per le premesse, poi considerando che di win non e che si possa sapere molto prendo un po il dato con le molle ma di sicuro in conto

cionci

05-07-2004, 17:15

Originariamente inviato da Mason
mi hai incuriosito con sta storia dei fixed point, intendi senza esponente? senza traslare la parte di mantissa ma mantenerla fissa rispetto a 1 e sfruttare tutti i bit per la mantissa?leggero' qualcosa premesso, dovrei cmq rinfrescare :), per ora mi lascia un poco perplesso, non riesco a ben capire cosa tu intenda, cmq devo leggere un poco, anche se mi sembra un po ot :)
Non esattamente... Intedevo memorizzare il floating point come parte intera e parte decimale... Senza normalizzazione e senza esponente...
Ad esempio: 32 bit per la parte intera e 32 bit per la parte dopo la virgola... Considera che ovviamente si parla di applicazioni particolari...diverse dal calcolo prettamente scientifico...
Originariamente inviato da Mason
per lo stack, si e vero che lo stack sara' meno usato ma questo e dovuto ai piu registri, non ai 64, anzi i registri che mettero nello stack occuperanno il doppio in mem per via dei 64.
Chiaro...non intedevo "grazie ai 64 bit", ma "grazie all'architettura introdotta da AMD per i 64 bit"... Comunque un ciclo di lettura/scrittura da 64 bit dovrebbe durare lo stesso tempo di un ciclo di lettura/scritto da 32 bit...dato che il bus è 64 bit non c'è alcuna differenza... Cambiano solo i segnali di selezione generati dal memory controller... Di fatto le varie linnee lavorano in parallelo...

Pubblicità: comunque fai un giro nella sezione Programmazione ;)

Mason

05-07-2004, 17:38

:cincin:
piu o meno siamo d'accordo, io avrei aspettato ancora qualche anno per i 64 bit, pero effetivamente x86 e da un po che c'e come architettura, un po di lifting gli fara bene ,e cmq dubito si tornera indietro e di quello che penso io all'amd intel penso non freghi una mazza :)

lurko un po in programmazione :)

hai pvt per il fixed point, vorrei evitare l'OT

cdimauro

05-07-2004, 23:23

Originariamente inviato da Mason
cmq secondo me, tra i vari incrementi che si possono fare in un procio, i 64 bit in hardware sono una delle ultime cose che vorrei, anzi, ad essere sincero la prima idea che mi viene in mente con la parola 64 e la tabella delle pagine inversa, fai tu.
Cioé?
Personalmente io son piu attirato da piu core (logici/reali) che dai 64 bit, come programmatore.

infine un paio di domande ai vari programmatori , voi cambierete qualcosa nella programmazione per questi 64 bit?
sinceramente non vedo grossi stravolgimenti a meno di aver a che fare con l'assembly proprio, ma forse mi sbaglio.
Dipende dal tipo di applicazione che scrivi, ovviamente. Posso dirti, tanto per fare un esempio, che nel campo dei codec i 64 bit li vedo proprio bene: puoi pensare di realizzare lo stesso algoritmo in modi completamente diversi da come faresti con processori a 32 bit. Il problema, però, è che non puoi permetterti di scrivere codice "pensato per i 64 bit", perché fatto girare su macchine a 32 bit, anche emulandone le funzionalità con i tipi long long, le prestazioni sarebbero disastrose.

Insomma, i 64 bit, come programmatore, mi stanno facendo impazzire di gioia proprio perché sono qualcosa che ha nuovamente scatenato la mia fantasia. :D Peccato che, nella vita di tutti i giorni, non li posso utilizzare per i motivi che ho sopra esposto... :cry:

^TiGeRShArK^

05-07-2004, 23:41

Originariamente inviato da Mason
mumble, dichiarazioni sicuramente pesanti :)

puoi linkare la prova su anandtech? un po ho cercato un po ma non ho trovato quasi nulla.

Ecco qu i link!
finalmente hanno aggiustato il problema al router della dorsale di Alice :D
http://www.anandtech.com/cpu/showdoc.html?i=1884&p=17

http://www.anandtech.com/systems/showdoc.html?i=1961

OverClocK79®

05-07-2004, 23:46

azzarola un +15% di prestazioni sull'encoding mi fa ben sperare......

peccato per i gioki che quasi si dimezzano ma è chiaramente un prob di driver conf ecc ecc

BYEZZZZZZZZZZZZZZ

^TiGeRShArK^

06-07-2004, 00:47

infatti ancora i driver x win64 sono ad uno stato praticamente embrionale....
si spera siano decenti con l'uscita del SO definitivo....

Mason

06-07-2004, 04:09

per la tabella pagine inversa :
http://www.cs.utah.edu/classes/cs5460/lectures/lecture14-6up.pdf

sinceramente ricordavo piu letteratura, cmq il prob di solito viene introdotto dalla dimensione della mappatura a 64 bit tra indirizzo virtuale e indirizzo reale, anche se ricordo non molto , pero lo associo a 64 bit :)

thx per i test:
mumble, ci pensop e faccio un paio di prove col gcc e lame, per vedere un paio di cose, poi ti dico, ma piu che altro per curiosita' personale.

per ora ci vedo:
l'amd e un buon procio
l'amd va bene a 32
l'amd 64 va meglio a 64 che a 32
non ci vedo che i 64 bit portino vantaggi velocistici cosniderabili(in processi cpu bound tipo encoding o rendering il p4 e avanti pur essendo a 32, _non_ volgio dire che il p4 sia meglio del a64, ma ritengo sia un fatto da teenre in considerazione)

il test cmq di win in encodin e quello che mi lascia piu perplesso visto l'applicativo.

sto guardando dei test di spec:
http://www.digit-life.com/articles2/insidespeccpu/insidespeccpu2000-part-f.html
http://www.digit-life.com/articles2/insidespeccpu/insidespeccpu2000-opteron2.html

io rimango dell idea che i 64 bit in se siano tutt'oggi e saranno per un qualche anno molto inutilizzati nel personal computer, e apsetto la killer aplication per i 64.

ma sono effetivamente l'unica persona che pensa che i 64 bit siano un po prematuri per il desktop?

cdimauro

06-07-2004, 07:50

OK, adesso è chiaro. ;)

Per quanto riguarda l'utilità dei 64 bit nella programmazione, ho già espresso la mia opinione: spazio alla fantasia... :D

cionci

06-07-2004, 09:45

Originariamente inviato da Mason
ma sono effetivamente l'unica persona che pensa che i 64 bit siano un po prematuri per il desktop?
Forse per i desktop sì...almeno di uno o due anni... Ciò non toglie che sia un'opportunità in più per noi programmatori... Non sapete quanti test avrei voglia di fare con un Althlon 64 e un SO a 64 bit...

^TiGeRShArK^

06-07-2004, 13:30

secodno me invece saranno MOLTO importanti x i desktop perchè penso ke i programmatori di gioki troveranno grandi vantaggi prestazionali (a detta della crytek, con amd64 si ottengono "huge performance gain").
e visto quanto mercato hanno i gioki x un computer desktop... l'equazione è completa :p

von Clausewitz

17-03-2005, 00:40

Originariamente inviato da von Clausewitz
non per dire, anzi per dire, ma voi conoscete qualche mdello attuale di schede madri per computer desktop che riesca ha installare il limite fatidico dei 4 GB di memoria ram?
se si ditemi il modello
in particolare vi sono problemi di compatibilità per via del controller integrato sull'athlon 64 (e infatti amd ha introdotto nuovi step per migliorarne la compatibilità) con vari moduli e marche di memoria ram
tomshardware ha fatto varie prove in merito e per le schede madri athlon 64 socket 754 il limite invalicabile e di 2 GB e mezzo
la prova di una scheda madre socket 939 su questo sito ha dato risultati ancora più sconfortanti, funzionavano 2 slot di memoria su 4, altro che oltre 4 GB di memoria ram è già troppo installarne due
fate ragionamenti troppo astratti senza tener conto della realtà dell'hardware esistente
per cui i fatidici 64 bit, almeno per la memoria installabile sui computer desktop, sono completamente inutili
si presume che questa inutilità permanga almeno anche per qualche anno a venire

Originariamente inviato da cionci
Questa: http://www.asus.com/prog/spec.asp?m=SK8N&langs=01#
Con della registered PC2100 non ci dovrebbero essere prolemi (avevo visto una configurazione con 4 Gb tempo fa su un sito che non mi riesce più trovare)...
Il problema della Ram c'è purtroppo su molte piattaforme per AMD...e non solo per Athlon 64...

Il limite non sta stretto ORA per i sistemi desktop (ma lo diventerà fra un paio di anni)...ma ORA sta stretto per i sistemi server...e per qualche workstation...
Tutti i sistemi quad e dual Opteron non hanno alcun problema a montare anche oltre 4 Gb di Ram...
von Clausewitz: ti prego non comnciare con i soliti discorsi antiAMD triti e ritriti...che ormai ti sentiamo fare da troppo tempo...

cionci, volevi un esempio di tuoi commenti non obiettivi?
eccone uno
io scrivo che l'athon 64 sulle mobo attuali ha problemi ha indirizzare molta ram per via del controlle integrato e tu allarghi il discorso scrivendo (testuale): "Il problema della Ram c'è purtroppo su molte piattaforme per AMD...e non solo per Athlon 64..."?
cioè lo allarghi alla piattaforma AMD genericamente intesa tout court

io scrivo che per il momento almeno per qualche anno a venire per queste ragioni l'indirizzamento a più di 4 gb di memoria fisica di fatto è inutile, specificando che mi riferisco ai computer desktop e tu mi rispondi:
"Il limite non sta stretto ORA per i sistemi desktop (ma lo diventerà fra un paio di anni)...ma ORA sta stretto per i sistemi server...e per qualche workstation...
Tutti i sistemi quad e dual Opteron non hanno alcun problema a montare anche oltre 4 Gb di Ram..."

come se io concettualmente avessi scritto qualcosa di diverso....
e per chiosa finale dici che io miei sono (sempre testuale): "i soliti discorsi antiAMD triti e ritriti"?
ma ti sembra un post plausibile invece il tuo? :confused: :rolleyes:
vabbè non potevo aspettarmi niente di diverso da uno che ha fatto mettere fra le discussioni importanti i codici degli athlon xp
che ci sarà di così in quei codici importante vallo a capire
però non si sa mai, vorrà dire che quando mi prenderò il sempron (fra un po') 2500+ o 2600+, posterò anch'io nella tua discussione quel codice (tanto è un athlon anche quello, no?), così dormirò sonni tranquilli.......

OverClocK79®

17-03-2005, 11:46

Originariamente inviato da von Clausewitz
vabbè non potevo aspettarmi niente di diverso da uno che ha fatto mettere fra le discussioni importanti i codici degli athlon xp
che ci sarà di così in quei codici importante vallo a capire
però non si sa mai, vorrà dire che quando mi prenderò il sempron (fra un po') 2500+ o 2600+, posterò anch'io nella tua discussione quel codice (tanto è un athlon anche quello, no?), così dormirò sonni tranquilli.......

tralasciando quello scritto sopra......nn voglio entrare nel merito...
i codici dei vari AthlonXP/64 sono molto ultili soprattutto per nn dover spiegare ogni volta a chi lo chiede cosa significa.....
se è un winchester ecc ecc
purtroppo nn lo guardano MAI :D
ma intanto è li.....

purtroppo AMD nn ha un bel sistema di ricerca tipo INTEL e lo spec finder.....
ma occorre guardarsi PDF su PDF.....
quindi quel post è di aiuto a chi vuole sapere qlkosa di + del suo Athlon Duron Torton e chi ne ha + ne metta senza dover cercare tra i PDF

per INTEL è tutto + semplice.....
nn serve manco un post....visto che gli passi il link
http://processorfinder.intel.com

e sei apposto :) c'è tutto

se invece ri riferisci a quello delle semplici sigle...
forse una volta poteva essere utile adesso credo che ormai una cpu valga l'altra a parità di core e ci siano sigle sfigate che a volte salgono di + di quelle "fortunate" va sempre a (_)(_)

BYEZZZZZZZZZZZZZZZZZZ

von Clausewitz

18-03-2005, 00:09

Originariamente inviato da OverClocK79®
tralasciando quello scritto sopra......nn voglio entrare nel merito...
i codici dei vari AthlonXP/64 sono molto ultili soprattutto per nn dover spiegare ogni volta a chi lo chiede cosa significa.....
se è un winchester ecc ecc
purtroppo nn lo guardano MAI :D
ma intanto è li.....

purtroppo AMD nn ha un bel sistema di ricerca tipo INTEL e lo spec finder.....
ma occorre guardarsi PDF su PDF.....
quindi quel post è di aiuto a chi vuole sapere qlkosa di + del suo Athlon Duron Torton e chi ne ha + ne metta senza dover cercare tra i PDF

per INTEL è tutto + semplice.....
nn serve manco un post....visto che gli passi il link
http://processorfinder.intel.com

e sei apposto :) c'è tutto

se invece ri riferisci a quello delle semplici sigle...
forse una volta poteva essere utile adesso credo che ormai una cpu valga l'altra a parità di core e ci siano sigle sfigate che a volte salgono di + di quelle "fortunate" va sempre a (_)(_)

BYEZZZZZZZZZZZZZZZZZZ

se vuoi entra anche nel merito, non c'è problema
non mi sembra di aver detto niente di scandaloso per avere una risposta di quel tipo da parte del moderatore cionci
cmq mi riferivo alle sigle, che siano importanti non saprei, sicuramente non al punto di metterla in rilievo
ma d'altronde in questo forum c'è ne sono 3 su 4 dedicate a processori amd

OverClocK79®

18-03-2005, 12:39

Originariamente inviato da von Clausewitz
se vuoi entra anche nel merito, non c'è problema
non mi sembra di aver detto niente di scandaloso per avere una risposta di quel tipo da parte del moderatore cionci

no bhe
intendevo non volevo entrare nel merito della questione perchè leggo solo uno stralcio del discorso....e 2 quote riportati da te....
non samprei sinceramente dove inizia e dove finisce
posso al limite intervenire su quei 2 quote...

cmq mi riferivo alle sigle, che siano importanti non saprei, sicuramente non al punto di metterla in rilievo
ma d'altronde in questo forum c'è ne sono 3 su 4 dedicate a processori amd

le guide sono utili IMHO
come dicevo in precedenza INTEL ha già il suo spec finder che funziona benissimo non credo servirebbero particolari guide
cmq credo che se qlkuno ha voglia di fare una guida per CPU INTEL credo che nessuno obbietterà......
anke se IMHO visto l'ottimo sito INTEL nn servirebbe

il TH soi codici degli XP sinceramente non saprei a cosa possa servire......quando la guida ormai spiega tutto.....e appurato anke che CPU cono la stessa sigla possono avere comportamenti diversi in OC

il fatto che cmq su questo forum ci siano + guide per AMD non significa che ci sia preferenza per una o per l'altra casa....
ma solamente che è + difficile reperire info per AMD che non per INTEL
un po' come sul forum skede video magari ci sono + guide per installare i Driver aTi rispetto ad nVidia
semplicemente perchè sono legg + delicati del forcware ecc ecc :)

passiamo poi al discorso 64 bit e indirizzamento ram
tralascio il discorso serve che personalmente non conosco benissimo e dove magari il limite di 4 GB su piattaforme per gestione di database e archivi pesanti sicuramente servono
passiamo al discorso desktop....

non per dire, anzi per dire, ma voi conoscete qualche mdello attuale di schede madri per computer desktop che riesca ha installare il limite fatidico dei 4 GB di memoria ram?
se si ditemi il modello
in particolare vi sono problemi di compatibilità per via del controller integrato sull'athlon 64 (e infatti amd ha introdotto nuovi step per migliorarne la compatibilità) con vari moduli e marche di memoria ram
vero....agli inizi con i C0 c'è stato + di qlk problemino sul 754
single channel si faceva fatica a usare 2 banki a 512 a 400mhz sulla stessa mobo spesso si decloccavano a 333
con gli ultimi step le cose sono migliorate sia per dimensioni che per compatibilità difficile cmq superare i 4Gb con un 754 sia per vias degli slot che del controller..... il limite è molto + basso

tomshardware ha fatto varie prove in merito e per le schede madri athlon 64 socket 754 il limite invalicabile e di 2 GB e mezzo
la prova di una scheda madre socket 939 su questo sito ha dato risultati ancora più sconfortanti, funzionavano 2 slot di memoria su 4, altro che oltre 4 GB di memoria ram è già troppo installarne due

appurato il discorso 754
passiamo al 939
sulla mia A8V massimo c'è scritto che posso arrivare a 4Gb non oltre.....tra PC3200/2700/2100/1600 ecc e non
tutti test fatti dall'asus sono stati fatti con 512mb di ramx4
per arrivare a 2Gb
in questa conf ti posso dire che la mobo funziona tranquillamente
quando avevo le 3500 Corsair provai i 2Gb senza problemi....
con 4 banki
un mio caro amico.....utilizza 4 banki da 256 sempre PC3500 senza prob
siamo cmq a dimensioni tipo 2Gb/1Gb DUAL 4 banki
quindi lo sforzo è stato fatto e le cose migliorano.....

certo......4Gb....manco l'ombra e cmq credo che forse con moduli + lenti.... PC2100 ecc ecc magari a 4gb si riesca ad arrivare.....
di + non credo.....
i 64 bit aggiungo anke questa possibilità.....ma IMHO per il settore dextop non è ankora ora....
adesso con 1 Gb si lavora benissimo
i + esigenti possono passare a 2
quando serviranno
forse saremo con il socketM2 e altre CPU con altre revisioni del controller
magari dual core con doppio controller e 4+4Gb .....chi lo sa :)

quindi anke IMHO per ora con gli attuali core.....questa feauture almeno in ambito desktop non è fruibile o cmq utile......

i 64 bit cmq non portano solo questo..... ;)
ma hanno anke altre interessanti feature

cmq sia nel caso dell'A64 che dei vari 875P 925XE i 4 banki credo funzionino solo con ram esattamente identica e della stessa marca (buona) non di certo con ram scadente OEM

BYEZZZZZZZZZZZZZZ

leoneazzurro

18-03-2005, 18:05

Qui si sta facendo un pò di confusione...

L'architettura x86-64 permette di indirizzare fisicamente un quantitativo di memoria superiore ai 4 Gigabyte.
E questo è facilmente verificabile nei sistemi Opteron.

Per i processori desktop invece si ha:

Socket 754 :supporto per 3 DIMM unbuffered

Socket 939: supporto per 4 DIMM unbuffered.

poichè attualmente sul mercato i DIMM unbuffered con capacità maggiore di 1 Gbyte praticamente non esistono, abbiamo che i processori Socket 754 supportano fino a 3 Gbyte di memoria, mentre i processori Socket 939 fino a 4 Gbyte. Fossero stati disponibili DIMM con capacità maggiori da subito, questo quantitativo di memoria sarebbe stato più alto.
In ambito desktop questo fattore però non è per nulla limitante, in quanto anche il sistema operativo più diffuso in questo ambito (Win XP) non è in grado di gestire adeguatamente questo quantitativo di RAM.

Nel caso degli Opteron il supporto è per 8 DIMM registered, che portano il quantitativo di RAM a 8 Gbyte per processore (ma sono in arrivo DIMM registered a 2 Gbyte), che comunque debbono essere sfruttati con un sistema operativo adeguato.

zuLunis

18-03-2005, 19:11

i bench ci sono in internet, e i 64bit rispetto ai 32 hanno un guadagno prestazionale di circa il 30% ora come ora.. andando avanti con lo sviluppo, si arriverà a un buon 50%, poi con i 64bit totali e non parziali attuali (estensione di 32bit, non completamente a 64) si arriverà anche 70% secondo me :)

leoneazzurro

18-03-2005, 19:16

Originariamente inviato da zuLunis
i bench ci sono in internet, e i 64bit rispetto ai 32 hanno un guadagno prestazionale di circa il 30% ora come ora.. andando avanti con lo sviluppo, si arriverà a un buon 50%, poi con i 64bit totali e non parziali attuali (estensione di 32bit, non completamente a 64) si arriverà anche 70% secondo me :)

A parte casi sporadici, è difficile che si andrà oltre il 15-20% di media.
Ci saranno dei programmi che non vedranno particolari incrementi.
Alcuni programmi specifici potrebbero anche superare il 50%, ma si tratterebbe di casi particolari e di certo non generalizzabili.

zuLunis

18-03-2005, 19:18

su un benchmark visto in rete, nn ricordo il link.. si parlava di un minimo del 30% e poi, come sempre, amd batteva intel sulle applicazioni a 64 bit :)

Secondo me, i 64bit gioverà molto di piu ad AMD per il rendering che ad Intel

leoneazzurro

18-03-2005, 19:21

Questo è probabile, tuttavia tu hai visto UN benchmark o una limitata serie di benchmark. E' plausibile che non tutti i benchmark risentiranno allo stesso modo dell'utilizzo dei 64 bit.

OverClocK79®

19-03-2005, 10:44

Originariamente inviato da zuLunis
i bench ci sono in internet, e i 64bit rispetto ai 32 hanno un guadagno prestazionale di circa il 30% ora come ora.. andando avanti con lo sviluppo, si arriverà a un buon 50%, poi con i 64bit totali e non parziali attuali (estensione di 32bit, non completamente a 64) si arriverà anche 70% secondo me :)

si ok
ma qui abbiamo preso in considerazione solo il discorso memorie che non fa performance :)

BYEZZZZZZZZZZZZ

von Clausewitz

19-03-2005, 18:37

Originariamente inviato da OverClocK79®
no bhe
intendevo non volevo entrare nel merito della questione perchè leggo solo uno stralcio del discorso....e 2 quote riportati da te....
non samprei sinceramente dove inizia e dove finisce
posso al limite intervenire su quei 2 quote...

le guide sono utili IMHO
come dicevo in precedenza INTEL ha già il suo spec finder che funziona benissimo non credo servirebbero particolari guide
cmq credo che se qlkuno ha voglia di fare una guida per CPU INTEL credo che nessuno obbietterà......
anke se IMHO visto l'ottimo sito INTEL nn servirebbe

il TH soi codici degli XP sinceramente non saprei a cosa possa servire......quando la guida ormai spiega tutto.....e appurato anke che CPU cono la stessa sigla possono avere comportamenti diversi in OC

il fatto che cmq su questo forum ci siano + guide per AMD non significa che ci sia preferenza per una o per l'altra casa....
ma solamente che è + difficile reperire info per AMD che non per INTEL
un po' come sul forum skede video magari ci sono + guide per installare i Driver aTi rispetto ad nVidia
semplicemente perchè sono legg + delicati del forcware ecc ecc :)

passiamo poi al discorso 64 bit e indirizzamento ram
tralascio il discorso serve che personalmente non conosco benissimo e dove magari il limite di 4 GB su piattaforme per gestione di database e archivi pesanti sicuramente servono
passiamo al discorso desktop....

vero....agli inizi con i C0 c'è stato + di qlk problemino sul 754
single channel si faceva fatica a usare 2 banki a 512 a 400mhz sulla stessa mobo spesso si decloccavano a 333
con gli ultimi step le cose sono migliorate sia per dimensioni che per compatibilità difficile cmq superare i 4Gb con un 754 sia per vias degli slot che del controller..... il limite è molto + basso

appurato il discorso 754
passiamo al 939
sulla mia A8V massimo c'è scritto che posso arrivare a 4Gb non oltre.....tra PC3200/2700/2100/1600 ecc e non
tutti test fatti dall'asus sono stati fatti con 512mb di ramx4
per arrivare a 2Gb
in questa conf ti posso dire che la mobo funziona tranquillamente
quando avevo le 3500 Corsair provai i 2Gb senza problemi....
con 4 banki
un mio caro amico.....utilizza 4 banki da 256 sempre PC3500 senza prob
siamo cmq a dimensioni tipo 2Gb/1Gb DUAL 4 banki
quindi lo sforzo è stato fatto e le cose migliorano.....

certo......4Gb....manco l'ombra e cmq credo che forse con moduli + lenti.... PC2100 ecc ecc magari a 4gb si riesca ad arrivare.....
di + non credo.....
i 64 bit aggiungo anke questa possibilità.....ma IMHO per il settore dextop non è ankora ora....
adesso con 1 Gb si lavora benissimo
i + esigenti possono passare a 2
quando serviranno
forse saremo con il socketM2 e altre CPU con altre revisioni del controller
magari dual core con doppio controller e 4+4Gb .....chi lo sa :)

quindi anke IMHO per ora con gli attuali core.....questa feauture almeno in ambito desktop non è fruibile o cmq utile......

i 64 bit cmq non portano solo questo..... ;)
ma hanno anke altre interessanti feature

cmq sia nel caso dell'A64 che dei vari 875P 925XE i 4 banki credo funzionino solo con ram esattamente identica e della stessa marca (buona) non di certo con ram scadente OEM

BYEZZZZZZZZZZZZZZ

bene anche tu confermi che adesso come adesso parlare di oltre 4 GB di ram per pc desktop è di fatto inapplicabile, quindi inutile, per ora
questo era sicuramente uno dei vantaggi possibili, per gli altri bisognerà vedere se e in che misura ci saranno

ps la storia dei codici era una punzecchiatura più che altro a cionci ;) :D

cionci

21-03-2005, 02:43

Originariamente inviato da von Clausewitz
vabbè non potevo aspettarmi niente di diverso da uno che ha fatto mettere fra le discussioni importanti i codici degli athlon xp
che ci sarà di così in quei codici importante vallo a capire
però non si sa mai, vorrà dire che quando mi prenderò il sempron (fra un po') 2500+ o 2600+, posterò anch'io nella tua discussione quel codice (tanto è un athlon anche quello, no?), così dormirò sonni tranquilli.......
Quando quel thread è stato messo in evidenza io non ero ancora moderatore...almeno mi sembra...
Quel thread era nato da una notizia secondo cui se nel codice della CPU era riportata in una data posizione, ad esempio, 26 quella CPU era un Atlhon XP 2600+ eventualmente downcloccato...
La discussione era perfettamente lecita ed abbiamo subito raggiunto l'obiettivo dimostrando che non c'era alcuna correlazione fra questo numero e la frequenza che la CPU raggiungeva a voltaggi poco inferiori a quello standard per l'ipotetica frequenza...
Per me, a parte qualche sporadico intervento, quella discussione è terminata 15 giorni dopo... Non ci sono nemmeno più iscritto...

Concordo postare i codice fine a se stessi non ha, almeno ora, alcun senso...

OverClocK79®

21-03-2005, 12:08

Originariamente inviato da cionci
Quando quel thread è stato messo in evidenza io non ero ancora moderatore...almeno mi sembra...
Quel thread era nato da una notizia secondo cui se nel codice della CPU era riportata in una data posizione, ad esempio, 26 quella CPU era un Atlhon XP 2600+ eventualmente downcloccato...

si ricordo ankio
ma infatti erano cazzate.....ormai sui codici degli XP ci sono molte leggende :D
io ho sempre usato la regola generale compra sempre l'ultimo step e + recente possibile
altro che PCB verdi marroni ecc ecc
cmq IMHO si potrebbe anke togliere da stiky ormai che dici??

xVon
non serve che mi quoti tutto il mess per scrivere 2 righe :D
basta che mi scrvi xOver ;) altrimenti occupiamo pagine e pagine :)

BYEZZZZZZZZZZZZZZ

cionci

21-03-2005, 13:12

Per me sì, ma io non c'entro ;)

von Clausewitz

22-03-2005, 00:35

Originariamente inviato da cionci
Quando quel thread è stato messo in evidenza io non ero ancora moderatore...almeno mi sembra...
Quel thread era nato da una notizia secondo cui se nel codice della CPU era riportata in una data posizione, ad esempio, 26 quella CPU era un Atlhon XP 2600+ eventualmente downcloccato...
La discussione era perfettamente lecita ed abbiamo subito raggiunto l'obiettivo dimostrando che non c'era alcuna correlazione fra questo numero e la frequenza che la CPU raggiungeva a voltaggi poco inferiori a quello standard per l'ipotetica frequenza...
Per me, a parte qualche sporadico intervento, quella discussione è terminata 15 giorni dopo... Non ci sono nemmeno più iscritto...

Concordo postare i codice fine a se stessi non ha, almeno ora, alcun senso...

bene moderatore cionci, detto questo appurato questo, ero più interessante al resto del post a cui non hai risposto
ti sarei grato se rispondessi
grazie :rolleyes: