Newsgroup: it.comp.hardware.cpu
Titolo: AMD rilascia Mobile Athlon XP

Finalmente, oserei dire:
http://hit.edengames.net/index.php?id=EpEApFkAFllKQyJfxm
Un altro ottimo spunto di discussione è questo "Do ut des":
http://hit.edengames.net/index.php?id=EpEApFyEklUrBoclWR
Saluti.
--
//   Xelloss da Bologna  || in real life: Wilmer Ricciotti   \\
|  
wirix...@libero.it
 (elimina il demone per rispondermi)  |
|    ICQ: 3233084        IRC: Xelloss@AzzurraNet, @ChatNow    |
| Hardware Information & Technology: 
http://hit.edengames.net
 |
\_______Like the Phoenix I rise from the ashes of life________/

 
http://hit.edengames.net/index.php?id=EpEApFyEklUrBoclWR
Beh...........
bisogna vedere quanto spinge Intel.
Un Windows 64 per Hammer sarebbe uno smacco
non da poco per la IA64.
Secondo me faranno di tutto per boicottarlo... :-(
Ciao

 Secondo me faranno di tutto per boicottarlo... :-(
AMD sta facendo un gioco "d'amicizia" con Microsoft... schierandosi dalla
sua parte sull'impossibilità di creare un kernel modulare per Windows :o)
Penso che Microsoft possa ripagare abbondantemente con Windows XP 64 per i
processori AMD...
--
+ > Piersandro Guerrera <-> PaRRoT <-> 
par...@edengames.net
  < +
-> PGP Key Available - 
http://parrot.edengames.net/pgpkey.asc
 <-
+ > ICQ: 8372114 <--> Eden.Games - 
http://www.edengames.net
  < +
+ > 
http://news.edengames.net
 <---> 
http://hit.edengames.net
 < +

 processori AMD...
Dubito che a WXP, se non per ragioni di marketing,
servano i 64 bit.
Semmai per W2K, che si trova a dover fronteggiare Linux
(settore server), che ha gia` il supporto per x86-64.
bye,
-- 
  Piergiorgio Sartor

 (settore server), che ha gia` il supporto per x86-64.
E Windows.NET ovviamente. Ma a quel punto tanto vale portare anche Windows
XP, no?


 XP, no?
Beh, direi che ha priorita` di gran lunga piu` bassa.
Mi pare, poi, che WXP supporti il multiprocessing,
cosa ben piu` interessante per il K8.
Vi potrebbero, pero`, essere ragioni di marketing,
come accennato, cioe` la possibilita` di dire:
"guardate che WXP e` true 64 bit OS".
Il primo shot dovrebbe essere con W2K, comunque.
bye,
-- 
  Piergiorgio Sartor

 Il primo shot dovrebbe essere con W2K, comunque.
Il punto è che Windows 2000 non è più in sviluppo... tu hai visto Windows
2000 per IA64? A parte qualche beta, io no. Windows XP per IA64 invece è
uscito, e Win.NET è in arrivo..
Il punto è che quando hai portato Win.NET a 64 bit, da un lato hai
praticamente portato anche WinXP, dall'altro è facile portarlo su qualsiasi
piattaforma a 64 bit. Non dubito che se usciranno versioni di Windows per
AMD64, tra di esse ci sarà anche WinXP professional, anzi, forse sarà quello
che uscirà per primo, perché MS vorrà testare le versioni .NET più
accuratamente.
Il multiprocessing, comunque, è supportato a partire da WinXP Professional,
e non su WinXP Home.


 uscito, e Win.NET č in arrivo..
Vabbe`, sara` WNET, sempre per il settore server,
comunque, non per il settore desktop.
Cioe` e` chi fa andare i serve che richiede i 64 bit,
per l'utente desktop non ha molti vantaggi.
bye,
-- 
  Piergiorgio Sartor

 per l'utente desktop non ha molti vantaggi.
Per l'utente desktop non sarà indispensabile, ma è pur sempre un 10-15% di
prestazioni in più...


 prestazioni in più...
*Solo* per l'indirizzamento a 64 bit? Naaaa...
Sara` per tutta l'architettura (a pari clock).
bye,
-- 
  Piergiorgio Sartor

 *Solo* per l'indirizzamento a 64 bit? Naaaa...
No no, principalmente per il raddoppio dei registri GPR e per l'incremento
di compattezza del codice che ne consegue.


 Poi considera che Sledge vedrà la luce 6 mesi dopo Claw.
Ma il passaggio a 64 bit non avrebbe benefici reali,
solo di immagine o marketing, per WXP.
A meno che tu non ti riferisca ad un generico
supporto per K8, oltre le estensioni a 64 bit.
D'altro canto per un OS tipo W2K, e per tutto quello
che gli gira attorno (IIS, SQL server, etc.) vi sarebbe
un vantaggio notevole.
Tra l'altro anche per i DB la cosa si fa interessante,
non solo per gli OS. Bisognera` quindi vedere anche
cosa fara` Oracle, sempre che non abbia gia` fatto
qualcosa, al riguardo.
Un DB server a 64 bit, high performance, per x86 su
Linux, sarebbe un duro colpo per MS. E per intel,
se non esce anche lei con x86-64 *compatibile*.
IA-64, in quest'ottica, sembra parecchio fuori gioco,
o comunque sembrerebbe occupare un ruolo marginale.
Preso tra i server Sparc/PPC high end e i server
x86-64 mid/low end.
Se non gli trovano un mercato adeguato, non so a
cosa potrebbe servire. A meno che non abbia prestazioni
assolutamente straordinarie, cosa che non sembra
essere, al momento.
bye,
-- 
  Piergiorgio Sartor

essere, al momento.
Viste le previsioni del Prescott? Due ALU a 32bit a 8Ghz a 1.2V, più cache L1 e
L2, miglioramenti a SMT che portano il vantaggio prestazionale al 50%...
Ci sarà anche quello che romperà le palle a Itanium... Poraccio quell'IA-64..
nato morto
-- 
e-mail:dialtone#/N0SPAM/#@
aruba.it
|Non vorrei piacere a tutti
togliere #N0SPAM# per inviare     |Avrei meno stima di me stesso
Powered by Debian Woody           |Se piacessi a certa gente
Co-Responsabile Hardware Information & Technology 
http://hit.edengames.net

 nato morto
Troppi ritardi, se fosse uscito un anno fa avrebbe
senza dubbio avuto piu` fortuna, a questo punto o
lasciano perdere, o si inventano qualche cosa di
incredibilmente straordinario.
Per esempio per il multi processing...
bye,
-- 
  Piergiorgio Sartor


...e direi anche grazie alle migliorie date dal controller di memoria DDR
incorporato e da quelle che verranno introdotte all'interno dei chipset
di supporto a queste nuove cpu (come collegmanenti Hypertrasnport e co.).
Ciao.

 di supporto a queste nuove cpu (come collegmanenti Hypertrasnport e co.).
Sě, ma io mi riferivo alle migliorie offerte unicamente da x86-64. Sommando
a queste le altre innovazioni di Hammer, l'incremento di prestazioni puň
salire fino al 40%.


 Per esempio per il multi processing...
Intanto continuate a posizionare male Itanium..............e
la cosa è strana :-). Secondo Itanium diventerà ciò che hanno
deciso esso diventi; chi decide è la cordata Intel-Hp-Compaq
e Ibm a seguire. Le altre considerazioni sono accademiche e
K8 centra un tubo, visto che non ha alleanze (forse Sun? chissà).
Rimaniamo con i piedi a terra, vietato sognare, di questi tempi
Ciao.
Alberto

 solo di immagine o marketing, per WXP.
Io mi baso sui dati AMD, e questi parlano di 10-15% di prestazioni in più su
software generico per i 64 bit. Un incremento che non ha nulla a che vedere
con il resto dei miglioramenti (controller memoria ecc.), che offre
un'ulteriore 20-25% in più, anche in modalità a 32 bit.


 e Ibm a seguire.
Non ci vuole niente ad abbandonare un accordo, vedi intel con Rambus, se
itanium si dovesse dimostrare un pseudo flop, hp-compaq-e a seguire ibm
abbandoneranno immediatamente itanium per qualcosa altro, sono daccordo
anche io con Piergiorgio, fosse già uscito avrebbe avuto grosse possibilità,
ma ora io lo vedo già morto

 ma ora io lo vedo già morto
Intanto Itanium non è un flop e lo sai...........:-).
Secondo dove sono le alternative?
Alpha? morto. Ultrasparc? è di Sun quindi non fa testo.
PaRisc? in pensionamento. Power 4? altra fascia (stellare).
K8 ? non è una cpu alto livello e non lo vuole essere (ne può).
P4 ? come sopra.
Cosa rimane? dove sono gli sviluppatori Alpha?
Ormai è assodato che per il 2004-2005 una buona
fetta del mercato ''tosto'' sarà Intel. Concorrenti?
Ibm nel settore di punta, Sun.
Non facciamo ''server dreams'' per favore ;-).
Ciao.
Alberto.

 Be... Il K8 puo` funzionare anche senza la compatibilita` con x86...
A dire il vero  no. Anche con un OS a 64bit  la compatibility mode viene
attivata  per  i programmi  a  32  bit  (individualmente, a  livello  di
segmento  di codice). In  pratica puoi  avere in  esecuzione processi  a
32bit contemporaneamente a quelli a 64bit.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
#include <stdio.h> 
int main(void) {printf("\t\t\b\b\b\b\b\b");
printf("\t\t\b\b\b\b\b\b");return 0;}

Alpha? morto.
I capi di Compaq non la pensano cosi'... E' appena uscito EV7 e ci sono progetti
di Alpha fino al 2025, DIVISI dai progetti Intel.


32bit contemporaneamente a quelli a 64bit.
Non è questo che intentevo. Intendevo dire che non è un core espanso di x86 ma
un vero e proprio core a 64bit.


 ...e direi anche grazie alle migliorie date dal controller di memoria DDR
Quello e` anche un bel colpo dal punto di
vista dei costi, dato che il DDR controller
e` estremamente costosto, specie per alte
frequenze (costo del NB + MB).
Spostare il costo nella CPU, significa ridurre
di fatto il costo della MB, che non deve piu`
preoccuparsi di due bus (CPU-NB e NB-DRAM), ma
solo di uno, che potra`, inevitabilmente, essere
migliore (piu` spazio per il routing) ed economico.
Questo agevolerebbe, se corretto, l'entrata
nel settore desktop.
bye,
-- 
piergiorgio

 K8 centra un tubo, visto che non ha alleanze (forse Sun? chissà).
Centra eccome, se centra.
Il progetto IA-64 nasce con l'idea di sostituire,
a lungo termine, IA-32.
Passando a 64 bit, ma con incompatibilita`.
Cosa possibile, nella strategia globale
pianificata all'inizio.
In cui intel aveva il controllo completo del
mercato IA-32, di fatto.
Il problema e` che x86 ha raggiunto IA-64,
in un modo o nell'altro.
Quindi che senso avrebbe IA-64?
Solo per casi specifici, ma forse piu`
unici che rari.
Eppoi, a proposito di immaginazione e realta`,
cosa ti sembra piu` "reale" x86-64 o IA-64?
bye,
-- 
piergiorgio

 software generico per i 64 bit. Un incremento che non ha nulla a che vedere
Diffidirei da certe affermazioni generiche.
Immagino che vi siano benchmark che possono
portare a questi risultati, ma dubito fortemente
che Quake4 (per esempio), giri il 10% piu` veloce
*solo* perche` ha indirizzamento a 64 bit.
Vi sara` altro, sicuramente.
bye,
-- 
piergiorgio

 di Alpha fino al 2025, DIVISI dai progetti Intel.
Si, ma in questo ha ragione, Alpha e` morto.
Perche` non ha mercato.
bye,
-- 
piergiorgio

 K8 ? non è una cpu alto livello e non lo vuole essere (ne può).
Non hai capito il K8. Piu` che altro
non hai capito il mercato a cui il K8
si rivolge.
Questo puo` essere diverso da quello IA-64,
ma e` piu` lucroso.
Nessuno ha mai fatto i soldi veri con i
supercomputer, i soldi stanno nei server
mid/high/low end (nell'ordine).
In questo mercato il K8 si propone (sempre
da verificare, poi) come un'alternativa
validissima, sia per costi che per scalabilita`.
Certo, come diceva Bohr, fare previsioni e`
sempre difficile, soprattutto sul futuro ;-)
bye,
-- 
piergiorgio

 di Alpha fino al 2025, DIVISI dai progetti Intel.
Oooops roba di un anno fa............
prima che mollassero il settore cpu, con
tutti i relativi testoni :-).
Con cosa sviluppano ora Alpha ?
Ciao.
Alberto.

 sempre difficile, soprattutto sul futuro ;-)
Perň č bello e stimolante farlo.
Ciao.
Alberto.

 *solo* perche` ha indirizzamento a 64 bit.
Minchia però, sono 10 volte che dico che l'indirizzamento a 64 bit non
c'entra una sega ^^;
Gli x86 lisci hanno 8 registri GPR, dei quali in condizioni normali se ne
possono utilizzare 6 o 7; tutto ciò, nonostante i salti mortali dei
compilatori, si traduce in quantità enormi di accessi in memoria, che
tendono a rallentare il codice TANTO. AMD64 ha 8 registri GPR in più, quindi
riduce enormemente la necessita di load/store. Un 10-15% di prestazioni in
più per questo motivo è plausibilissimo.


 cosa ti sembra piu` "reale" x86-64 o IA-64?
IA-64 esiste, x86-64 è da venire e sopravviverà
se Intel darà corda, altrimenti....kaput.
Ci sono stati vari esempi di tentativi di rottura con
il principe, negli ultimi 15 anni, ma quali sono andati
in porto?
Non sopravvalutiamo Amd, ha lo stesso peso finanziario
di tre anni fa; sappiamo che solo quello conta, purtroppo.
Ciao.
Alberto.

 più per questo motivo è plausibilissimo.
Hehehehehehehehe ma guarda ! prima si pompa un futuro
omnicomprensivo per x86-quanto vuoi, poi ci si accorge che i
duecento registri di vario tipo di una cpu come IA-64,
o Ultrasparc o Power 4 o Alpha, ''forse'' servono :-).
Ciao.
Alberto.

 o Ultrasparc o Power 4 o Alpha, ''forse'' servono :-).
IA64 ha un'architettura tale da non poter fare a meno di centinaia di
registri, e non è difficile intuire il perché.
Architetture più tradizionali sguazzano in quantità di registri comprese 16
e 32. Gli ingegneri AMD (puoi stare certo che il problema è stato pesato
perché in un progetto così delicato come una nuova ISA non si lascia nulla
al caso, tanto meno caratteristiche tanto importanti) hanno deciso che 32
registri GPR non avrebbero garantito un miglioramento di prestazioni se non
in poche applicazioni.


 di renderlo meno appetibile ad un nuovo concorrente ;-).
Sicuramente, sono sempre attenti a conrollare
la situazione, nessuno e` statico, ne` intel
ne` tantomeno AMD.
Il problema, soprattutto per AMD, e` che le
scelte vanno fatte con qualche anno di anticipo
e` quindi le scommesse sono piu` rischiose.
Questo perche` intel si e` sempre dimostrata
piu` veloce a cambiare.
Il caso IA-64, pero`, e` emblematico.
Io ero convinto che fossero in grado di accellerare
quando e come avessero voluto.
Non mi pare sia successo, la CPU che propongono
non e` quello splendore che potrebbe essere o
che *dovrebbe* essere.
Un cluster con 64 K8 potrebbe (per es.) diventare piu`
interessante, sia come costi che come prestazioni,
di una simile configurazione IA-64.
Insomma K8 e` un sasso nello stagno quieto di intel,
IA-64 non e`, per intel, la risposta al K8, e` la
domanda.
Naturalmente, come detto sopra, la situazione e`
fluida e non statica, quindi mi aspetteri una
qualche altra risposta da intel.
bye,
-- 
  Piergiorgio Sartor

 adatto ovvio.
Certo, questo *dovrebbe* essere il vantaggio,
pero` potrebbe darsi, ripeto, che una soluzione
cluster con K8 sia piu` conveniente come costo
e come prestazioni (assolute) dell'equivalente
IA-64, non e` piu` chiaro chi definisca il
limite superiore, a questo punto.
bye,
-- 
  Piergiorgio Sartor

 c'entra una sega ^^;
Io parlavo *solo* dei 64 bit di indirizzamento.
Perche` questo consente, con minima modifica dell'OS
e di alcuni applicativi, di spingere le prestazioni
per il settore server (dove serve l'OS server, pero`).
Settore lucroso, in cui AMD non ha ancora messo piede.
Le altre modifiche richiedono piu` sforzo per chi
scrive compilatori, sforzo paragonabile a quello
di scrivere il compilatore per IA-64.
Quindi il vantaggio e` minimo, in questo caso.
bye,
-- 
  Piergiorgio Sartor

prestazioni in più...
non necessariamente, considera l'hovehead su disco/ram, usandolo con
applicazioni "piccole" e su sistemi relativamente piccoli qualcosa ci
rimetti per forza (intasa il disco come minimo... immaginati a
ricompilare a "64bit" tutte le dll sparpagliate per l'hd con la solita
efficienza microsoftiana...) - e' su grossi server che hai guadagni su
tutta la linea.
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

deciso esso diventi; chi decide è la cordata Intel-Hp-Compaq
fai Intel - hp/compaq (qualunque forma finisca per prendere questo
amalgama) stanno decisamente prendendo in considerazione l'idea di
mollare ia-64 visti gli scarsi risultati (know-how, brevetti e rete
distribuitiva non gli mancano di sicuro - compaq ha perso quasi tutte
le licenze alpha ma hp continua a sviluppare in grande stile PA...).
se Intel non riesce a piazzare un grosso hit _IN FRETTA_ si trova sola
e nei guai fino al collo.


Intanto Itanium non è un flop e lo sai...........:-).
al momento e' il piu' grosso flop della storia intel - l'attuale
modello ha assorbito il piu' grosso investimento in un unico
processore mai fatto da intel ed ha venduto letteralmente zero.
per recuperare le perdite mckinley dovrebbe vendere a livello di
processore desktop prima di venire pensionato per il prossimo modello
(perche' ovviamente ogni modello deve ammortizzare gli investimenti
per ricercare il successivo...), ho qualche dubbio che ce la faccia.


Oooops roba di un anno fa............
facciamo tre, purtroppo.
Alpha e' morto e sepolto, questo e' indubbio.


 tutta la linea.
Ovviamente i guadagni sono diversi a seconda dell'applicazione, ma ricordo i
dati rilasciati da AMD:
- le dimensioni del codice crescono di meno del 10%
- il numero statico di istruzioni diminuisce del 10%
- il numero dinamico di istruzioni diminuisce almeno del 5%
- il numero dinamico di Load/Store diminuisce del 20%
- il tutto senza nessuna ottimizzazione specifica.
Specialmente la diminuzione delle Load/Store è talmente grande che, a mio
avviso, non potrà non avere conseguenze...


 di scrivere il compilatore per IA-64.
Non posso essere d'accordo. Scrivere un (buon) compilatore per IA64 è 10
volte più difficile che scriverne uno per AMD64. Oltretutto, le innovazioni
di AMD64, semmai, semplificano il lavoro di chi progetta il compilatore.


bye,
--
    (iao!!oai)                                    (ICQ: 10860566)


 di AMD64, semmai, semplificano il lavoro di chi progetta il compilatore.
Diciamo che scrivere un compilatore e`
*sempre* difficile.
Non conosco IA-64 nei dettagli, ma se e`
appena ortogonale, diventa molto piu`
facile che non per quella baracca di x86.
Che K8 possa semplificare x86, puo` essere,
il compilatore sara` piu` facile da scrivere
relativamente ad un x86 standard.
Ma qui saltiamo ad un altro punto, cioe` al
fatto che intel produce compilatori, AMD no,
si affida a gcc. Il che non e` bene.
Il compilatore intel per Pentium produce
codice dal 10% al 20% migliore di gcc.
Il livello tecnico che hanno e` notevole.
bye,
-- 
piergiorgio

 Il livello tecnico che hanno e` notevole.
Si sa, comunque i compilatori intel sono ben lontani dall'essere i più
usati.


Piergiorgio Sartor wrote:
 > Le altre modifiche richiedono piu` sforzo per chi
 > scrive compilatori, sforzo paragonabile a quello
 > di scrivere il compilatore per IA-64.
IMHO un compilatore per x86-64 "che produce
codice decentemente ottimizzato" e' relativamente
semplice rispetto a quelli per IA64.
I GPR raddoppiano ed anche se c'e' un aggravio
(in decodifica ed in occupazione di memoria delle istruzioni)
nell'accesso ai secondi 8 il vantaggio
rispetto ad un accesso in memoria e' enorme
e si possono usare schemi di ottimizzazione
"gia collaudati" su altre cpu.
Con i "famigerati" registri XMM, visto che
a differenza che con IA32 sono standard
(e quindi ha senso perdere tempo ad ottimizzarne
   l'utilizzo da parte del compilatore)
si puo procedere in due stadi successivi.
1) dammi-un-fottuto-compilatore-che-sfrutti-gli-XMM:
     si usano in "modo scalare"
     considerandoli come 32 registri a doppia precisione
     indipendenti tra loro con la "penalizzazione" che
     con la parte alta si possono usare solo le MOV;
2) dammi-con-calma-un-compilatore-che-sfrutti-bene-SSE2:
     si usano i registri in "modo scalare" ma si assegnano
     dinamicamente alle variabili ed alle espressioni parziali
     in modo tale da massimizzare i casi in cui si esegue
     la stessa operazione sulla parte alta e quella
     bassa (in modo da usare le istruzioni vettoriali).
Ci sono poi i registri MMX, ma ho il sospetto che
si possano tranquillamente ignorare visto che sembrano
essere li solo per compatibilita con il passato.
La complessita di un simile compilatore mi sembra sul livello
di quello di una cpu RISC (so bene che non e' una cosa banale
ma e' decisamente piu semplice rispetto ad IA64)
e rispetto agli IA32 si sta nel paradiso dei registri
(senza l'incubo dell' IA64, ovvero "ho troppi registri
   e non so che farne senza mettere in crisi altre
   parti della cpu").
L. Micheletto

Alpha e' morto e sepolto, questo e' indubbio.
Per la serie: non basta la qualita'. T_T
Su, prendiamo il lato buono: se e' vero che i cervelloni si sono
trasferiti alla Intel, finalmente risaranno in grado di progettare
cpu. ):-)
-- 
Le razioni di cioccolata verranno aumentate a 20 grammi
dal film/libro:1984 - George Orwell (grazie Skip)
(nel film questa frase sostituisce: le razioni di cioccolata non verrano abbassate sotto i 25 grammi)

 usati.
Sono usati come riferimento di qualita`, il
che non e` poco.
Non saprei, per esempio, se il compilatore Microsoft
ha tecnologia intel, magari solo per uso interno di
Microsoft stessa. Tanto il codice gira anche su AMD,
anche se con differenti prestazioni.
bye,
-- 
  Piergiorgio Sartor

 semplice rispetto a quelli per IA64.
Il problema e` anche un altro, da considerare
profondamente e da non sottovalutare.
Problema che non si pone o si pone in misura
minore per il solo discorso 64 bit.
Cioe` una volta che ho scritto codice ottimizzato
per x86-64, questo gira anche su normali x86?
Non sembrerebbe, da quello che leggo, quindi non
ha assolutamente senso compilare in maniera ultra
ottimizzata per x86-64, dato che si perderebbe una
buona fetta di altro mercato (oltre che tempo).
Probabile che la gente di gcc & Linux, avendo il
gusto di ricompilarsi tutto, sia la prima a sfruttare
tale CPU, ma questo non e` sempre il top del mercato.
Persino Redhat continua a distribuire la quasi
totalita` dei suoi pacchetti come i386, solo alcuni
(kernel & relativi) sono *anche* i586 o i686.
Insomma, se le SW house devono perder tempo per
produrre software per x86-64, non vedo perche` non
dovrebbero farlo anche per IA-64, dove per altro
sono *obbligati* a farlo, in qualche modo.
Il compilatore non e` il problema, dato che intel
comunque ha la capacita` di fornirlo, cosa che AMD
non sembrerebbe avere.
bye,
-- 
  Piergiorgio Sartor

buona fetta di altro mercato (oltre che tempo).
Questo è il problema contrario... Non vedo motivi per porsi questa compatibilità
col passato da parte x86-64.
L'obbiettivo sia di AMD che di Intel è quello di migrare a 64bit, Intel ha
deciso di farlo dando una mazzata al passato, AMD ha deciso di farlo
gradualmente. Quando non sarà più necessario mantenere la compatibilità a 32bit
perchè tutto il software è scritto con AMD64 allora si passa a processori a
64bit.
Vedrai che anche Intel farà cosi'. Chi ha cercato di fare rivoluzioni in passato
ha sempre ottenuto l'effetto opposto di fallire a propria volta... E in seguito,
ma solo in seguito, sul suo esempio si è poi gradualmente costituito il tutto...
-- 
e-mail:dialtone#/N0SPAM/#@
aruba.it
|Non vorrei piacere a tutti
togliere #N0SPAM# per inviare     |Avrei meno stima di me stesso
Powered by Debian Woody           |Se piacessi a certa gente
Co-Responsabile Hardware Information & Technology 
http://hit.edengames.net

 col passato da parte x86-64.
Questione di mercato, se x86-64 non e` compatibile,
tanto vale usare IA-64, ti pare?
Per questo insisto sul 64 bit di indirizzamento
e non sul resto.
Questo e` il vantaggio: avere un x86 con 64 bit
di indirizzamento copre facilmente il settore
server, low/mid e persino high.
Tutto il resto e` fumo, come MMX, 3DNow!, SSExyz...
Nessuno si prende la briga di scrivere codice
ottimizzato, se poi rischia di non vederlo
funzionare su le altre CPU, specialmente intel.
bye,
-- 
  Piergiorgio Sartor

cpu. ):-)
per il vero di "cervelloni" ne erano rimasti davvero pochi del team
originale al momento dell'acquisto del reparto alpha da parte di intel
(la maggior parte se li era pappati AMD, alcuni sono andati a nvidia
se non ricordo male, altri si sono messi in proprio...).
di licenze e brevetti d'altro canto ad intel ne sono andati tanti, una
vera miniera d'oro.


 per x86-64, questo gira anche su normali x86?
Pretendi di far girare codice a 64 bit su processori a 32 bit? Non ti seguo,
mi sono perso dei pezzi?
Saluti.
--
//  Xelloss dal portatile || in real life: Wilmer Ricciotti  \\


per x86-64, questo gira anche su normali x86?
il codice x86 a 32bit gira sugli 8088? 
certo, per molto tempo sara' indispensabile avere versioni parallele a
32 e 64bit (come prima a 16 e 32bit), ma se anche intel si butta sulla
nuova isa ci mettera' relativamente poco a divenire uno standard.


 mi sono perso dei pezzi?
A parte che e` possibile, il problema e`
sempre lo stesso: a parita` di tutto,
conviene rimanere il piu` possibile
compatibili con x86.
Per la modalita` 64 bit, dentro un OS,
la soluzione e` facilissima, per gli altri
casi non lo e`. Almeno nel breve/medio periodo.
bye,
-- 
piergiorgio

 nuova isa ci mettera' relativamente poco a divenire uno standard.
Questo e` un discorso ancora diverso,
se intel passa a x86-64, allora AMD
avra` altri problemi.
Il discorso era la contrapposizione
IA-64 vs. x86-64.
Il mio punto e` che x86-64 puo` avere
successo perche` (e solo perche`) puo`
garantire compatibilita` x86 e coprire,
con uno sforzo relativamente piccolo, il
settore server, ad ampio spettro.
Il resto, piu` registri ed ammennicoli
vari, potrebbe avere senso sul lungo
periodo, ma come diceva Keynes (mi pare),
sul lungo periodo saremo tutto morti.
In particolare, sul lungo periodo, IA-64
potrebbe spuntarla, dato che ricompilare
per ricompilare, x86-64 od IA-64 non farebbe
troppa differenza.
Spero di aver chiarito il mio pensiero.
bye,
-- 
piergiorgio

 casi non lo e`. Almeno nel breve/medio periodo.
Non concordo, e in ogni caso non è preoccupante. Se i sistemi operativi
supportano una certa piattaforma a 64 bit, completamente compatibile con
software a 32 bit già esistente, c'è assoluta libertà per il resto del
software di passare ai 64 bit se e quando se ne sentirà il bisogno.


 Spero di aver chiarito il mio pensiero.
Non troppo, a dire il vero...


Xe||oss dal portatile wrote:

-- 
piergiorgio

 software di passare ai 64 bit se e quando se ne sentirà il bisogno.
Che vuol dire "preoccupante"?
Appunto, c'e` assoluta liberta`, il che vuol
dire, come esperienza dimostra, il piu` tardi
possibile.
Quindi la chiave del possibile successo e`
solo ed esclusivamente la capacita` di
estendere x86 a 64 bit, non il resto di
accorgimenti che ci hanno messo, quelli
sono solo biscottini per il marketing.
bye,
-- 
piergiorgio

 hanno seguito il tradizionale approccio RISC, che rimane il migliore?
Perche` VLIW e` meglio di RISC.
A saperlo fare, pero`... :-)
bye,
-- 
piergiorgio

hanno seguito il tradizionale approccio RISC, che rimane il migliore?
ci vuole sempre qualcuno che sperimenti nuove strade - in intel
pensavano che le nuove tecnologie produttive permettessero di portare
il vliw "esteso" pure in campo generico competitivamente. 
al momento pare non ci siano riusciti, ma un plauso per il tentativo
se lo meritano comunque.


troppa differenza.
fa differenza - sotto x86-64 ti puoi limitare a riscrivere/ricompilare le routines 
"critiche" sfruttando i nuovi registri  e features (cosa che ti semplifica 
molto la vita pure se le scrivi a mano in assembler...) lasciando il resto 
com'e', sotto ia-64 non basta neppure ricompilare ma devi riorganizzare l'intero 
software fin dalla base per sfruttare al meglio la gestione esplicit-vliw (il che e'
una follia per la filosofia di base dei vliw ma ia-64 cosi' funziona...)


 "critiche" sfruttando i nuovi registri  e features (cosa che ti semplifica 
Sempre piu` d'accordo, per questo mi riferivo
al discorso OS per x86-64.
Pensa che Linux per x86-64 ha solo un paio
di file modificati, quelli per la gestione
della paginazione virtuale.
Non vedo, pero`, senso a ricompilarsi, per
esempio, Office, per X86-64.
Cioe` quel 15% in piu` non lo vedremo per
un po', dubito che le SW house si mettano
a vendere SW per IA-32 e SW per x86-64.
Solo a livello di OS e` possibile, come
scrivi tu stesso, avere qualche "patch" per
sfruttare alcune caratteristiche del K8.
bye,
-- 
piergiorgio

 A saperlo fare, pero`... :-)
E' un'affermazione che ho sentito da tante parti, ma ancora non mi pare sia
stata dimostrata. Un conto è la teoria, un altro la realtà. Magari per
sfruttare VLIW servono semplicemente tecnologie di cui ancora non
disponiamo.
Non nego che IA64 sia diversi ordini di grandezza più raffinato di AMD64,
purtroppo, però, finora è stato un fiasco su tutta la linea. AMD invece
tenta di avvicinare x86 al RISC, il che è un'impresa disperata; eppure,
apparentemente, paga.
"A saperlo fare", dici... devo credere che ad Intel siano tutti incapaci?
Sprecare svariati miliardi e 5 anni o più, per uscirsene con un prodotto di
cui è difficile intravedere i vantaggi?


Piergiorgio Sartor wrote:
 > Il discorso era la contrapposizione
 > IA-64 vs. x86-64.
 >
 > Il mio punto e` che x86-64 puo` avere
 > successo perche` (e solo perche`) puo`
 > garantire compatibilita` x86 e coprire,
 > con uno sforzo relativamente piccolo, il
 > settore server, ad ampio spettro.
Questo e' ovvio ma ..
 > Il resto, piu` registri ed ammennicoli
 > vari, potrebbe avere senso sul lungo
 > periodo, ma come diceva Keynes (mi pare),
 > sul lungo periodo saremo tutto morti.
IMHO ha importanza pure a "breve" termine.
Il nuovo set d'istruzioni fornisce un incentivo
in piu a ricompilare anche le applicazioni
che "guadagnano poco" dal puro passaggio ai 64bit
ma che "guadagnano abbastanza" (da giustificare
la ricompilazione) sfruttando le feature aggiuntive.
Lo sforzo primario di AMD nel settore delle cpu
e' creare una ampia base di utenza e di sviluppatori
prima che IA64 possa iniziare ad erodere
troppo il settore dei pc x86 compatibili.
x86-64 ha tante "feature" piu evolutive che rivoluzionarie
fatte per attirare utilizzatori, sviluppatori e costruttori
con esigenze diverse.
Non sono solo i 64bit, non e' solo la compatibilita
con gli x86, e' l'insieme ad essere "interessante".
 > In particolare, sul lungo periodo, IA-64
 > potrebbe spuntarla, dato che ricompilare
 > per ricompilare, x86-64 od IA-64 non farebbe
 > troppa differenza.
 >
 > Spero di aver chiarito il mio pensiero.
Chiarissimo, ma questo spero sia ovvio per tutti.
Il problema e' che oltre ad essere "diverso"
da un x86, IA64 e' partito male nonostante
l'impegno massiccio di Intel per lanciarlo bene.
Prima lanciano il Merced, poi si tirano indietro
presentandolo come una specie di "prototipo", poi
ci riprovano con il McKinley ma lo tengono a 0.18
per dare spazio ai P4 Northwood.
Se AMD riesce a spingere in alto il confronto
in termini di prestazioni tra x86-64 e P4/P5
alla fine per quanto potenzialmente interessante
IA64 verra' "suicidato" da Intel stessa.
L'unica vera ancora di salvezza per IA64
e' costituita da MS .Net e da Linux, ma mentre
Linux non da problemi (una volta che il compilatore
va bene), con MS .Net c'e' il problema dei driver
per le varie periferiche (a meno che non sia possibile
scrivere device driver decenti in CIL).
L. Micheletto

 sono solo biscottini per il marketing.
8 registri in più sarebbero biscottini per il marketing? Un guadagno di
prestazioni di più del 10%? Attento a definire questo marketing, c'è una
folla inferocita di persone che potrebbe decidere di lanciarti contro
processori che vanno più veloci in internet...


 prestazioni di più del 10%? Attento a definire questo marketing, c'è una
Non esiste nessun guadagno del 10%,
dato che il codice ricompilato non
esiste e non esistera` per parecchio
tempo, perche` nessuno (tranne quelli
dell'Open Source) si sognera` di
produrre codice diverso da x86-32,
almeno per un po'.
Office ricompilato per x86-64 chissa`
quando lo vedremo...
Il settore server e` diverso, come
detto, ma ha anche diversi concorrenti.
bye,
-- 
piergiorgio

 cui è difficile intravedere i vantaggi?
Tu cosa proponi? Sono incapaci od hanno
qualche carta ancora da giocarsi?
bye,
-- 
piergiorgio

 Linux non da problemi (una volta che il compilatore
Linux e` anche il primo supporto di x86-64.
Sostanzialmente non e` di parte e, con l'appoggio
di Sun, sara` il primo sistema server su K8.
Prima di Microsoft.
bye,
-- 
piergiorgio

 qualche carta ancora da giocarsi?
Qualcuno avrebbe detto: HyperThreading su Itanium. Non riesco a immaginare
come si possa implementare HT su un'architettura come IA64, tutto ciò puzza
di ristrutturazione dell'ISA. Quanti anni aveva detto Intel che doveva
durare IA64? 20? 30?...


 detto, ma ha anche diversi concorrenti.
...ecco, però nel settore server può essere solo peggio, perché è
ultraprobabile che AMD non sfondi se non dopo anni di tentativi; e bada
bene, non per inferiorità di prestazioni o di stabilità, ma per l'assoluta
assenza di supporto da parte degli OEM. Allora soprattutto in questo settore
il software commerciale scarseggerà, mentre occorrerà sfruttare il software
open-source...
Tutto questo, naturalmente, dimenticandosi .NET e MSIL.


 Tutto questo, naturalmente, dimenticandosi .NET e MSIL.
Vabbe`, ma 'sta roba e` sempre un punto
interrogativo, al momento non mi pare
abbiano realmente indirizzato l'attuale
mercato, ma tentino di crearne uno nuovo,
quindi bisognera` vedere...
bye,
-- 
piergiorgio

 durare IA64? 20? 30?...
Secondo me, se non provvedono un supporto,
tipo HT, per il multiprocessing, sono ancora
piu` fuori dal mercato di prima.
Avrei dei dubbi sulla volonta` di farlo,
immagino che non avrebbe giustificazioni
economiche, si spendono miliardi per poi
accorgersi che manca un pezzo?
Meglio non accorgersene... :-)
bye,
-- 
piergiorgio

Piergiorgio Sartor wrote:
 > Lorenzo Micheletto wrote:
 >
 >> Il nuovo set d'istruzioni fornisce un incentivo
 >> in piu a ricompilare anche le applicazioni
 >> che "guadagnano poco" dal puro passaggio ai 64bit
 >> ma che "guadagnano abbastanza" (da giustificare
 >> la ricompilazione) sfruttando le feature aggiuntive.
 >
 >
 > Cosi` come avrebbe senso ricompilare tutto
 > per P4, invece che per generico i386.
 > Non funziona, nessuno ricompila per produrre
 > codice un po' migliore e per giunta incompatibile
 > con il resto del mondo.
Vediamo due momenti diversi di un possibile scenario.
Se ho ben capito tu vedi la cosa dal punto di vista
di chi deve scegliere tra portare/sviluppare applicazioni
da 32bit a 64bit per x86-64 oppure per IA64, io invece
parto considerando uno scenario in cui gli x86-64 sono
gia diffusi ed usati come x86 "piu veloci".
L. Micheletto

 da 32bit a 64bit per x86-64 oppure per IA64, io invece
No, non ci siamo, si vede che non mi sono
spiegato bene.
Esistono, diciamo per semplificare, due
mercati diversi: quello server e quello
desktop (o "office" o "personal", se vuoi).
Esiste poi il settore OS ed il resto, cioe`
SW piu` o meno specifici, tipo Office e
compagnia bella.
Gli OS per server (e qualche SW particolare)
beneficiano moltissimo dall'indirizzamento
esteso a 64 bit (ma anche 40 bit, bastano).
Cioe` allo stato attuale, avere 64 bit di
indirizzamento, per i server, considerando
le modifiche minime all'OS, e` una soluzione,
non solo accettabile, ma addirittura molto
appetibile. E` cio` che manca, di fatto
(per la classe x86, ovviamente).
K8 ha come grande vantaggio la possibilita`
di fornire cio`, con sforzo minimo, dato che
e` ancora x86 compatibile.
IA-64 si pone piu` in la', non rende la
vita del programmatore cosi` facile.
Nel momento in cui, pero`, si decide di
passare tutto il SW all'architettura x86-64,
cioe` si decide di ricompilare tutto per
la nuova CPU, usando tutte le estensioni
che questa provvede, quindi ottimizzando
pesantemente per x86-64, il vantaggio verso
IA-64 si perde.
Ricompilare milioni di righe di codice per
x86-64, testarle, e ritrovarsi con SW che
gira *solo* su x86-64 e lo stesso che fare
questa procedura per IA-64, magari con vantaggi
prestazionali maggiori nel secondo caso (e lo
stesso e` per Alpha, PPC o Sparc, alla fine).
Questa procedura, per una o per l'altra CPU,
conviene solo nel momento in cui la quota
di mercato (delle CPU) e` alta, altrimenti
non conviene farlo, ma conviene rimanere
ancora a x86-32.
Chiaramente questo avvantaggia K8, rispetto
a IA-64, ma non rispetto a P4 o K7.
Cioe` il vantaggio del 10%~15%, in caso di
ricompilazione specifica x86-64, non credo
sia cosa che si vedra` presto, per cui non
lo considero neanche come un vantaggio del
K8, sono numeri per il marketing.
Globalmente, ripeto, il K8 e` in vantaggio
su IA-64, ma per i seguenti punti:
1) Facile scalabilita`, dato HT
2) Compatibilita` x86, parecchio SW gira
senza modifiche.
3) Indirizzamento esteso, in aggiunta
ad 1) e 2) per server di un certo livello
(e per qualche SW particolare, tipo Data
Base enterprise).
4) Costi relativamente contenuti.
Questi punti non toccano il mercato desktop,
ovviamente, ma pare che AMD stessa si voglia
confrontare con IA-64, prima che con P4.
Ovviamente alcuni punti, come 1) e 3), danno
grossi vantaggi anche verso P4 (P5?).
In sostanza il progetto K8 mi sembra parecchio
positivo, tutto considerato direi che le scelte
tecniche sia state ben ponderate, ad occhio la
CPU si presenta bene, anche come longevita`.
Il passo successivo (K9? P5?) sara` quello di
avere un cache L2 (o L3) in tecnologia DRAM,
cioe` un transistor per bit, contro i sei
delle celle SRAM attuali.
Quindi 6 volte piu` capace a pari transistor
oppure sei volte piu` piccola a pari capacita`.
bye,
-- 
piergiorgio

ancora a x86-32.
Non sono d'accordo. In un caso basta ricompilare, nell'altro devi riscrivere il
codice in modo ordinato per sfruttarlo con quella architettura.
-- 
e-mail:dialtone#/N0SPAM/#@
aruba.it
|Non vorrei piacere a tutti
togliere #N0SPAM# per inviare     |Avrei meno stima di me stesso
Powered by Debian Woody           |Se piacessi a certa gente
Co-Responsabile Hardware Information & Technology 
http://hit.edengames.net

 codice in modo ordinato per sfruttarlo con quella architettura.
In quale caso scusa?
Comunque, allo stato attuale del SW, basta
ricompilare, sia per un x86, che per un RISC.
Dato che quasi tutto il SW in circolazione
e` scritto in linguaggi tipo C o simili.
bye,
-- 
piergiorgio

e` scritto in linguaggi tipo C o simili.
Ovviamente nel caso di x86-64 basta ricompilare nell'altro no. E' proprio la
filosofia di programmazione che cambia.


L2, miglioramenti a SMT che portano il vantaggio prestazionale al 50%...
E si vedrà il vero P4 finalmente... beh meno male che si sono decisi!
:-)
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
Tessera #008 BAG, #000 DPPSJ, #013 BAT, #012 TFC
"Il Grande Fratello? Non lo farei mai vedere ai miei figli."
(Giovanni Modina, direttore di Canale 5)

in porto?
Nessuno, ma il principe è intel o l'architettura x86?
La stessa intel ha provato in passato ad affossarla ed è sempre dovuta
tornare indietro.


Intanto Itanium non è un flop e lo sai...........:-).
L'architettura è potenzialmente ottima, ma i ritardi sono paurosi...


oppure sei volte piu` piccola a pari capacita`.
Il rovescio della medaglia è che una SRAM è più veloce di una DRAM...
e visto che la cache deve essere MOLTO veloce, bisogna vedere se il
compromesso è accettabile.


 wrote:
 >
 >
 >>Ricompilare milioni di righe di codice per
 >>x86-64, testarle, e ritrovarsi con SW che
 >>gira *solo* su x86-64 e lo stesso che fare
 >>questa procedura per IA-64, magari con vantaggi
 >>prestazionali maggiori nel secondo caso (e lo
 >>stesso e` per Alpha, PPC o Sparc, alla fine).
 >>Questa procedura, per una o per l'altra CPU,
 >>conviene solo nel momento in cui la quota
 >>di mercato (delle CPU) e` alta, altrimenti
 >>non conviene farlo, ma conviene rimanere
 >>ancora a x86-32.
 >
 >
 > Non sono d'accordo. In un caso basta ricompilare, nell'altro devi riscrivere
 > il
 > codice in modo ordinato per sfruttarlo con quella architettura.
No, sotto questo punto di vista ha ragione Sartor.
In entrambi i casi si fa il porting principalmente di codice ad alto livello
(i casi in cui si usa l'assembly sono molto ristretti) e ci si affida
al compilatore per le ottimizzazioni specifiche della cpu e per quelle
indipendenti dagli algoritmi (quelle "generiche").
A questo punto, supponendo (ottimisticamente) che tutto il resto sia a posto
(S.O., librerie esterne di terzi, ecc. ecc.) entrano in gioco due classi
di bug difficili da identificare velocemente perche spesso sfuggono ai primi
test e si manifestano in modo indiretto (spesso producono crash
e malfunzionamenti in *altre* parti del codice, non dove sono localizzate):
1) dipendenze implicite dalla cardinalita/dimensione dei tipi di dati;
2) bug e "feature" del compilatore.
Se il codice e' gia "64bit clean" (es: supporta la ricompilazione
su Alpha o su UltraSparc) magari le bug di tipo 1) sono gia state
quasi tutte rimosse, ma restano ancora quelle di tipo 2) e possono
essere particolarmente rognose.
Sotto questo punto di vista fare il porting verso x86-64 o IA64
e' la stessa cosa.
L. Micheletto

 filosofia di programmazione che cambia.
In qualunque caso basta ricompilare,
non e` che si scrive in C per x86 oppure
in C per Alpha.
bye,
-- 
  Piergiorgio Sartor

 compromesso č accettabile.
Il bello e`... che non e` vero! :-)
I tempi di accesso sono praticamente identici,
il problema e` costruttivo.
Mescolare tecnologia DRAM con tecnologia per
CPU (+SRAM) non e` facile, ci provano in molti,
con successi parziali.
bye,
-- 
  Piergiorgio Sartor

il problema e` costruttivo.
Si, ma un DRAM necessita comunque di cicli di refresh (soprattutto
quando si scende a certe dimensioni), questo in parte rallenta...
Ovviamente bisogna quantificare: se si rallentasse del 10% ma questo
permettesse di triplicare la cache (non dico sestuplicare perchè
qualcosa mi dice che in ogni caso non ce la si fa ;) ) potrebbe essere
comunque conveniente...


 comunque conveniente...
La soluzione e` relativamente semplice, dal
punto di vista della circuiteria.
Dato che la cache ha accessi in qualche modo
prevedibili, e` possibile generare cicli di
refresh in maniera ottimale, cioe` senza
collidere con gli accessi.
Per esempio questo gia` avviene, in qualche
modo, con le SDRAM che supportano il 2-way
o 4-way bank interleaving.
Esiste poi una ditta (fabless) che ha progettato
una memoria DRAM che appare come SRAM, in cui il
refresh viene fatto insieme al ciclo di accesso.
Questo pero`, a mio avviso, ha l'inconveniente di
aumentare il consumo energetico della cella, cosa
non sempre auspicabile, soprattutto in una CPU che
gia` consuma troppo di suo... :-)
bye,
-- 
  Piergiorgio Sartor

compromesso č accettabile.
come cache di terzo livello e' perfetta.
immaginati di averne 16 o 32mb (considerando un processore in classe
server e' una stima anche conservativa), con sotto 512kb di l2 rapida
- se quella dram viaggia sull'ordine dei 2ghz con latenze a manetta e'
comunque schifosamente veloce rispetto alla ram di sistema....
.
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

 compromesso è accettabile.
Per come crescono le frequenze il compromesso e' piu che accettabile.
Pensa a questo esempio "improvvisato" (i dati sono presi a spanne, servono
giusto per avere dei numeri a cui fare riferimento):
1) cpu a 2Ghz con 512KB "SRAM" di L2 che lavorano alla stessa frequenza;
2) cpu a 2Ghz con una L2 "DRAM" da 2Mbyte che lavora a mezza frequenza.
[N.B. A) considero che anche se i transistor calano da 6 ad 1, parte
  del "risparmio" non viene sfruttato o viene usato per altro, tipo
  le connessioni delle celle che circa quadruplicano a loro volta]
[N.B. B) non e' detto che la L2 "dram" lavori a mezza frequenza rispetto
  alla cpu, potrebbe anche viaggiare a piena frequenza ma con latenze piu alte
  della sram]
Con 512KB e' molto piu frequente "uscir fuori" verso
la ram ed anche supponendo di avere DDR a 400Mhz
si viaggia ad 1/5 della velocita della cpu e si hanno
latenze molto piu alte che con una L2.
Sempre con lo stesso rapporto tra core della cpu ed L2
considera una cpu a 3..4GHz, il vantaggio di una cache L2
a mezza frequenza ma ampia almeno il quadruplo diventa
sempre piu evidente visto che piu e' ampia la cache e meno
il bus verso la ram (o verso le altre cpu nel caso di una cpu
"stile K8") "strozza" le prestazioni, inoltre avere un ampia area
del chip che viaggia a mezza frequenza aiuta a tener sotto controllo
i consumi ed il calore prodotto.
L. Micheletto

 come cache di terzo livello e' perfetta.
Ci aggiungo un'altra offerta :-)
Perche` non usarla come banco di memoria,
invece che come cache?
Per esempio si potrebbero mappare i primi
X megabyte su quella DRAM on-board ultra
veloce (rispetto alla DRAM di sistema) e
piazzarci, per esempio il kernel del sistema
operativo. La latenza agli interrupt diventerebbe
minima, con ottimi guadagni prestazionali di
tutto l'insieme.
bye,
-- 
  Piergiorgio Sartor

piazzarci, per esempio il kernel del sistema
fattibile ma non compatibile con i s.o. attuali, dovresti customizzare
parecchio...
btw tralasciando i casi "non proprio voluti" tipo le schede con i430xx
e piu' ram di quanto le tag riescano a coprire, non e' la prima volta
che sistemi "asimmetrici" del genere esistono.
prendi ad esempio l'amiga - i primi 512kb (1mb-2mb a seconda della
versione del chipset) erano condivisi con il chipset grafico e quindi
con latenze di accesso altissime, sulle macchine con acceleratrice i
successivi 8mb erano a 16bit mentre la memoria veloce a 32bit (propria
delle acceleratrici) veniva allocata nello spazio Z3 (oltre i 16mb).
il s.o. era tranquillamente in grado di gestire la situazione,
allocando la memoria a partire da quella piu' veloce e sfruttando
quella piu' lenta soltanto dopo aver saturato il resto...
non e' difficile da implementare ma Windows non e' fatto per questo,
andrebbe riscritto un bel po' di cose.
sotto linux la cosa e' leggermente piu' semplice da realizzare (piu'
che altro perche' puoi mettere le mani sul codice...).


 parecchio...
http://hit.edengames.net/index.php?id=EpEAVyVZyAZqoGmyYI
Direi che su un sistema operativo NUMA dovrebbe andare come il cacio sui
maccheroni...
--
//   Xelloss da Bologna  || in real life: Wilmer Ricciotti   \\
|  
wirix...@libero.it
 (elimina il demone per rispondermi)  |
|    ICQ: 3233084        IRC: Xelloss@AzzurraNet, @ChatNow    |
| Hardware Information & Technology: 
http://hit.edengames.net
 |


maccheroni...
non sono sicuro che la cosa sia molto pratica al giorno d'oggi, imho
sono piu' utili usati come cache che come "fast kernel" quei mega
(dopotutto non stiamo parlando esattamente di processori desktop)...
questo in single-processing, farlo in mp, anche via i canali rapidi
dei processori numa moderni, sarebbe un incubo (quando un processore
deve accedere alla e-dram dell'altro....)


collidere con gli accessi.
Un problema possibile: se c'è bisogno di accedere + volte alla linea
di cache bisogna tutte le volte aspettare il refresh, cmq...


 di cache bisogna tutte le volte aspettare il refresh, cmq...
Affatto, se accedi alla stessa linea, non
c'e` bisogno di refresh, l'accesso ad una
DRAM e` equivalente al refresh.
D'altro canto e` possibile fare un refresh
di una linea, in parallelo con l'accesso
ad un altra.
bye,
-- 
piergiorgio