Link alla notizia: http://www.hwupgrade.it/news/cpu/intel-presenta-sette-nuovi-processori-itanium_23108.html

In arrivo nuovi processori della famiglia Itanium, contraddistinti da consumi più contenuti e alcune caratteristiche interessanti

Click sul link per visualizzare la notizia.

ma è ancora vivo? attualmente il confronto con il POWER6 è imbarazzante, ma lo è anche il confronto con uno xeon di ultima generazione; è un processore vecchio e nato male, pensino se caso a svilupparne uno completamente nuovo al posto che prolungare la sua agonia in questo modo

Mi dici come fai a fare un paragone con uno Xeon? Sull'architettura Itanium gira solo software dedicato.

Francamente penso che più che gli Xeon il problema di Intel siano gli Opteron.
Non scordiamo che nel mercato server AMD ha una posizione molto forte.
Mi dici come fai a fare un paragone con uno Xeon?
Probabilmente coi test come Linpack o applicativi usati in ambito server e datacenter.

Anche su Power, Sparc, Alpha etc gira solo software dedicato, eppure il confronto bisogna pur farlo, altrimenti come si fa a scegliere? :P

Prolungare l'agonia di Itanium è anche un modo per non lasciare con le chiappe per terra i clienti che ci hanno creduto. Penso che investimenti su macchine del genere abbiano orizzonti più lunghi e se il produttore non ci crede più dopo pochi anni, il cliente ingoia il rospo e in futuro acquisterà altrove.

Mi dici come fai a fare un paragone con uno Xeon? Sull'architettura Itanium gira solo software dedicato.

direi "anche" più che "solo"

Gli Xeon costano moolto gli opteron molto poco con il 2360SE ne vedremo delle belle..

direi "anche" più che "solo"
Eh ma temo che sull'"anche" il paragone proprio non provino neanche a farlo ^^''
(a meno che le cose non siano mirabolmente cambiate)

E comunque ribadisco che è ovvio che il paragone lo si possa fare!

E poi guardate che una versione di Linux "dedicata" con tutti i suoi programmi è appena un "make" per ogni piattaforma esistente! E poi si misura.

insomma qui non siamo di fronte ad un microprocessore general purpose ma ad un vero è proprio sistema di calcolo ad alta precisione.
oggi non esiste in processore paragonabile all'itanium.
tenete conto che i nostri processori a volte si perdono qualche bit per strada...l'itanium cerca di evitare questo....
per quanto riguarda le prestazioni sono assolutamente in linea se non superiori a quelle dei migliori processori general purpose in commercio...tenete conto che se poi dobbiamo stare a vedere solo le prestazioni pure mettendo da parte l'affidabilità le nostre GPU vanno piu' di qualunque cpu....e non costano poi tanto....
naturalmente se dovete fare calcoli strutturali per l'ingegneria aere spazione non ci si puo' permettere di sbagliare o approssimare i calcoli...se no gli aerei cadono........
ormai c'e' una frattura enorme tra i computer general purpose e i sistemi di calcolo avanzato....

E poi guardate che una versione di Linux "dedicata" con tutti i suoi programmi è appena un "make" per ogni piattaforma esistente! E poi si misura.

e questa dove l'hai tirata fuori, da topolino? Assolutamente falso, nel kernel spesso ci sono driver o ottimizzazioni specifici per una data architettura.
Ma anche nei programmi stessi non sempre funziona come dici tu.

Un semplice make non risolve tutti i problemi.

oggi non esiste in processore paragonabile all'itanium.
tenete conto che i nostri processori a volte si perdono qualche bit per strada...l'itanium cerca di evitare questo....
Homero sei stato ad un Intel Developer Forum di recente? Parli come un depliant pubblicitario. (quella del "qualche bit per strada" è divertente comunque :P)

Dai un occhiata ai supercomputer usati per il calcolo scientifico e conta quanti Itanium ci sono (si, li puoi contare)
http://www.top500.org/lists/2007/06

Se vai su "statistics" trovi subito cose interessanti come questa:
http://www.top500.org/stats/list/29/procfam/

Ah, qui c'è il mio prossimo pc, RoadRunner :D
http://en.wikipedia.org/wiki/IBM_Roadrunner

e questa dove l'hai tirata fuori, da topolino? Assolutamente falso, nel kernel spesso ci sono driver o ottimizzazioni specifici per una data architettura.

Un semplice make non risolve tutti i problemi.
Sob speravo di non dover specificare. :eh: oki: "make" funziona perché il codice (e i driver etc) per Linux ci sono per praticamente tutte le piattaforme, spesso prima che la piattaforma raggiunga il mercato.
Il senso in cui l'hai inteso tu ("make fa tutto da solo") ovviamente era così inconcepibile che avevo pensato non fosse necessario specificare. :p

Homero sei stato ad un Intel Developer Forum di recente? Parli come un depliant pubblicitario. (quella del "qualche bit per strada" è divertente comunque :P)

Dai un occhiata ai supercomputer usati per il calcolo scientifico e conta quanti Itanium ci sono (si, li puoi contare)
http://www.top500.org/lists/2007/06

Se vai su "statistics" trovi subito cose interessanti come questa:
http://www.top500.org/stats/list/29/procfam/

Ah, qui c'è il mio prossimo pc, RoadRunner :D
http://en.wikipedia.org/wiki/IBM_Roadrunner


se volevi smontare itanium e intel sei andato un po' fuori strada...
Intel IA-64 28 5.60 % 409801 471363 75412
Intel EM64T 231 46.20 % 1792543 2952457 275450

Intel EM64T ha il 46.20 % di share nella top500, e Intel IA-64 con il 5,60% di share nella top500 è terzo come Rmax sum... mi sembra che alla fine Itanium non faccia poi così schifo. Amd non vince nè come quantità nè come potenza (dove l'architettura power pc invece spinge parecchio, anche rispetto ad intel)

se volevi smontare itanium e intel sei andato un po' fuori strada...
E perché vorrei smontare Intel? O_o
I grafici che ho postato li ho letti anche io ^^''

Rispondevo ad Homero, che erroneamente pensava che solo gli Itanium fossero buoni nel calcolo scientifico. Invece il loro uso non eccelle neanche in quei campi (ma non so il motivo, e non è certo "l'incompatibilità del software").

Guarda che io sono triste che gli Itanium per qualche motivo non abbiano preso piede come atteso (guarda il grafico delle previsioni di vendita sulla pagina di wikipedia http://en.wikipedia.org/wiki/Itanium). Fosse stato per me, ben venga un'architettura nuova!

Dai un occhiata ai supercomputer usati per il calcolo scientifico e conta quanti Itanium ci sono (si, li puoi contare)
http://www.top500.org/lists/2007/06

Se vai su "statistics" trovi subito cose interessanti come questa:
http://www.top500.org/stats/list/29/procfam/



da un punto di vista techico non ha senso quello che dici perche nella lista top500 entrano i sistemi fatti per calcolo distrbuito, gli itanium hanno un mercato differente e non sono nati per fare batterie di centinaia a migliaia di server, vengono utilizzati in configurazioni ridotte di 1 o pochi server.

basta vedere il prezzo, con 1 sola cpu itanium top di gamma ti compri anche 10 cpu AMD o INTEL di prestazioni simili, che messe in parallelo vanno 10 volte meglio, questo non vuol dire che siano superiori giusto? ;)

E perché vorrei smontare Intel? O_o
I grafici che ho postato li ho letti anche io ^^''

Rispondevo ad Homero, che erroneamente pensava che solo gli Itanium fossero buoni nel calcolo scientifico. Invece il loro uso non eccelle neanche in quei campi (ma non so il motivo, e non è certo "l'incompatibilità del software").

Guarda che io sono triste che gli Itanium per qualche motivo non abbiano preso piede come atteso (guarda il grafico delle previsioni di vendita sulla pagina di wikipedia http://en.wikipedia.org/wiki/Itanium). Fosse stato per me, ben venga un'architettura nuova!

frainteso, scusa!

basta vedere il prezzo, con 1 sola cpu itanium top di gamma ti compri anche 10 cpu AMD o INTEL di prestazioni simili, che messe in parallelo vanno 10 volte meglio, questo non vuol dire che siano superiori giusto? ;)

oh, io non ho ancora capito qual è l'ambito in cui gli itanium eccellono, perchè se il problema è solamente l'affidabilità assoluta reputo decisamente più intelligente far eseguire lo stesso compito a due server con dentro gli "inaffidabili" x86 confrontando il risultato piuttosto che metterne uno solo che costa 10 volte

basta vedere il prezzo, con 1 sola cpu itanium top di gamma ti compri anche 10 cpu AMD o INTEL di prestazioni simili, che messe in parallelo vanno 10 volte meglio, questo non vuol dire che siano superiori giusto?
O_o ehi non è che volessi postare una verità assoluta, ma solo l'esempio di quel contesto.

E a dire il vero mi hai un pò confuso con questa risposta.
Perché dovrei preferire un Itanium a 10 x86 che vanno 10 volte meglio in parallelo? La maggior parte del software cpu-bound di solito è ben parallelizzato.
(sono certo che la riposta magari ci sia, ma è complessa)

Imho Intel farebbe volentieri a meno di Itanium. Il grafico su wikipedia che ho postato sopra è sconfortante (notare la differenza tra le stime in blu e le vendite in arancione), e l'andazzo futuro potrebbe orientarsi verso altre soluzioni (multicore x86 accoppiati con steam processors o roba tipo Cell)

Imho Intel farebbe volentieri a meno di Itanium.

visto gli investimenti continui e erormi che mette in campo per l'Itanium non so se l'intel la pensa allo stesso modo.

(notare la differenza tra le stime in blu e le vendite in arancione)

ora, o lo leggo male io o stanno arrivando adesso, dopo quasi 10 anni, all'obiettivo di vendita che si erano prefissi per i primi 6 mesi di commercializzazione???

oh, io non ho ancora capito qual è l'ambito in cui gli itanium eccellono, perchè se il problema è solamente l'affidabilità assoluta reputo decisamente più intelligente far eseguire lo stesso compito a due server con dentro gli "inaffidabili" x86 confrontando il risultato piuttosto che metterne uno solo che costa 10 volte

"confrontando il risultato" , scherzi vero :stordita:

ora, o lo leggo male io o stanno arrivando adesso, dopo quasi 10 anni, all'obiettivo di vendita che si erano prefissi per i primi 6 mesi di commercializzazione???
Chiaramente questo mi sembra dovuto anche ad un ritardo del lancio di Itanium di due anni. Certo però che anche confrontando con le stime successive non è che le cose siano andate tanto meglio.

Comunque le previsioni sono sempre in salita, questo sì. ^^

"confrontando il risultato" , scherzi vero
Qualcuno me la spiega questa storia dell'"affidabilità" del calcolo?
No, perché sapete, non è che sugli aerei/centraline delle automobili/sistemi per il calcolo di proteine medicinali/satelliti si usino Itanium sempre sempre...

Ho il sospetto che la storia dell'"affidabilità" sia stata quantomeno travisata.

oh, io non ho ancora capito qual è l'ambito in cui gli itanium eccellono, perchè se il problema è solamente l'affidabilità assoluta reputo decisamente più intelligente far eseguire lo stesso compito a due server con dentro gli "inaffidabili" x86 confrontando il risultato piuttosto che metterne uno solo che costa 10 volte

forse dipende da quanto è net-bound l'algoritmo da eseguire.
Programmi estremamente parallelizzabili scalano terribilmente bene ed è dove conviene l'uso di migliaia di x86, i gigaflops si calcolano sommando i flops di ogni singola gpu.
Afaik anche itanium è progettata al fine di rispondere ad esigenze di "parallelizzabilità" del calcolo, ma ovviamente vuoi mettere, in un algoritmo non perfettamente parallelizzabile, dove i threads necessitano di una comunicazione di una certa mole, l'esecuzione all'interno di una singola cpu dove i dati vengono scambiati da locazioni della cache, contro un'architettura dove i dati vengono sparati tramite rete, non c'è paragone.
Gli itanium sono nati per essere una nicchia.

Mi piacerebbe se qualcuno fosse più preciso perché ha esperienze nel campo, e se necessario mi correggesse.

"confrontando il risultato" , scherzi vero :stordita:

no, fanno il raid di tutto (ram compresa), non si capisce perchè i processori dovrebbero rimanerne fuori

a parte che non è di certo una novità, la nasa per i robottini su marte al posto che mettere 1 processore superaffidabile ha messo 3 processori normali che svolgevano le stesse operazioni per l'appunto in una sorta di RAID (3 perchè se sono in 2 e uno scazza bisogna ripetere l'operazione; se sono in 3 e uno scazza l'output dei due è quello reputato buono)... alla fin fine è più una questione di chipset a livello di scheda madre che di altro

oltre il fatto che non sei obbligato a fare un confronto per ogni singola istruzione macchina: laddove si hanno algoritmi complessi è pensabile un confronto anche solo software dei risultati (esempio: hai due server uguali, fai fare loro lo stesso calcolo, impiegano entrambi 10 ms; al termine dell'operazione si scambiano attraverso una banalissima gigabit - in questo caso, dato che il calcolo occupa un tempo relativamente lungo - il risultato e lo confrontano: se è uguale proseguono, se è diverso ricalcolano)...

l'idea di puntare a componenti superaffidabili è vecchia, bisogna pensare a componenti con buona affidabilità ridondanti, come la storia insegna

e anche la statistica: facciamo due conti. ipotizziamo che un processore consumer possa scazzegare un'operazione ogni 10^15 operazioni. ipotizziamo che un processore dedicato con tutti i controlli del caso riduca il rischio a una su 10^25 (rapporto di 1 a 10 miliardi, non ci credo manco se paul otellini si mette sotto la scrivania della lewinsky). se metti due processori del primo tipo in un ipotetico RAID il rischio si riduce a 1 su 10^30... ad un costo estremamente più contenuto.

in ogni caso, vedremo tra qualche anno quale strada seguiranno =)

Mah, non mi risulta che gli x86 siano così inaffidabili nei risultati o nella coerenza dei dati... Del resto, tutte le cpu possono avere dei bug, che nella maggior pare dei casi si risolvono con degli aggiornamenti via bios, ma in altri, più sfortunati, richiedono un intervento sull'hardware (cioè delle correzioni al progetto): se leggo bene, la news sembra parlare proprio di questo, cioè di errori di calcolo verificati in certe circostanze che adesso vengono corretti.

Ma il core level lock-step sembra riguardare anche l'integrità dei dati, e questo forse merita un (breve) discorso a parte. A grandi linee, gli x86 hanno dei meccanismi hardware sofisticati per garantire la coerenza dei dati nella cache (o nelle cache, nel calcolo distribuito) e per l'ispezione di cache non condivise; itanium, per filosofia progettuale (molto risc), ha una logica di "controllo" (passatemi il termine improprio) ridotta all'osso e delega la maggior parte dei compiti al compilatore/al software, concede anche di eseguire in parallelo i rami di un branch, per poi validare il risultato e scegliere il ramo corretto (in pratica, esegue dopo il criterio di scelta per ridurre l'impatto dei salti), ma il tutto è affidato al codice, che deve gestire in maniera ottimale i predicati. In quest'ottica, aggiungere dei meccanismi hardware per garantire l'integrità dei dati può solo portare dei vantaggi, a mio modo di vedere.

Tornando alla correttezza e alla perdita di bit per strada: per quanto riguarda il lato hardware, può essere una questione di correttezza nell'implementazione, ma così torniamo al discorso dei bug che saltano fuori e vengono corretti, perchè a meno di bug (che possono essere presenti in qualsiasi progetto), non capisco proprio perchè un moltiplicatore di un'alu debba dare risultati corretti una volta si e una no, a prescindere dal chiamarsi x86, itanium o power... Altro discorso quello della precisione: alcuni calcoli possono essere soggetti alla cancellazione numerica, quindi la precisione (= numero di bit elaborati) è essenziale, dato che un calcolatore opera su insiemi di numeri finiti e discreti (quantizzati). Ma in questo "ambito" possiamo distinguere due differenti aspetti: uno inerente il software, l'altro relativo alla logica di calcolo (= hardware). Per quanto riguarda il lato software, è importante la scelta oculata della tipizzazione per i dati, siano essi float (single o double), oppure interi (short, integer, long, signed o unsigned, ecc.), ma anche, e soprattutto, la corretta implementazione degli algoritmi: quella che può essere una banalissima operazione, come la risoluzione di un'equazione di secondo grado, se si ricerca il massimo della precisione richiede una valutazione preliminare dei dati (nell'esempio, i coefficienti e il termine noto), per scegliere la variante appropriata dell'algoritmo - in altri termini, prima di sputare sull'affidabilità del processore, guardiamo il software. Per quanto riguarda il lato hardware, gioca un ruolo importante l'implementazione interna: l'fpu di un itanium ha una precisione interna di 80 bit (se non ricordo male), pur essendo la massima precisione richiesta da un software pari a 64 bit; tuttavia, questa non è un'esclusiva di itanium, e la questione va inquadrata anche in un'altra prospettiva: le istruzioni SIMD di un x86 si possono implementare in modo da avere una precisione massima di 64 bit su due dati float elaborati in contemporanea, ma questo non è un vero problema, in quanto il software si aspetta comunque questa precisione, e le scelte relative alla cancellazione numerica vengono fatte sulla base del range di numeri descrivibili con 64 bit; ma itanium usa l'fpu anche per approssimare i risultati di operazioni su interi, che per loro natura non sono delle approssimazioni e possono essere maggiormente soggetti agli errori di troncamento (immagino che tutti in questo forum sappiamo bene che il confronto tra due float non è preciso come quello tra due interi, perchè i float sono numeri approssimati e sommati daranno un numero approssimato, gli interi invece no), ed ecco che la precisione degli itanium, laddove fosse maggiore, da dote di pregio diventa necessità assoluta, caratteristica indispensabile per ottenere un minimo di correttezza (ricordo che itanium ha anche due alu "tradizionali", che però vengono usate solo per le operazioni logiche e per i load/store).

Per il discorso "net-bound", di primo acchitto mi sembra molto simile ad una situazione memory-bound, e in questi casi la presenza o meno di una logica out-of-order fa sentire il suo peso. Se un algoritmo è molto ben parallelizzato, i vari thread condivideranno si grandi moli di dati, però tenderanno a monopolizzare l'accesso a quelli su cui stanno elaborando; però potrebbero esserci anche delle notevoli dipendenze, quindi una comunicazione frenetice e "abbondante" fra i thread, ma questo non influisce necessariamente sulla "bontà" del parallelismo: un algoritmo che organizza i suoi thread come in una catena di montaggio, ad esempio, può comunque consentire una buona scalabilità alle varie fasi dell'elaborazione, quindi la creazione di molti thread indipendenti per ciascuno stadio e lo sfruttamento adeguato di molte cpu, ma gli stadi dovranno comunque scambiare grandi quantità di dati, e questo non deve diventare un collo di bottiglia a prescindere (per questo nei supercomputer si usano soluzioni di comunicazione custom, basate sulla fibra ottica e spesso studiate - o adattate - per specifici problemi). Se invece alcune fasi dell'elaborazione non sono scalabili, allora esse stesse diventano dei colli di bottiglia, conta molto la potenza del singolo processore (e se si tratta di elaborazioni su interi, itanium non è la scelta migliore), ma credo di non sbagliare nel dire che in questi casi avremo a che fare o con situazioni memory bound, e/o con molti salti, quindi la logica ooo e un buon branch predictor possono fare la differenza.

Quanto alla cache, non è necessariamente un vantaggio: non è una memoria di accesso "rapido", diretto (random), ma una specie di database associativo in cui i dati vanno cercati, quindi più è grande e più aumentano le latenze di accesso (oltretutto, tra qualche decina di mega finirà col perdere i vantaggi intrinseci della sram verso la dram, perchè le minori latenze di una ram statica possono essere compensate dalle maggiori dimensioni complessive, quindi da perdite di segnale e crescita di latenze nelle piste). Alla fine, da vantaggi solo se (e finchè ) l'accesso alla ram fa da bottle neck, quindi, anche ammettendo dei casi in cui l'elaborazione nel singolo core ha il suo peso e le comunicazioni a mezzo cache condivisa fossero importanti, parlerei comunque di vantaggi non a rimanere nella stessa cpu, ma nella stessa macchina: un'architettura come quella degli Opteron, con MCH integrato e un bel pacco di ram dedicata al singolo processore, cui si accede in modo molto veloce, più i meccanismi dei nodi NUMA per accedere ai dati di un altro processore (con qualche latenza in più), e con linee di comunicazione dedicate ed efficienti (hyper transport) per far "parlare" i processori tra di loro, e meccanismi di ispezione delle cache e di coerenza dei dati tutt'altro che inaffidabili, può dire la sua (senza contare che HT si può usare anche per le comunicazioni tra più macchine).

IMHO, Intel continua ad investire su Itanium perchè ha già investito tantissimo, e deve cercare di ottenere un ritorno migliore dall'investimento, oltre che per non lasciare "a piedi" chi ha creduto nel progetto (per questo ha anche adottato un socket unico per itanium e xeon, e questo la dice lunga...)

Premetto che non ho mai visto un processore Itanium.

Però ho seguito la discussione e ho sentito di processori consumer che "scazzegano un'operazione ogni 10^15", sorridendo...

quindi vorrei precisare che per "errore" negli ambienti di calcolo scientifico si intende il fatto che non è possibile memorizzare in un calcolatore un numero con infinite cifre decimali , quindi è necessario procedere a troncamenti o arrotondamenti.

Questa piccola perdita di precisione iniziale può propagarsi e aumentare (propagazione dell'errore) quindi è necessario tenerne conto ed ovviare al problema con appositi algoritmi.

In quanto a prestazioni è chiaro che per questo genere di calcoli un architettura con registri del processore grandi è avvantaggiata rispetto a processori general pourpose a 32 bit.

I registri general purpose contengono interi, che per loro natura non sono soggetti a propagazione dell'errore (sugli interi non c'è nè arrotondamento, nè troncamento, il numero quello è e quello rimane). I problemi possono nascere se si usa l'fpu per elabrorare gli interi, come fa itanium, e allora serve una precisione maggiore.

Poi, itanium non ha registri grandi, ma un gran numero di registri, che in qualche misura sopperisce all'assenza di logica ooo, ma in generale non è un gran vantaggio: la quasi totalità degli algoritmi si ottimizza efficientemente con non più di 32 registri (e sono pochi quelli che ne richiedono più di 16), superato questo limite si introducono delle latenze. L'idea dei registri a rotazione, per accelerare il passaggio da una subroutine all'altra e il ritorno al chiamante, può essere interessante, però la loro gestione non è semplice e produce latenze (la prima generazione di itanium doveva fermarsi e impiegare alcuni cicli di clock solo per questo, prima di poter riprendere l'elaborazione). Però itanium ha una fpu veramente molto veloce, ed è questo il suo vero punto di forza (ma sta a vedere fino a che punto la candela vale il prezzo).

siamo fuori dal mondo....:doh:
con l'itanium posso caricare un algoritmo in cache comunicare alle altre unità operative la porzione di dati che sto elaborando e prenotare la memoria porzione di memoria in cui scrivero i risultati, il tutto in un sistema con centinaia di nodi in cui ogni nodo puo' avere anche decine di unità operative.
questo con l'architettura x86 non è possibile farlo.
punto e basta.
l'intel non ha bisogno di salvare la faccia. visto che sono molti anni di sviluppo sul progetto itanium, parliamo di quasi 10 anni, nessun progetto viene tenuto in vita cosi' a lungo....solo per salvare la faccia....
...tenete conto che la sun ha abbandonato da anni i microprocessori sparc...e non se ne' accorto nessuno....ne' a perso la faccia....
....la apple ha lasciato i processori IBM power....e cosi' via.....

No homero, eh, non te la prendere, ma tu gli x86 attuali non li conoscevi quando ti intestardivi a dire che i 64 bit introdotti da amd sono falsi e realizzati col microcodice, e continui a non conoscerli, visto che le cose che dici, peraltro piuttosto vaghe, o le puoi fare tranquillamente con un x86, o non hai bisogno di farle, perchè ci pensa la cpu a farle per te e meglio di te, oppure sono problematiche che risolvi efficientemente a livello software, senza aver bisogno di uno specifico supporto da parte della cpu...

Vuoi fare tu, a manina, il prefetch della cache? Ti svelo un segreto: tra le varie istruzioni SSE ce n'è qualcuna che non riguarda il calcolo vettoriale, ma ti consente di fare esattamente questo. Ma ti serve davvero farlo? Con un x86 la risposta è no, perchè è in grado di gestire la cache in maniera estremamente efficiente, nella stragrande maggioranza dei casi meglio di come faresti tu, quindi se proprio vuoi ottimizzare la gestione della cache ti "basta" allineare certe strutture dati critiche alla dimensione di una linea di cache, e così sei a posto per qualsiasi cpu x86, perchè ci pensa da sola a scalare la quantità di dati/istruzioni da caricare a seconda della quantità di cache che si ritrova, tu non devi fare più niente, perchè sai già che il processore si troverà a disposizione i dati che gli servono, quando gli servono. Non dire che con Itanium "puoi" farlo, ma che "devi" farlo, perchè il processore ti lascia carta bianca su molte cose, ma questo può produrre una situazione che ha molti nomi, ma un solo significato: maggior difficoltà di programmazione, più tempo, più bug, più soldi da spendere, ecc. ...

Poi, che significa che puoi far sapere agli altri processori quale parte di dati stai elaborando e "prenotare" la porzione di dati su cui scrivere i risultati? Che puoi sincronizzare dei thread o un qualsiasi altro modello di coordinazione software? E ti serve Itanium?

Vuoi forse dire che con itanium puoi creare un cluster con centinaia o migliaia di processori e con gli x86 invece no? Guarda che Linux, o Windows, o un qualsiasi Unix custom se la cavano egregiamente anche con i cluster di x86, non per niente tutte le prime posizioni della top 500 sono appannaggio quasi esclusivo di sistemi basati su Power, Opteron e Xeon...

Oppure ti riferisci alla presenza di "strumenti" predisposti al controllo manuale della coerenza dei dati tra le varie cache e la memoria centrale? Un x86 lo fa in automatico, gli Opteron usano linee di comunicazione dedicate (hyper transport) per far parlare i processori tra di loro, e le stesse linee si possono usare anche per comunicazioni esterne tra i nodi di un cluster (è una questione di implementazione e di supporto da parte di MB, chipset ecc.). Doverlo fare a mano, anche solo in casi limitati, con Itanium ti sembra una soluzione migliore? Evidentemente qualcuno alla Intel la pensa diversamente, visto che hanno introdotto un meccanismo hardware a tal fine, come leggiamo in questa stessa news (in realtà, so bene che Itanium implementa un'architettura numa con coerenza della cache in hardware, però è un processore che tende comunque a lasciare grande libertà ai programmatori, ed evidentemente tutta questa libertà deve aver causato più problemi che altro, visto che vogliono limitarla, o quanto meno rafforzare i meccanismi hardware...).

Del resto, Intel ti smentisce su tutta la linea, dal momento che ha deciso di unificare il socket usato da itanium e xeon, e questo più di 3 anni fa. A me sembra palese che sia una scelta dettata dagli scarsi risultati di itanium, da possibili lamentele di clienti e dall'esigenza di essere pronti a "scaricare" la ia64 qualora diventasse un completo fallimento: non si tratta di perdere o meno la faccia, ma di tenersi stretti dei clienti schizzinosi, quelli del settore server, poco propensi al cambiamento come al ritorno sui propri passi una volta fatto il "salto" (verso altri lidi, diversi da intel), almeno nel breve periodo. Trovo, invece, impensabile che chi sceglie xeon possa voler passare ad itanium, dato che itanium è rivolto al mercato high-end, dove va a competere con altre cpu risc high end (i power), ma anche con supercomputer basati su x86, e chi fa una scelta quantomeno ha ponderato a fondo e valutato anche con prove "su strada", mentre i server xeon dovrebbero essere rivolti ad altri ambiti: solo un pazzo passerebbe a itanium per gestire un database, spendendo molto di più per ottenere prestazioni inferiori, e dovendo buttare tutto il software, mentre è più credibile che chi avesse scelto itanium, trovandosi poi di fronte a una generazione di cpu x86-based con prestazioni fpu superiori, e non a caso i progetti terascale di intel si basano su core x86 semplificati, per non parlare dei progetti fusion e torrenza di amd, volti a coniugare la flessibilità di un x86 alla potenza fpu di coprocessori dedicati, possa decidere di fare il salto, dato che comunque la riscrittura (in parte, e in parte ricompilazione) del software verrebbe compensata dalla maggiore facilità di ottimizzare lo stesso per x86.

Ma tu parlavi di nodi: non è che invece ti riferivi alla possibilità di creare, grazie ad apposite strutture fisiche (= hardware) delle sovrastrutture logiche (nodi), che stabiliscono delle gerarchie, e attribuiscono a un processore il controllo/l'accesso prioritario su porzioni di memoria di dimensione variabile, che fungono da memoria locale per i processori facenti parte del nodo? Cioè ti piace Itanium perchè puoi fare cose simili a quelle che si fanno con gli Opteron grazie all'architettura NUMA supportata nativamente? Ma allora ti piacciono gli x86!!!!! :p

(piccola nota: non hai del tutto torto, perchè non tutti gli x86 supportano numa: con gli xeon non la puoi sfruttare, almeno non direttamente via hardware - e implementare numa via software non conviene - mentre gli opteron costituiscono di per sè un nodo numa - considerando che le prestazioni di questo tipo di architettura sono inversamente proporzionali al numero di processori di un nodo, fai un po' i tuoi calcoli... considerando anche che Intel adotterà un'architettura simile con il progetto Nehalem, che introduce un mch integrato e il bus common system interface, equivalente di hyper transport, che sarà adottato anche da Itanium )

Scusa, cosa dicevi di Sun? Che vende server basati su Opteron, Xeon, ma continua a vendere server basati su SPARC64 VI (2 core, 2 thread per core), UltraSPARC IV+ (dual core), UltraSPARC T1 (cpu Niagara: 8 core, 4 thread per core, controller della memoria integrato), UltraSPARC T2 (Niagara2, 8 core, 8 thread per core, controller integrati, per la memoria e l'I/O - è un system-on-a-chip, con dual 10Gb ethernet e PCI Express), tutti con la stessa ISA delle generazioni precedenti di cpu SPARC (SPARC V9) e sta lavorando sul progetto Niagara3? Intendevi questo, giusto?

E poi, Apple mi vai a prendere... maddai, Apple... con il suo zoccolo duro di fedelissimi, che se trovano una mela bacata dal fruttivendolo se la portano a casa e la incornicano... :Prrr:

1. Apple vende design
2. Itanium implementa un'architettura che non è NÉ CISC NÉ RISC, ma la EPIC (http://it.wikipedia.org/wiki/Explicitly_Parallel_Instruction_Computing) che ha preso "vagamente" spunto dalla VLIW usata nei DSP (dove fare conti velocemente è la cosa che sanno fare meglio)
Per funzionare al meglio richiede che ci sia la "collaborazione" del software. Preprogrammare la logica di predizione dei salti è una cosa che nessun'altro processore può fare. Fatto sta che alcune cose sono... come dire... curiose. (con un bit seleziono se un'area di memoria viene gestita in little piuttosto che in big-endian o.O grappini alla mattina? )

1. Apple vende hardware "condito" da design, anche innovativo ed esteticamente gradevole (ma secondo me sopravvalutato, però è una questione di gusti, quindi non sto a sindacare; personalmente appartengo alla "vecchia guardia" di chi considera il computer una macchina da lavoro e da più importanza alla sostanza che alla forma - preferisco spendere la differenza in hardware più performante, piuttosto che in design, ma de gustibus), e Steve Jobs è un genio del marketing (ed è innegabile che abbia saputo creare uno zoccolo duro di clienti fedelissimi, che prendono tutto ciò che dice come oro colato, quando spalava m*rd@ sugli x86, tutti a spalare con lui, quando ha cambiato solfa elogiandone le meraviglie, tutti a rinnegare la m*rd@ precedente e a cercare mille motivi, anche validi, per giustificare il cambio di rotta, con pochi critici a chiedersi se magari la verità non stesse nel mezzo anche prima).

2. Che Epic non abbia assolutamente niente a che fare con i CISC, non ci piove, ma NON "ha preso vagamente spunto da VLIW", Epic E' una variante di VLIW: quello stesso articolo di Wikipedia (che per certi versi non mi piace granchè, ma non voglio addentrarmici) dice che "L'architettura EPIC è un derivato dell'architettura VLIW e difatti lo sviluppo di questa architettura è inscindibilmente legato con lo sviluppo dell'architettura VLIW"; più sotto aggiunge "EPIC è un architettura pienamente VLIW senza cicli di ritardo"; se poi vai all'articolo sui VLIW, troverai una bella foto di Itanium con tanto di didascalia che la definisce come cpu vliw; ma praticamente tutte le riviste di settore, cartacee e digitali, hanno sempre enfatizzato lo strettissimo legame tra EPIC e VLIW.

Io preferisco parlare di variante piuttosto che di derivazione, per fare un discorso più generale: Epic deriva dal PA-WW, che a sua volta è una implementazione del VLIW fatta da HP, ma non l'unica (ad esempio, i Crusoe di Transmeta erano dei VLIW); tutt'al più potremmo parlare di evoluzione, ma non certo di vago spunto. E VLIW, a sua volta, E' una variante delle architetture RISC (in particolare, PA-WW di HP deriva da PA-RISC), che riprende il modello più "puro", originario, di architettura risc (i ppc che usava apple, ad esempio, a partire dai g3 di risc avevano quasi solo il nome - c'è un bellissimo articolo su arstechnica che traccia a grandi linee e con notevoli spunti critici l'evoluzione dei due concetti, cisc e risc, e arriva a parlare di "fisc": fast instruction set computer, perchè l'orientamento vincente si è rivelato quello che toglie complessità "inutile" e aggiunge complessità "utile"; a me piace parlare di BCA, balanced complexity architecture, per gli stessi motivi, distinguendo al più un legame storico-pratico in base al set di istruzioni "esterno", parlando di bca-cisc e bca-risc).

E per funzionare al meglio non ha semplicemente bisogno della collaborazione del software (quella c'è anche con un cisc: il compilatore ordinerà come meglio può le istruzioni indipendenti, e trasforma, nei limiti del possibile, un ciclo in un blocco sequenziale, al resto pensa la logica out-of-order), ma ha l'assoluta necessità che il software sia parallelizzato con la massima precisione. Un'architettura risc "pura" tende ad eliminare gran parte della complessità architetturale, a scapito però della complessità del software e del compilatore, che aumenta terribilmente: sostanzialmente, quello che non fa un risc rispetto a un cisc, lo deve fare il software.

Epic mette a disposizione delle soluzioni interessanti per semplificare il compito del compilatore, come i predicati, la rotazione dei registri, l'ampio numero dei registri, la possibilità di seguire due strade di un branch per validare il risultato e scartare il ramo sbagliato (calcoli alla fine la condizione di salto, e invece di fare il salto hai pronti due risultati diversi tra cui scegliere). Però, queste soluzioni hanno un risvolto della medaglia: avere tanti registri implica avere maggiori latenze di accesso ai registri stessi (una ricerca in questo stesso forum dovrebbe portarti a dei post interessanti al riguardo, scritti da gente che scrive compilatori), e la rotazione dei registri dedicati alle subroutine introduce anch'essa delle notevoli latenze (in Itanium 1 erano "drammatiche" ). Inoltre, nessuna di queste soluzioni può risolvere il problema alla radice: il compilatore dovrà comunque effettuare un'ottimizzazione statica, basata su ciò che conosce a priori, e quindi non è escluso che le situazioni contingenti che possono verificarsi durante l'elaborazione ne pregiudichino le performance.

Ti faccio un piccolo esempio: i registri a rotazione sono ben 96, un numero elevato, ma non infinito, non si può presumere che siano sempre sufficienti, quindi il processore stesso, automaticamente, provvede a spostare nello stack il contenuto dei registri più "lontani" dall'elaborazione; di conseguenza, quando una certa subroutine (o più subroutine in sequenza) ritornano al chiamante, può succedere che i dati non siano più disponibili e vadano ripresi dalla memoria centrale, che è più lenta: in questo caso possono succedere due cose, o il processore si ferma a rigirarsi i pollici, nell'attesa, oppure cerca di andare avanti e fare qualcos'altro, ma non è detto che la speculazione predicativa sia sempre sufficiente a trovare qualcosa da fare, mentre la logica out-of-order, che è in grado di decidere al volo cosa fare, basandosi sulla conoscenza di ciò che sta effettivamente accadendo dentro il processore, tenderebbe a produrre risultati migliori (in generale, l'esecuzione fuori ordine si rivela utile ogni qual volta si deve accedere frequentemente a dati sparsi in memoria). E' per questo che i processori cisc tendono ad essere vincenti nel general purpose, oltre che più facili da programmare.

Per la storia dello switch big/little endian, potrebbe essere una questione di compatibilità, ad esempio con coprocessori/periferiche particolari, oppure per consentire un più rapido adattamento di librerie preesistenti, con ottimizzazioni specifiche per l'uno o l'altro tipo di macchina ("storicamente", i RISC hanno avuto un notevole impiego per l'high performance computing, impiegati per calcoli pesanti, di tipo vettoriale o comunque basati su algoritmi ben noti ed estremamente ottimizzati nel tempo: con un'ottimizzazione perfetta lato software, i Risc tendono, sempre facendone un discorso storico, a rivelarsi vincenti, mentre i cisc danno migliori risultati da subito, consentendo una più facile ottimizzazione "di base" e prestazioni più che decenti con qualsiasi algoritmo). Quindi, la possibilità di far funzionare Itanium come macchina big-endian o little-endian può avere un senso.

il vagamente era virgolettato perchè era ironico.

Ok, allora ho frainteso io :p
però, se è vliw allora concettualmente è anche risc :p
Bye :)