Gli UltraSparc III: guerra ad Itanium

Sun ha finalmente annunciato la nuova versione dei suoi chip UltraSparc III, missili lanciati contro le ambizioni di Intel nel mercato a 64 bit

Palo Alto (USA) - Sun ha annunciato la nuova generazione di processori UltraSparc III che, secondo le sue speranze, dovrebbero competere con le CPU Itanium di Intel.

I nuovi UltraSparc, prodotti nelle fabbriche di Texas Instruments con processo a 0,15 micron, girano alla frequenza di 900 MHz e utilizzano la tecnologia al rame che Sun ha licenziato da IBM.

Le nuove e più potenti CPU di Sun verranno rilasciate sul mercato a ottobre ed equipaggeranno dapprima le workstation e poi i server enterprise.
A differenza di Intel, Sun produce da anni CPU con architettura a 64 bit, un settore dove detiene la leadership e dove Intel spera di entrare prepotentemente con le future generazioni di Itanium.

Sun ha più volte deriso l'architettura very long instruction word (VLIW) di Itanium definendola "bizzarra" e sostenendo invece che i suoi chip UltraSparc hanno un roseo futuro: fra i vantaggi citati da Sun c'è l'architettura RISC super collaudata, le elevate prestazioni e la possibilità, da parte dei clienti, di scalare in alto senza necessariamente dover riscrivere tutto il proprio software.

Intel sostiene per contro che l'architettura RISC, nata nei primi anni '80, stia ormai incontrando limiti insuperabili e soprattutto non consente la produzione di chip a basso costo. Con il progetto Itanium, Intel ha invece puntato molto sull'economicità dei chip e sulla possibilità di rendere l'architettura a 64 bit sempre più di massa.

Sun attende di impiegare i nuovi UltraSparc III nella sua nuova generazione di server enterprise denominata StarCat. Entro l'autunno Sun conta poi di rilasciare la prima beta di Solaris 9, un grande aggiornamento al proprio sistema operativo Unix, ottimizzato per sfruttare a fondo la nuova architettura dei processori UltraSparc III.
TAG: hw
24 Commenti alla Notizia Gli UltraSparc III: guerra ad Itanium
Ordina
  • CISC: Istruzioni molto complesse e con durata molto variabile di cicli macchina, un mucchio di feature e di gadget (i windows 3.11 dei processori)
    RISC: Istruzioni ridotte ma molto potenti con una durata minima in cicli macchina (i linux dei processori) I processori risc in genere non hanno tempi morti di elaborazione interna.
    Provate ad installare linux PPC su un imac!!! anzichè su un solito intel

    Il maggiore costo dei RISC è dovuto al fatto che questi processori (alpha, G4, Ultra Sparc, ecc..) sono generalmente già a 64 bit e vista la minore diffusione ne ammortizzano ancora i costi.

    L'ibrido migliore è il processore Athlon di AMD un RISC che interpreta macrocodice CISC!!! Velocissimo ed anche economico!!!
    Vedremo cosa uscirà con la concorrenza Intel e soprattutto con il 64 bit di AMD
    non+autenticato


  • - Scritto da: Ginko

    > RISC: Istruzioni ridotte ma molto potenti

    ma che potenti!!! le istruzioni risc sono molto semplici!!! il vantaggio è che, essendo semplici, sono anche molto veloci ad essere eseguite ma non c'entra niente la potenza

    StefanoR

    non+autenticato
  • So che le istruzioni sono più limitate ma che vuol dire con il costo più alto ?

    Qualcuno meno ignorante di me mi pò illuminare ???
    non+autenticato
  • Le istruzioni sono piu' limitate non mi pare corretto.
    Le istruzioni sono meno "potenti", nel senso che se vuoi sommare 2 numeri che stanno in memoria su un RISC ti devi portare i numeri in 2 registri del processore, sommarli e mettere il risultato in un terzo registro, mettere il risultato in memoria.
    Si CISC puoi fare operazioni con operandi che sono in memoria direttamente.

    Di conseguenza un istruzione CISC richiede piu' tempo per essere eseguita di un istruzione piu semplice tipo RISC. Spesso la somma di piu' istruzioni semplici da risultati migliori di una complessa per vari motivi.
    I CISC tenderebbero ad avere clock piu' bassi (i pentium hanno una ventine di pipeline per raggiungere gli Hz che hannno)

    Comunque oggi non e' piu' cosi' netta la distinzione, entrmbe le filosofie si sono rese conto che c'era del buono anche nel modo opposto di pensare.

    Del perche' i RISC siano piu' costosi non ti saprei dire. Forse perche' meno diffusi??
    Bho??

    Ciao
    non+autenticato


  • -> Le istruzioni sono meno "potenti", nel senso
    > che se vuoi sommare 2 numeri che stanno in
    > memoria su un RISC ti devi portare i numeri
    > in 2 registri del processore, sommarli e
    > mettere il risultato in un terzo registro,
    > mettere il risultato in memoria.
    > Si CISC puoi fare operazioni con operandi
    > che sono in memoria direttamente.
    >
    > Di conseguenza un istruzione CISC richiede
    > piu' tempo per essere eseguita di un
    > istruzione piu semplice tipo RISC.

    Scusa non ti seguo... per un RISC hai descritto piu' operazioni rispetto ad un CISC... quindi dovrebbe metterci piu' tempo.
    non+autenticato
  • - Scritto da: §o§e
    > -> Le istruzioni sono meno "potenti", nel
    > senso
    > > che se vuoi sommare 2 numeri che stanno in
    > > memoria su un RISC ti devi portare i
    > numeri
    > > in 2 registri del processore, sommarli e
    > > mettere il risultato in un terzo registro,
    > > mettere il risultato in memoria.
    > > Si CISC puoi fare operazioni con operandi
    > > che sono in memoria direttamente.
    > >
    > > Di conseguenza un istruzione CISC richiede
    > > piu' tempo per essere eseguita di un
    > > istruzione piu semplice tipo RISC.
    >
    > Scusa non ti seguo... per un RISC hai
    > descritto piu' operazioni rispetto ad un
    > CISC... quindi dovrebbe metterci piu' tempo.

    No, perché le operazioni RISC si chiamano anche
    operazioni "atomiche", che non possono essere
    suddivise in operazioni più elementari.
    Possono essere eseguite quindi in un tempo
    inferiore a quelle CISC. A parte che oggi, dai
    Pentium in su quasi tutte le operazioni prendono
    1 ciclo macchina, e di meno non possono... ecco
    perché da entrambe le parti si cerca di eseguire
    più di una istruzione per volta, con
    l'architettura superscalare ( = a più pipelines).
    Io sono a favore dell'architettura CISC: è vero,
    la RISC sta raggiungendo dei limiti invalicabili,
    e per quanto mi riguarda l'avevo previsto già
    da diversi anni, che questo limite l'avrebbe
    raggiunto. Ciononostante penso che Intel abbia
    fatto una colossale stupidaggine nell'implementare
    il sistema di protezione degli indirizzi, specie
    per quello che riguarda operazioni di LETTURA
    dalla memoria, che in tutti i sensi sono innocue,
    e che causano la maggior parte dei GPF di Windows,
    ovvero quando vi dice:

    "l'applicazione ha eseguito un'operazione
    non valida e sarà terminata..." ecc...

    Bè, sappiate che la principale colpa è di Intel.
    non+autenticato
  • > il sistema di protezione degli indirizzi, specie
    > per quello che riguarda operazioni di LETTURA
    > dalla memoria, che in tutti i sensi sono
    > innocue, e che causano la maggior parte dei GPF > di Windows, ovvero quando vi dice:

    > "l'applicazione ha eseguito un'operazione
    > non valida e sarà terminata..." ecc...

    Qualcuno mi può spiegare meglio questa cosa ?

    Grazie
    non+autenticato
  • Premesso che non conosco molto bene gli errori di windows penso che sia un errore simile al segmentation foult.

    Ad ogni processo viene allocato un pezzetto di memoria entro il quale lui deve lavorare.
    Se cerca di accedere ad un ID al difuri di quello a lui assegnato viene generato un errore (trap al S.O.) che avviera' le sue procedure di gestione per quel determinato errore.

    Spegato alla vole' e in modo superficiale, ovviamente.

    Ciao
    non+autenticato
  • - Scritto da: Krecker
    > Premesso che non conosco molto bene gli
    > errori di windows penso che sia un errore
    > simile al segmentation foult.

    Esatto.
    Mi sono anche un po' stupito che le
    applicazioni Linux non girassero in FLAT,
    che insomma anche Linux abbia abbracciato
    questo pessimo sistema di protezione.
    Potevano optare per un modello semiflat.
    Non sto a spiegare cosa sia, ma sarebbe stato
    meglio...

    > Ad ogni processo viene allocato un pezzetto
    > di memoria entro il quale lui deve lavorare.

    Giusto!

    > Se cerca di accedere ad un ID al difuri di
    > quello a lui assegnato viene generato un
    > errore

    ID = indirizzo relativo di memoria;
    relativo cioè all'inizio del segmento,
    e al di fuori dell'estensione attuale
    del segmento.

    > (trap al S.O.)

    Proprio! Precisamente un GPF,
    General Protection Fault, che nel 99% dei casi
    è dovuto alla protezione degli indirizzi, cioè
    allo sconfinamento del programma al di fuori
    dell'area assegnatagli. Il fatto è che molti
    programmi ottengono indirizzi per arrotondamento
    di vari calcoli, e quindi alcune "sbavature" non
    sempre prevedibili (difficilmente prevedibili,
    in effetti) sono difficilissime da evitare.
    Intel, insomma, è stata "troppo pignola", poteva
    almeno lasciare un po' di tolleranza, allineando
    i confini dei segmenti su blocchi che so, di 64K
    o giù di lì... oppure implementare una struttura
    semiflat, che ancora non sto a spiegare...

    > che avviera' le sue
    > procedure di gestione per quel determinato
    > errore.

    > Spegato alla vole' e in modo superficiale,
    > ovviamente.

    Ma spiegato bene.

    > Ciao
    non+autenticato
  • Salve,
    ho capito il nocciolo del problema ma mi resta un dubbio: perché Linux non ha tutti i problemi di cui soffre win? Eppure girano sugli stessi processori, percui un errore dell'architettura hardware si rifletterebbe anche in Linux.
    Forse è dovuto al fatto che la memoria in win non è protetta mentre Linux dispone di un'ottima protezione che gli evita i segfault? Anche BeOS dispone di buone protezioni e non ha i prob di win, perciò ritengo sia questo il punto.
    Qualcuno sa dirmi se ho indovinato o dirmi qual'è la risposta esatta?
    Grazie.
    non+autenticato
  • - Scritto da: palomar29
    > Salve,
    > ho capito il nocciolo del problema ma mi
    > resta un dubbio: perché Linux non ha tutti i
    > problemi di cui soffre win? Eppure girano
    > sugli stessi processori, percui un errore
    > dell'architettura hardware si rifletterebbe
    > anche in Linux.
    > Forse è dovuto al fatto che la memoria in
    > win non è protetta mentre Linux dispone di
    > un'ottima protezione che gli evita i
    > segfault? Anche BeOS dispone di buone
    > protezioni e non ha i prob di win, perciò
    > ritengo sia questo il punto.
    > Qualcuno sa dirmi se ho indovinato o dirmi
    > qual'è la risposta esatta?
    > Grazie.

    Perche' hanno buoni commerciali, ma pessimi programmatori;) se guardi i sorgenti di Dos 6, fai un trova di alcune parole:

    shit, bug, around, ceck, mather, God.
    Ne troverai migliaia, e seguendoli ti accordi di alcuni commenti lasciati dai programmatori, che tradotti suonano piu'ì o meno cosi':

    - Questa parte funziona, e' meglio che non la tocchiamo piu' seno non va.
    - Controllo del vettore in memoria di 512k, sarebbe meglio controllare anche il resto.
    - Questa parte non funziona.
    - Questo sarebbe da rifare.

    In generale i controlli sulla memoria e sui processi sono molto piu' raffazzonati e meno precisi; infatti capita che un vettore riesca a sporcare aree di memoria non sue, poi il programma magare si pianta, ma le aree di memoria sporche (fuori dal programma) restano e fanno danno non appena qualcosa vi accede.

    Se vuoi piu' dettagli posto qualche link sull'analisi dell'uso della memoria ma sono un po' spissi.
    non+autenticato

  • Potresti postare i link che dicevi?

    Se vuoi puoi farlo alla mia casella personaleOcchiolino

    Grazie

    Il Conte
    non+autenticato
  • - Scritto da: Count Zero

    > Potresti postare i link che dicevi?

    > Se vuoi puoi farlo alla mia casella
    > personaleOcchiolino

    Fammi sapere se e' arrivata.
    non+autenticato