Speciale/ Processori allo scontro

L'IDF sembra aver superato i rischi dello spaccamento degli x86: Intel e AMD si ritrovano sulla stessa strada e raccolgono gli interessi di tutti, da IBM a Microsoft, da Sun a Dell ad HP. E ritorna al centro la Casa digitale

Speciale/ Processori allo scontroSan Francisco (USA) - È ufficiale: anche Intel, dopo AMD, si appresta a "spalmare" i 64 bit sulle proprie CPU x86, sia desktop che server. La tecnologia x86 a 64 bit di Intel, nota in precedenza con il nome in codice di Clackamas e commercializzata con quello di IA-32e, permetterà alle future versioni di Pentium 4 e Xeon di eseguire, similmente a quanto già fanno i processori Athlon 64 e Opteron di AMD, sia il codice x86 a 32 bit che quello a 64 bit, e di supportare quantitativi di memoria superiori ai 4 GB.

L'annuncio, dato presso l'Intel Developer Forum dal CEO di Intel, Craig Barrett, riveste particolare importanza per almeno tre ragioni: la prima è che Intel si trova nell'inusuale posizione di dover seguire le orme della sua diretta avversaria, AMD; la seconda è data dal fatto che, con il previsto arrivo degli Xeon a 64 bit, Itanium verrà di fatto relegato ad una nicchia del mercato di fascia alta; la terza ragione è che l'entrata di Intel nel settore dei chip x86 a 64 bit avrà l'effetto di accelerare in modo significativo la transizione del mercato dei PC, anche quello desktop, verso i 64 bit.

La prima domanda che tutti si sono posti è se le istruzioni a 64 bit di Intel siano compatibili con quelle di AMD: se così non fosse, infatti, lo standard x86 rischierebbe, dopo oltre trent'anni di vita, di spaccarsi in due. Su questo punto Barrett è stato abbastanza vago, limitandosi a dire che, sebbene la tecnologia Clackamas sia differente da quella AMD64, "è probabile che la stragrande maggioranza dei software e dei sistemi operativi girino su entrambe le piattaforme".
Nonostante il boss di Intel abbia deliberatamente usato il condizionale, appare quanto mai probabile che le istruzioni base di Clackamas e AMD64 siano le stesse. Alcuni osservatori hanno persino ipotizzato che Intel si sia limitata, facendo leva su di un vecchio accordo di cross-licensing con la rivale, ad implementare nei suoi chip le specifiche alla base dell'estensione x86-64 di AMD.

A dimostrare la stretta compatibilità fra le due soluzioni, all'IDF Microsoft ha annunciato che le stesse versioni di Windows a 64 bit compatibili con le CPU di AMD - che non a caso il big di Redmond ha genericamente denominato "for Extended Systems" - supporteranno anche i processori IA-32e di Intel. "Ci sarà un solo sistema operativo capace di supportare tutte le estensioni a 64 bit", ha confermato un portavoce di Microsoft.

Anche alcuni fra i maggiori distributori di Linux, fra cui Red Hat, Suse e MontaVista, hanno già annunciato il rilascio, durante la seconda metà dell'anno, di versioni dei propri sistemi operativi compatibili con le CPU a 32/64 bit di Intel.

La più sostanziale differenza fra l'architettura "estesa" di Intel e quella di AMD sarà probabilmente rappresentata dall'adozione di un diverso insieme di istruzioni multimediali, probabilmente un ampliamento delle SSE, che Barrett ha definito "migliore di 3DNow".
TAG: hw
38 Commenti alla Notizia Speciale/ Processori allo scontro
Ordina
  • Sapete dove si possono trovare dei benchmark ?
  • E tutta questa accozzaglia di device elettronici (costose fonti di ulteriori radiazioni elettromagnetiche insieme ai gia presenti frigo, forni a microonde, televisori ecc..) dovrebbe girare sotto winzoz?
    argh...




    sh4d
    non+autenticato
  • Ho appena comprato un Athlon64 3200, ed ho subito fatto le prove che più mi stavano a cuore, per capire se in effetti i 64bit possono essere un vantaggio anche per noi utenti desktop "normali.

    Ho installato Fedora Core 1 per x86-32 e Fedora Core 1beta x86-64 e gli ho fatto fare le stesse operazioni: bzip2 ed md5sum (programmi che calcolano intensivamente) su di grossi file.

    Beh, con mio grosso stupore (e felicità!) gli stessi programmi, sugli stessi dati, semplicemente ricompilati a 64 bit sono stati più veloci di circa il 40% e 30% rispettivamente!

    WowSorride

    Jugi

    P.S.: Ovviamente ho fatto attenzionie che il grosso file che ho usato per fare le prove (circa 700Mb) stesse tutto in cache in modo da non dipendere dalla velocità del disco
    non+autenticato

  • - Scritto da: Anonimo
    > Ho appena comprato un Athlon64 3200, ed ho
    > subito fatto le prove che più mi
    > stavano a cuore, per capire se in effetti i
    > 64bit possono essere un vantaggio anche per
    > noi utenti desktop "normali.
    >
    > Ho installato Fedora Core 1 per x86-32 e
    > Fedora Core 1beta x86-64 e gli ho fatto fare
    > le stesse operazioni: bzip2 ed md5sum
    > (programmi che calcolano intensivamente) su
    > di grossi file.
    >
    > Beh, con mio grosso stupore (e
    > felicità!) gli stessi programmi,
    > sugli stessi dati, semplicemente ricompilati
    > a 64 bit sono stati più veloci di
    > circa il 40% e 30% rispettivamente!

    Decisamente non male... resta da capire (almeno per me) se la velocità dichiarata da AMD (i famosi 3.2 GHz di un ipotetico P4 equivalente) siano riferiti al codice a 32 bit o a quello a 64 bit.....
    non+autenticato
  • - Scritto da: Anonimo
    > > Beh, con mio grosso stupore (e
    > > felicità!) gli stessi programmi,
    > > sugli stessi dati, semplicemente
    > ricompilati
    > > a 64 bit sono stati più veloci di
    > > circa il 40% e 30% rispettivamente!

    Lo stesso incremento che ho provato con mano sul mio nuovo G5 (monoprocessore 1.6Mhz) contro il vecchio G4 (daul processor 1Ghz) usando Photoshop (con solo il plug-in 64 bit!!! ) Cinebench e FinalCut 4.1.1 ottimizato per G5

    ...ma quando ho provato ha dirlo su questo Forum degli ..."ingegnieri" mi hanno dato del troll macchista, sostenendo che passando sui 64 l'incremento doveva essere "non più di un 5%"...e che stavo dicendo delle sciocchezze per fare un piacere ad Apple...plagiato dal marketing...

    ...che i 64bit sono utili sono se necessiti di più di 8 Gb di RAM e amenità varie...

    ...io oggi a 6 mesi di distanza, ho molti più software ottimizzati per G5 (OSX Panther in primis) e loro probabilmente usano lo stesso PC di allora convinti di avere il meglio....

    mah...tra un anno voi avrete Win2006 a 64 e gli stessi di cui sopra grideranno al miracolo...

    ...cmq sono contento per te, anche se per dare una pecentuale devi dichiarere prima rispetto a che cosa...

    Ciao
    FinalCut
    non+autenticato

  • - Scritto da: Anonimo
    ...
    > Ciao
    > FinalCut

    Incremento di prestazioni fra G4 e G5 a parte... in effetti leggendo il tenore del resto del tuo post... si: sono daccordo con chi ti ha dato del troll....

    Ciao.... e.... dacci un taglio... se è finale anche meglio....
    non+autenticato
  • Qualcuno di voi programma in C su piattaforma a 64 bit?

    Quali accortezze occorre usare quando scrivo un programma per tale piattaforma?

    Gli int, float etc a quanti bit sono? 32 ?
    E i double a 64?
    E' verto che solo i puntatori saranno a 64 bit?

    non+autenticato

  • - Scritto da: Anonimo
    > Qualcuno di voi programma in C su
    > piattaforma a 64 bit?
    >
    > Quali accortezze occorre usare quando scrivo
    > un programma per tale piattaforma?
    >
    > Gli int, float etc a quanti bit sono? 32 ?
    > E i double a 64?
    > E' verto che solo i puntatori saranno a 64
    > bit?

    Praticamente tutti i linguaggi ad alto livello hanno tipi anche a 128bit.
    Cambieranno i puntatori come dici, e si potranno indirizzare maggiori quantita' di memoria.
    Non so se alcuni linguaggi hanno dei tipi interi a 32bit che diventeranno a 64 bit, previa riscrittura dell'interprete o del compilatore (se linguaggio interpretato o compilato).

    non+autenticato

  • - Scritto da: Anonimo
    > Qualcuno di voi programma in C su
    > piattaforma a 64 bit?
    >
    > Quali accortezze occorre usare quando scrivo
    > un programma per tale piattaforma?
    >
    > Gli int, float etc a quanti bit sono? 32 ?
    > E i double a 64?
    > E' verto che solo i puntatori saranno a 64
    > bit?

    Il fatto e' che se vuoi programmare per bene in un qualsiasi linguaggio ad alto livello uno dei primi accorgimenti e' cercare di NON sapere a quanti bit sono i tipi primitiviSorride

    non+autenticato

  • - Scritto da: Anonimo
    >
    >
    > Il fatto e' che se vuoi programmare per bene
    > in un qualsiasi linguaggio ad alto livello
    > uno dei primi accorgimenti e' cercare di NON
    > sapere a quanti bit sono i tipi primitiviSorride

    queste cose le può dire solo se stai studiando, e al 99% studi e non hai mai scritto codice su queste piattaforme.

    http://groups.google.it/groups?hl=it&lr=lang_it&ie...
    non+autenticato

  • - Scritto da: Anonimo
    > > uno dei primi accorgimenti e' cercare
    > > di NON sapere a quanti bit sono i tipi
    > > primitiviSorride
    >
    > queste cose le può dire solo se stai
    > studiando, e al 99% studi e non hai mai
    > scritto codice su queste piattaforme.

    Non si studia più l'overflow? Sorride
    non+autenticato

  • - Scritto da: Anonimo
    >
    > Il fatto e' che se vuoi programmare per bene
    > in un qualsiasi linguaggio ad alto livello
    > uno dei primi accorgimenti e' cercare di NON
    > sapere a quanti bit sono i tipi primitiviSorride
    >

    http://punto-informatico.it/p.asp?i=47014

    Microsoft Internet Explorer Integer Overflow in Processing Bitmap Files Lets Remote Users Execute Arbitrary Code

    http://www.securitytracker.com/alerts/2004/Feb/100...

    Se non conosci quanti bit vengono usati per i tipi primitivi ecco cosa succede.
    non+autenticato

  • - Scritto da: Anonimo
    > Qualcuno di voi programma in C su
    > piattaforma a 64 bit?
    >
    > Quali accortezze occorre usare quando scrivo
    > un programma per tale piattaforma?
    >
    > Gli int, float etc a quanti bit sono? 32 ?
    > E i double a 64?
    > E' verto che solo i puntatori saranno a 64
    > bit?

    aehm.. purtroppo amd a furia di rimbambirvi con il marketing per star dietro a IBM tende ad omettere alcune cose fondamentali che chiariro' una volta per tutte, magari senza approfondire troppo per evitare suicidi in diretta e crisi letargiche

    Il 64bit di AMD non e' un processore 64 bit puro (ovviamente), esistono gia' processori, architetture e sw a 64 bit che funzionano molto bene (mips,alpha,sparc ecc..)ma ovviamente non per il mercato consumer e nemmeno per il prosumer.

    il 64bit amd funzionera' quasi sempre in legacy mode, cioe' fara' girare istruzioni a 32/16 bit esattamente come fa adesso (in modalita' reale e protetta con memoria segmentata). Sara poi possibile sfruttare i 64 bit utilizzando il long mode in 2 submodalita':
    *compatibility mode (che e' quello che verra' utilizzato nel 100% dei casi), richiede un os a 64 bit, non e' richiesta la ricompilazione del codice, l'indirizzamento e' a 32 bit
    *submodalita' 64-bit con indirizzamento a 64bit e nuovi registri a 64bit (oltre ai soliti estesi a 64bit), e' richiesto un os a 64bit, ricompilazione di tutto il sw che non girera' sui vecchi os e sui vecchi computer

    Gli analisti affermano che non c'e' mercato per questo genere di applicazioni, io affermo che alcuni giochi potrebbero sfruttare la modalita' a 64bit per incrementi di prestazioni ma ATTENZIONE, il 64 bit di per se' non accelera nulla! Le migliorie teoriche dipendono solo dalla maggiore quantita' di memoria indirizzabile e dalla maggiore quantita' di registri a disposizione .


    detto questo continuate pure a programmare come sapete

    Mela Marcia (tm)
    non+autenticato
  • - Scritto da: Anonimo
    > [...]
    >
    > aehm.. purtroppo amd a furia di rimbambirvi
    > con il marketing per star dietro a IBM tende
    > ad omettere alcune cose fondamentali che
    > chiariro' una volta per tutte, magari senza
    > approfondire troppo per evitare suicidi in
    > diretta e crisi letargiche
    >
    > Il 64bit di AMD non e' un processore 64 bit
    > puro (ovviamente), esistono gia' processori,
    > architetture e sw a 64 bit che funzionano
    > molto bene (mips,alpha,sparc ecc..)ma
    > ovviamente non per il mercato consumer e
    > nemmeno per il prosumer.

    Non capisco da dove tiri fuori tutta questa "ovvietà".

    L'athlon64 _è_ un processore a 64 bit puro, con in più la possibilità di lavorare in modalità mista 64/32 bit.

    Se mi dici che probabilmente il 90% delle persone lo utilizzerà in questo modo, soprattutto perchè utilizza windows, ti do ragione.

    Ma non è certo l'unico modo di usarlo.

    In particolare esistono già Gentoo e Suse _native_ a 64 bit, dove tutto il codice (compreso il kernel) è a 64 bit puro.
    Al punto che, se non sbaglio, in Gentoo non è nemmeno possibile far girare applicazioni a 32 bit al contrario di Suse che invece fornisce delle librerie a 32bit per il codice legacy.

    Che guarda caso, per linux è pochissimo, perchè essendo che quasi tutto il sw è open source, nella stragrande maggioranza dei casi è sufficiente ricompilarlo per avere una versione nativa a 64 bit, e quindi guadagnarne in efficienza e prestazioni.

    Anche Debian sta preparando una versione a 64 bit della propria distribuzione e ci metterà parecchio proprio perchè si vuole assicurare che sia in grado di far funzionare fianco a fianco codice a 64 e 32 bit.

    Come loro stessi affermano infatti, fare una versione pura a 64 bit è ben più semplice, e già seguito da altre distribuzioni.

    Alex
    non+autenticato
  • > L'athlon64 _è_ un processore a 64 bit
    > puro, con in più la
    > possibilità di lavorare in
    > modalità mista 64/32 bit.
    ...
    > sufficiente ricompilarlo per avere una
    > versione nativa a 64 bit, e quindi
    > guadagnarne in efficienza e prestazioni.

    mi intrometto, avrei un paio di domande:
    1° ma i processori x86-64 saranno realmente in grado di indirizzare a 64 bit? qualcuno ha link su dove informarsi meglio marketing a parte?
    2° compilatori: ci sono già compilatori open source, e per quali linguaggi (ho la sfortuna di non lavorare prevalentemente in c-like), in grado di compilare le applicazioni per questi processori? (In effetti la domanda su come verranno gestiti i tipi non è affatto banale!)
    grazie.
    non+autenticato

  • - Scritto da: Anonimo
    > Che guarda caso, per linux è
    > pochissimo, perchè essendo che quasi
    > tutto il sw è open source, nella
    > stragrande maggioranza dei casi è
    > sufficiente ricompilarlo per avere una
    > versione nativa a 64 bit, e quindi
    > guadagnarne in efficienza e prestazioni.
    .....
    > Come loro stessi affermano infatti, fare una
    > versione pura a 64 bit è ben
    > più semplice, e già seguito da
    > altre distribuzioni.
    >
    > Alex
    Se non hai fatto casini coi tipi si.

    Problema: salvo su file una lista di interi.

    Poiche' il mio programma ricompilato suppone che gli interi
    siano improvvisamente divenuti a 64-bit cosa succede?

    Succede che prima leggo il numero di entries, poi le scrivo.
    Se le scrivi leggendo la dimensione reale della lista ok. Se
    invece fai dei calcoli piu' o meno manuali gia' hai un
    problema. Il problema e' che tu potresti leggere i 32-bit alti
    e scrivere una serie di zero.

    D'altra parte se usi un banale sizeof sulla versione a 64-bit
    ti restituisce 4, su quella a 32-bit 2.
    In questo modo tu scrivi sul tuo file una serie di numeri a 64-
    bit. Pero' l'utonto linux che ha la distro a 32-bit legge il numero
    di interi nella lista, fa il suo bel sizeof ottenendo due e poi
    legge. Risultato? Il primo e' corretto, il secondo e' zero, il
    terzo e' il secondo, il quarto zero, il quinto e' il tezo, il sesto
    e' zero, etc.

    A meno che tu non abbia utilizzato un typedef per stabilire
    che quella lista e' a 32-bit.
    Nel qual caso mi sfugge il concetto di "ottimizzazzione" e
    "codice nativo".
    Codice nativo vuol dire ricompilare e sperare che il
    compilatore ottimizzi per noi? Vuol dire utilizzare tipi
    sottodimensionati rispetto alla capacita' di un registro?

    Mah.
    non+autenticato
  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    > > Che guarda caso, per linux è
    > > pochissimo, perchè essendo che
    > quasi
    > > tutto il sw è open source, nella
    > > stragrande maggioranza dei casi è
    > > sufficiente ricompilarlo per avere una
    > > versione nativa a 64 bit, e quindi
    > > guadagnarne in efficienza e prestazioni.
    > .....
    > > Come loro stessi affermano infatti,
    > fare una
    > > versione pura a 64 bit è ben
    > > più semplice, e già
    > seguito da
    > > altre distribuzioni.
    > >
    > > Alex
    > Se non hai fatto casini coi tipi si.
    >
    > Problema: salvo su file una lista di interi.
    >
    > Poiche' il mio programma ricompilato suppone
    > che gli interi
    > siano improvvisamente divenuti a 64-bit cosa
    > succede?
    >
    > Succede che prima leggo il numero di
    > entries, poi le scrivo.
    > Se le scrivi leggendo la dimensione reale
    > della lista ok. Se
    > invece fai dei calcoli piu' o meno manuali
    > gia' hai un
    > problema. Il problema e' che tu potresti
    > leggere i 32-bit alti
    > e scrivere una serie di zero.
    >
    > D'altra parte se usi un banale sizeof sulla
    > versione a 64-bit
    > ti restituisce 4, su quella a 32-bit 2.
    > In questo modo tu scrivi sul tuo file una
    > serie di numeri a 64-
    > bit. Pero' l'utonto linux che ha la distro a
    > 32-bit legge il numero
    > di interi nella lista, fa il suo bel sizeof
    > ottenendo due e poi
    > legge. Risultato? Il primo e' corretto, il
    > secondo e' zero, il
    > terzo e' il secondo, il quarto zero, il
    > quinto e' il tezo, il sesto
    > e' zero, etc.
    >
    > A meno che tu non abbia utilizzato un
    > typedef per stabilire
    > che quella lista e' a 32-bit.
    > Nel qual caso mi sfugge il concetto di
    > "ottimizzazzione" e
    > "codice nativo".
    > Codice nativo vuol dire ricompilare e
    > sperare che il
    > compilatore ottimizzi per noi? Vuol dire
    > utilizzare tipi
    > sottodimensionati rispetto alla capacita' di
    > un registro?
    > Mah.

    Ecco, non per fare polemica, ora ti spiacerebbe spiegarmi che cosa c'entra in tutto questo discorso l' "utonto linux"?
    O uno ha la laurea in ingegneria elettronica o e' un' utonto?
    L' UTENTE non esiste?
    Lo dico senza nessuna vena polemica quindi non ti arrabbiare, voglio solo far riflettere sul significato di quello che si dice/scrive; le abitudini possono essere una buona cosa ma a volte sono diaboliche...
    Lo scrivo perche' pure io sono spesso caduto in questo tranello: sapendo molte cose (ma ammetto che molte altre mi mancano) relegavo gli "altri" alla categoria degli utonti... un po' come se l' elettricista considerasse tutti quelli che non sanno fare il suo mestiere (in pratica tutti i suoi clienti o potenzialmente tali) un branco di fessacchiotti....

    ==================================
    Modificato dall'autore il 19/02/2004 14.28.53