Link alla notizia: http://news.hwupgrade.it/11507.html

Il notevole intresse da parte degli sviluppatori e dei clienti che stanno raccogliendo i processori AMD64 potrebbe spingere Intel a integrare estensioni a 64bit nelle proprie cpu

Click sul link per visualizzare la notizia.

Ma qui c'è un monopolio AMD! Che scandalo... ;)
Credo che Intel abbia peccato di supponenza sviluppando un processore in cui il mercato non crede, pensando dall'alto della sua fetta di mercato che la clientela l'avrebbe seguita compatta. Disgraziatamente per lei, Amd è un'alternativa che tutti conoscono e ci si mette molto poco a cambiare brand e rimanere sulla stessa piattaforma. E ciò che vale per i clienti, vale anche per i fornitori (Hardware&Software).

Per un semplicissimo motivo: i driver. Già ora XP per AMD64 tarda ad uscire sopratutto per questo motivo, figuriamoci se dovesse arrivare una terza versione di 64 bit: Sarebbe la rivolta degli sviluppatori. Inoltre nella documentazione attuale per Longhorn le uniche architetture previste sono 32bit, Itanium, e AMD64. Quindi delle due una: O Intel proporrà Itanium (e relative istruzioni) come Mainstream, o si dovrà arrendere all'X86-64. Ovviamente non c'è nemmeno bisogno di dire gli OEM quale soluzioni spingeranno....

Il Nero burning è ottimizzato per AMD leggtivi questo ppreso da 3ditalia:
ero Recode 2: compressione e qualità in MPEG4 per i vostri DVD
News di leo - ore 6:04
CDFreaks.com ha condotto un test per saggiare le reali capacità di Nero Recode 2, l'utility per la compressione dei DVD che AHead ha rilasciato parallelamente all'ultima release 6.3.0.0 di Nero. Nero Recode 2 utilizza un nuovo codec denominato Nero Digital, compatibile con il formato MPEG4:
copia 1:1 di DVD (non protetti), compreso menu originale
creazione di un DVD da uno o più film DVD
conversione dei film in DVD nel formato Nero Digital
compressione dei file in Nero Digital in formato DVD, CD o qualsiasi dimensione scelta dall'utente
supporto per audio 5.1
modalità Vedi-mentre-registri
tecnologia Burn-at-once
supporto per processori AMD64
gestione dell'audio multilingua e dei sottotitoli
Alcune caratteristiche sono molto interessanti, prima fra tutte la possibilità di comprimere un film di un qualsiasi DVD da 9 GB in un DVD da 4,7 GB oppure, addirittura, su un CD, rimuovendo le lingue non desiderate e tutte le altre informazioni non strettamente necessarie (trailer, ecc...). Inoltre, la codifica in formato MPEG4 permette di ottenere qualità audio/video veramente notevoli: dai test condotti da CDFreaks.com il codec di AHead offre una qualità video sui livelli di XviD, un nuovo codec di compressione, e superiore a quella di DivX, uno dei codec più diffusi.
Nero Digital è contenuto nell'Update Package 2, comprendente NeroVision Express 2, Nero ShowTime e Nero Recode 2; l'Update Package 2 può essere installato solo su un PC che abbia già installato l'Update Package 1, che comprende la suite principale di Nero 6.3.0.0 e dei programmi allegati.

Sembra che YamHill (i 64 bit proprietari di intel) sia già incluso in Prescott...

Comunque lo sviluppo di una estensione x86-64 non significa che sia compatibile con AMD64...purtroppo...

che confusione!

amd64 non è il nome della "estensione"!!! amd64 è il nome della tecnologia utilizzata da amd per avere i 32/64 bit in unico processore!

Le estensioni sono solo x86-64 descritte in x86-64.org!
Intel sarà OBBLIGATA a usarle perchè oramai sono uno standard! E questo standard non stato creato da AMD!!! Ma bensi è l'evoluzione diretta a 64bit dell'architettura x86 intel-compatibile!

ma intel non puo fare come ha fatto amd quando ha incluso le istruzioni compatibili sse e sse2 nei amd 64
e includere le istruzioni x86 64 di amd nei suoi processori

Originariamente inviato da bs82
E questo standard non stato creato da AMD!!! Ma bensi è l'evoluzione diretta a 64bit dell'architettura x86 intel-compatibile!
Non è assolutamente vero...lo standard è stato definito da AMD... Se una ditta Pinco Pallino avesse definito uno standard x86 a 64 bit sicuramente sarebbe stato diverso dall'x86-64 di AMD... Bastano pochi dettagli per renderli diversi...ad esempio basterebbe chiamare i nuovi registri in modo diverso...o semplicemente cambiare le regole di programmazione per il passaggio dei parametri a procedura e non sarebbe più compatibile...

Cionci.....io ho studiato x86 a 16 e il suo passaggio avvenuto oramai molti anni a 32 bit... dove il registro ax diventava eax e così via! I 64 bit di Itanium non seguono questo processo di evoluzione ed infatti non sono compatibili x86! AMD64, che è stato sviluppatto si da amd ma in collaborazione con suse e moltre altre aziende (specilmete linuxiane), è l'unico metodo di far evolvere a 64bit l'x86-32 seguendo gli stessi passi del'evoluzone da 16 a 32bit...

http://old.x86-64.org/documentation_folder/assembly

guardando semplicemente l'assembler si può vedere come il passaggio 16->32->64 bit nell'x86 sia "lineare"...e questa è l'unica strada per la compatibilità...che intel dovrà seguire....

Originariamente inviato da bs82
http://old.x86-64.org/documentation_folder/assembly

guardando semplicemente l'assembler si può vedere come il passaggio 16->32->64 bit nell'x86 sia "lineare"...e questa è l'unica strada per la compatibilità...che intel dovrà seguire....
Quoto...

Poi non capisco tutta questa esaltazione per AMD perchè è 64bit.
A quanto pare pure Intel lo può diventare e che usi le istruzioni "create" da Intel o no, non capisco cosa cambi...
Se proprio vogliamo fare un raffronto allora chiediamoci il perchè AMD ora utilizza le SSE di Intel e perchè le sue istruzioni proprietarie sono invece state quasi fallimentari...

Secondo me fino a quando non si passerà ai 64bit puri (e non emulati) come standard tutte queste soluzioni sono solo dispendiose e quasi inutili.
Quando con win95 si è passati dai 16 ai 32 bit c'è stato un salto tangibile,ma perchè tutta la macchina e tutti i software erano ottimizzati e "nativi" per così dire. Avere ora una soluzione "ibrida" che costa dai 700 ai 900 e passa € per il solo processore,mi sembra inutile.E' indubbio che Amd ha avuto il coraggio di aprire la strada a questa innovazione con un piede nel presente e uno nel futuro,è per questo che fa bene la concorrenza! Però io aspetterei fin quando non ci sarà il passaggio effettivo.

La situazione è totalmente incasinata....è impossibile dire chi alla fine avrà ragione....cmq sarà il mercato di quest'anno a dirlo....e spesso a vincere non è certo la tecnologia migliore.....

Concordo con MikeLezZ in questo particolare:
Sembra che Amd abbia scoperto la fuosione a freddo introducendo il K8 e che sia chissà quale meraviglia.
Mesi prima è uscito il Mac G5 : 64 bit,serial ata,1 ghz fsb, Pci-x e Pci express... anni luce avanti e si mangia qualsiasi pc.
A me ha fatto pensare,leggendo i test prestazionali e tutto il resto, a quanto sia indietro il mondo pc, e a quanto non sia alternativo un soggetto che scelga Amd invece di Intel per smuovere la concorrenza.
Se si spingesse di più per diffondere il Mac sarebbe un bene per tutti: avremmo computer che non si "invecchiano" dopo una settimana perchè è cambiata piattaforma,processore,slot e perfino casa si mormora,e il buon vecchio Bill sarebbe costretto a sfornare prodotti di qualità vera.
Pensateci su...
Ah! BUON ANNO A TUTTI!!! :)

...perchè è cambiata piattaforma,processore,slot e perfino casa si mormora,
volevo dire CASE...adesso ci manca solo il pc nomade..
:)

Originariamente inviato da marcus21
Mesi prima è uscito il Mac G5 : 64 bit,serial ata,1 ghz fsb, Pci-x e Pci express... anni luce avanti e si mangia qualsiasi pc.



Su Chip o PC Magazine (non riscordo) di Dicembre c'era un bellissimo test comparativo tra AMD 64 FX e Mac G5 entrambi chiaramente in versione 64 Bit ........oltre a Intel Extreme Edition 3,2 GHz.
Il Mac G5 era nettamente inferiore all'AMD in quasi tutti i test (escluso filtri in Photoshop) e senza dimenticare che costa quasi il doppio rispetto alla versione PC!!! :eek:
Detto questo ............. nulla da dire sulla qualità costruttiva del Mac che è anni luce avanti a quella del mondo PC.


Gio&Gio

Originariamente inviato da marcus21
Secondo me fino a quando non si passerà ai 64bit puri (e non emulati)
Cosa vuol dire?
Chi emula i 64 bit adesso?

Giusto alcune precisazioni, perchè pare che parlare per sentito dire qui stia diventando una moda.

Forse il Mac è anni avanti alla qualità costruttiva di un assemblato, non certo di una macchina workstation di marca.
Pci-express NON esiste ancora, e men che meno su Mac.
PCI-X è da un bel pò presente nelle piattaforme x86 sopratutto destinate ad impiego server.
S-ATA non è certo una novità introdotta da Apple, così come l'uso della DDR-SDRAM.
Infine: Opteron è uscito sul mercato alcuni mesi PRIMA di G5.

Ciao

Federico

Originariamente inviato da MiKeLezZ
A quanto pare pure Intel lo può diventare e che usi le istruzioni "create" da Intel o no, non capisco cosa cambi...
Cambia...se usasse le proprie estensioni in quel caso significherebbe un grande fallimento per AMD...

Originariamente inviato da marcus21
Concordo con MikeLezZ in questo particolare:
Sembra che Amd abbia scoperto la fuosione a freddo introducendo il K8 e che sia chissà quale meraviglia.
Mesi prima è uscito il Mac G5
L'Opteron se non sbaglio è uscito prima del G5 !!!

AMD utilizza le SSE perchè Intel detiene più del 80% del emrcato delle CPU...

Originariamente inviato da bs82
è l'unico metodo di far evolvere a 64bit l'x86-32 seguendo gli stessi passi del'evoluzone da 16 a 32bit...
Non è assolutamente lineare...dai 16 ai 32 bit non sono stati aggiunti registri...sono solamente stati estesi quelli già presenti...
Nell'x86-64 di AMD, oltre all'estensione dei registri già esistenti, sono stati aggiunti 8 registri general purpose...e sarà quello uno dei principali vantaggi nell'esecuzione di un codice a 32 bit ricompilato per AMD64... I registri general purpose sono chiamati R8...R15... Se l'azienda Pinco Pallino ad esempio avesse chiamato gli 8 registri aggiuntivi della sue estensione di x86 a 64 bit R1...R8 allora non sarebbe compatibile con AMD64...
Ancora più semplice...la codifica binaria delle istruzioni... Ovviamente è cambiata anche perchè devono essere codificati anche i nomi dei registri aggiuntivi e degli operatori a 64 bit... Dici che esiste un solo modo per codificare i codici operativi ?
Poi esistono delle direttive per la programmazione in assembler...queste direttive devono essere rispettate da chi programma in assembler e da chi scrive i compilatori... Sono direttive relative, ad esempio, al passaggio dei parametri alle procedure assembler...
Se anche solamente una di questi parametri fosse diverso tra AMD e Intel allora non sarebbero compatibili !!!
Quindi insisti ancora a dire che esiste solamente un modo per estendere x86 ai 64 bit ? Volendo Intel può fare il suo set di istruzioni proprietario...
Tutto dipende da Microsoft !!!

Concordo con cionci.
Comunque i primi prescott si trovano già in listino (e credo siano anche ordinabili) in alcuni famose catene italiane.
Guardate il prezzo anche se credo sarà solo provvisorio.
http://www.computerdiscount.it/pagine/prodotti/pages.asp?pag=1&par=Z500

Ciao,
vorrei fare un commento senza scatenare flame ....
C'0e' chi dice che AMD sia stata molto coraggiosa "aprendo" la strada ai 64 bit con un'architettura ibrida 32/64, io invece penso che questa sia stata la scelta piu' conservativa e meno "audace" che potesse fare, in questa maniera continua a tenere viva la vetusta architettura x86 che e' ormai allo stremo (ricordiamoci che ha piu' di vent'anni).
Semmai si pui dire che il coraggio c'e' l'ha avuto la Intel quando ha sviluppato l'architettura Epic tagliando totalmente i ponti con il passato nonostante sia stata lei a creare l'x86.
La scelta di Intel e' stata un vero salto nel buio visto che ha creato un'architettura totalmente nuova, prendendo come basi vent'anni di sviluppi sulle architetture e cercando di mettere all'interno del chip tutto quanto.
Per chi non lo sapesse le basi di Itanium (anzi Merced) affondano le radici negli studi di HP per migliorare l'architettura pa-risc, poi in seguito sono stati aggiunti tutti gli studi di Intel ed infine sono state implementati alcuni progetti che Digital aveva per il suo mai nato alpha ev8.

Ciao
Fabio

Originariamente inviato da andamus
C'0e' chi dice che AMD sia stata molto coraggiosa "aprendo" la strada ai 64 bit con un'architettura ibrida 32/64, io invece penso che questa sia stata la scelta piu' conservativa e meno "audace" che potesse fare, in questa maniera continua a tenere viva la vetusta architettura x86 che e' ormai allo stremo (ricordiamoci che ha piu' di vent'anni).
Purtroppo era l'unica strada che poteva intraprendere una società come AMD... AMD non ha la potenza di "decidere" il mercato come ha Intel...
E comunque era l'unica strada per i 64 bit di massa in breve tempo... Senza ocntare che i 64 bit di AMD sono stati accolti benissimo soprattutto dalle aziende...aziende che non sono costrette a cambiare tutto il parco software esistente, ma possono migrare gradualmente verso software a 64 bit...

Originariamente inviato da marcus21
Secondo me fino a quando non si passerà ai 64bit puri (e non emulati) come standard tutte queste soluzioni sono solo dispendiose e quasi inutili.
Gli itneri a 64 bit erano emulati fino ad adesso... Gli AMD64 sono processori a 64 bit a tutti gli effetti...

Cmq sia stranamente xp 64bit è stato rimandato le solite porcate intel+microsoft!

... Microsoft metterebbe in piedi un windows xp 64bit edition in un batter d'occhio. Se deve farlo solo per AMD manco si sporca le mani :D A microsoft non interessa il 20% del mercato... non so se mi sono spiegato !

Marcus21

Aspettiamo i 64 "puri"
Secondo me fino a quando non si passerà ai 64bit puri (e non emulati) come standard tutte queste soluzioni sono solo dispendiose e quasi inutili.
Quando con win95 si è passati dai 16 ai 32 bit c'è stato un salto tangibile,ma perchè tutta la macchina e tutti i software erano ottimizzati e "nativi" per così dire.

Ma scherzi?
La prima soluzione interamente a 32 bit x desktop (quindi escludendo NT) è stata windows2000, cioè 5 anni dopo.

Quanto alle altre imprecisioni vedo che ti hanno già risposto.

Originariamente inviato da flisi71
Giusto alcune precisazioni, perchè pare che parlare per sentito dire qui stia diventando una moda.

Forse il Mac è anni avanti alla qualità costruttiva di un assemblato, non certo di una macchina workstation di marca.


Dunque:
Io personalmente non parlo per sentito dire ma per esperienza personale visto che ho la possibilità di testare PC e Mac praticamente tutti i giorni.
Io mi sono assemblato il mio PC per passione e non comprerei mai un Mac e pertanto non credo di essere stato di parte nell'aver scritto che la qualità costruttiva del Mac G5 è avanti anni luce rispetto ad un PC anche di marca. Non c'è storia!!! :O
Hai mai visto l'interno di un G5? Guardalo con attenzione e poi fai altrettanto con un HP, un DELL, un FujitsuSiemens .............. vedrai che alla fine mi darai ragione.
Per il resto PCI Express e tutto il resto ti do pienamente ragione. ;)


Gio&Gio

Originariamente inviato da andamus
...
io invece penso che questa sia stata la scelta piu' conservativa e meno "audace" che potesse fare, in questa maniera continua a tenere viva la vetusta architettura x86 che e' ormai allo stremo (ricordiamoci che ha piu' di vent'anni).
Semmai si pui dire che il coraggio c'e' l'ha avuto la Intel quando ha sviluppato l'architettura Epic tagliando totalmente i ponti con il passato nonostante sia stata lei a creare l'x86.

Perché "vetusta" ?
Perché "allo stremo" ?
Mi sembra che tu stia confondendo il set di istruzioni x86 con le architetture dei processori che lo usano , e parlo al plurale perché un Athlon , piuttosto che un PIV o un PIII hanno architetture profondamente diverse , il fatto che tutti e 3 abbiano lo stesso set di istruzioni non vuol dire che abbiano la stessa architettura .
Piuttosto l' architettura Epic sembra essere un bel buco nell' acqua , l' idea sembrerebbe interessante ( buttare tutta la complessità fuori dal chip e lasciarla al compilatore ) ma i risultati sono scadenti perché :
1 - La CPU non sembra meno complessa delle altre , anzi .
2 - Il compilatore Assembler é diventato un incubo .

non concordo per nulla con andamus:
scegliere i 64bit deve dare sì vantaggi nell'esecuzione di codice e nell'allocazione massima di memoria possibile... ma a costi contenuti. Un anonimo su PI (http://punto-informatico.it) ha scritto a proposito questo messaggio (http://punto-informatico.it/forum/pol.asp?mid=505843) , che quoto in pieno:


- Scritto da: avvelenato
>
> - Scritto da: Anonimo
> > beh grazie al cavolo, l'amd64 è un x86*2,
> > hanno preso l'x86 e hanno moltiplicato
> per 2
> > tutti i registri e ne hanno aggiunti 8, se
> > questa è innovazione....
> > l'itanium è un architettura totalmente
> > nuova, riprogettata da 0, e ha subito
> quasi
> > 10 anni di lavoro, non è una cosa alla amd
> > tanto per tirare avanti ancora qualche
> anno,
> > e poi passare ad un'architettura
> compatibile
> > con itanium, quando prenderà il
> sopravvento
> > (e lo farà, intel l'ha solo tirata fuori
> > troppo presto)
>
> l'itanium è una mezza cazzata, nel senso che
> l'intel ha voluto tracimare dal suo campo
> d'azione principale (il segmento desktop)
> per andare a fare moine a chi si mangia le
> ultrasparc a colazione.

Peggio! Con l'Itanium, Intel ha ripetuto per la terza
volta una enorme cazzata.

Negli anni '80 ci aveva provato con
lo iAPX432 (che doveva essere il "vero"
processore a 32bit di Intel e doveva andare
a coprire la fascia dei 32bit che poi invece
e' stata presa dai 386 e dai suoi successori).

Poi negli anni '90 ci aveva provato con l' i80860
(da non confondere con il chipset 860) che
doveva essere un "RISC per workstation".

Infine ora ci ha provato con Itanium.

Il problema e' stato che o ha fatto
cpu "nuove" con troppe feature (che si intralciavano
tra loro) oppure ha pensato di entrare in un settore
dove c'erano gia cpu "abbastanza buone"
da non giustificare un cambio brutale di architettura.

Infine con Itanium, Intel e' riuscita a fare simultaneamente
gli stessi errori che aveva fatto (separatamente)
con iAPX432 e i80860.
Buona (in teoria) la cpu, ma per tutto il resto
errori a non finire ...

Mi chiedo se la quarta volta dimostreranno
di aver imparato qualcosa.


ecco non capisco perché l'intel ogni volta debba voler innovare e rivoluzionare e rinnovare tutto il parco hw e sw esistente (vedasi rambus), senza curarsi delle tasche dei potenziali clienti.

(ps: c'è qualche problema con la formattazione dei link, bugs strane del forum, spero capiate...)

Originariamente inviato da Scezzy
... Microsoft metterebbe in piedi un windows xp 64bit edition in un batter d'occhio. Se deve farlo solo per AMD manco si sporca le mani :D A microsoft non interessa il 20% del mercato... non so se mi sono spiegato !


il 20% del mercato che andrebbe a finire nella mani di distributori linux?

il 20% del mercato non sono mica bruscolini...

il 20% del mercato può convincere amici/parenti/vicini/passanti a spendere di meno per un amd64+linux64 (gratis) piuttosto che comprare un itanium+windows(a pagamento)...

Originariamente inviato da B|4KWH|T3
La prima soluzione interamente a 32 bit x desktop (quindi escludendo NT) è stata windows2000, cioè 5 anni dopo.
A dire il vero c'era NT4 Workstation nel '96-'97.

Concordo con andamus. Intel è stata audace nel proporre un'architettura ancora acerba (epic/vliw) soprattutto dal punto di vista dei compilatori.

Di clienti che non si fanno problemi a cambiare piattaforma hw e sw ce ne sono, e sono quelli su cui si fanno i guadagni. Certo che si va a pestare i piedi ad architetture mature ed ottimizzate: al massimo è questo il problema, non la retrocompatibilità con x86-32bit.

Il set x86 è decisamente vecchiotto, mostra i suoi limiti di progetto. Ma è ancora molto valido per il settore desktop.

Amd ha deciso di seguire un approcio dal basso verso l'alto, insidiare il mercato server/wrkstation con opteron. Intel invece si è buttata nel mezzo, e spera che itanium si diffonda anche nel mercato desktop.

Originariamente inviato da Scezzy
... Microsoft metterebbe in piedi un windows xp 64bit edition in un batter d'occhio. Se deve farlo solo per AMD manco si sporca le mani :D A microsoft non interessa il 20% del mercato... non so se mi sono spiegato !
Comunque XP e 2003 Server per AMD64 sono già in beta... Il primo dovrebbe uscire fra 3 mesi...il secondo fra 6 mesi ;)

Soprattutto a cionci ma anche ad altri che si sono ben prodigati nel far seguito al mio post(flisi e Gio& Gio...)
L'unico errore,e ammetto di averlo fatto,riguarda il pci express e l'emulazione dei 64 bit per la quale intendevo(poi l'ho pure detto) la configurazione ibrida 32/64, ma per il resto vi dico:
1) Fatevi un giro nel sito apple e guardatevi la panoramica delle caratteristiche e la comparativa di un desktop che testualmete "fa mangiare la polvere alla concorrenza";
2) Opteron è per server,G5 è desktop,quindi non ho detto una cazzata (e poi allora lo dice anche apple)
3) Per il prezzo, indubbiamente non accessibile a tutti, non vedo molta differenza con una configurazione decente di Athlon 64 Fx (perchè quello "normale" che comunque costa 700 € non è assolutamente la stessa cosa...)che da solo costa 900€.
Il mac è caro anche perchè è poco diffuso rispetto ai pc e chi capisce almeno le basi di economia sa che il prezzo sale se la domanda diminuisce;
5) Per il passaggio dai 16 ai 32 bit leggete (per chi può) il numero di dicembre di Pc Profess**** all'articolo su MS Longhrn.
6) Spiacente della catena di discussione piuttosto accesa e dei vari commeti del tipo (parla per sentito dire...),dico non prendetevela e non facciamo sempre i paladini di una casa produttrice o dell'altra,questo si che è una moda!
Take it easy.... : )

Originariamente inviato da xtg
Il set x86 è decisamente vecchiotto, mostra i suoi limiti di progetto. Ma è ancora molto valido per il settore desktop.
IMHO un set di istruzioni non può essere mai vecchio !!!
E' l'architettura che semmai prima del P4 e del K6 era nettamente vecchia !!!
Il set di istruzioni è soltanto una scelta progettuale (come per altro dimostrato da Transmeta)...

Attualmente P4 e K7/K8 possono permettersi di fare le stesse cose che da molto facevano le CPU Risc... Sono pipelined, supportano sia speculative che out-of-order execution...
K7/K8 possono avere in fase di esecuzione fino a 9 istruzione contemporanee (in pratica fino a 9 unità di esecuzione possono lavorare contemporaneamente)...

E tutto questo grazie all'unità di decodifica che permette di tradurre le istruzioni x86 in istruzioni a lunghezza fissa rendendo in questo modo più agevole il lavoro per le unità interne...

Certo...l'unità di decodifica occupa fino al 30% della CPU (cache esclusa), ma di fatto è questa a rendere l'architettura indipendente dall'istructrion set al costo solo di un paio di stadi della pipeline... Costi ammortizzati proprio dal principio di funzionamento stesso della pipeline...

Insomma...oggi P4 e K7/K8 (li metto insieme perchè sono più simili di quanto pensiate) non è più niente da individuare alle CPU RISC...e il discorso sui difetti dell'x86 regge poco (praticamente l'unico è lalunghezza variabilie delle istruzioni) perchè ampliamente superato...

Originariamente inviato da marcus21
1) Fatevi un giro nel sito apple e guardatevi la panoramica delle caratteristiche e la comparativa di un desktop che testualmete "fa mangiare la polvere alla concorrenza";
Per ogni prova comparativa scritta sul sito Apple te ne porto un'altra in cui viene dimostrata la cosa contraria... Il sito Apple è troppo di parte, non puoi credere a quelle prove ;) Comunque le prestazioni sono vicine...te lo assicuro...
Originariamente inviato da marcus21
2) Opteron è per server,G5 è desktop,quindi non ho detto una cazzata (e poi allora lo dice anche apple)
Opteron è anche una CPU Workstation e quindi va ad interesecare anche il mercato dei G5...
Originariamente inviato da marcus21
6) Spiacente della catena di discussione piuttosto accesa e dei vari commeti del tipo (parla per sentito dire...),dico non prendetevela e non facciamo sempre i paladini di una casa produttrice o dell'altra,questo si che è una moda!
Take it easy.... : )
Se continuano li riprendo io :Perfido:

Comunque non è il momento di una discussione MAC vs. PC ;)

bah..leggendo i post precedenti....

G5...si da la polvere...peccato che per i bench abbiano usato un doppio g5 modello di punta contro l'opteron (il primo uscito). se fanno un confronto SINGOLO athlon FX-54 con DOPPIO G5 "modello di punta"....non so chi dei due potrebbe vincere...

Itanium: intel ha sbagliato tutto, software complessi da programmare, retrocompatiblità 32 bit scandalosa (velocità degne di un pentium 2), retrocmpatibilità 16 praticamente inesistente. Costi altissimi, prestazioni elevate a 64 bit solo su software fortemente ottimizzati.

AMD64: compatibilità 32 bit ottima prima vi di emulazione, velocità a parità di frequenza maggiore del k7 e sue evoluzioni (athlon xp barton), conseguente compatibilità con i 16 bit.
Velocità 64bit ottima (anche se...bench ufficiali con software fortemente ottimizzati non ce ne sono), non compete con itanium per l'ovvia destinazione di mercato. Costo "basso" per essere una rivoluzione.
E' una rivoluzioni ed è la scelta più azzeccata.E' come avere due processori: il top per i 32 in ogni ambito, il top per i 64bit in ambito desktop.
x86-64 è uscito da molto oramai: la struttura è cambianta con l'aggiunta di 8 registri ok...ma l'assembler è l'assembler...chi conosce quello per i 32bit può senza fatiche estreme partire con il 64bit.

Pur continuando a pensare che prestazionalmente parlando il mac sia meglio e i test sono fatti con programmi da tutti i tester utilizzati e poi la apple non penso si metta a fare "false comunicazioni sociali"per di più negative verso concorrenti,il senso delle mie affermazioni era semplicemente di guardare il mercato non solo a metà,ma anche con una terza componente che,seppur differente e incompatibile,da' sempre un riferimento importante per chiederci quanta qualità effettivamente c'è nelle configurazioni alte che i due unici produttori ci propongono.
Detto questo che ognuno la pensi in maniera differente è anche un bene(vuol dire che si può..!)basta che non si dica che uno parli per dar fiato alla bocca.
Riformulo gli auguri a tutti! : )

Originariamente inviato da bs82
Velocità 64bit ottima (anche se...bench ufficiali con software fortemente ottimizzati non ce ne sono)
Sì, ce ne sono.
Ho visto alcuni benchmark di Apache a 64 bit (è stato citato in queste pagine) e il test di un compressore di file (tipo lo Zip). Quest'ultimo, tra l'altro, guadagnava tantissimo in prestazioni nella modelità a 64 bit, anche se il test era di parte.

Mi permetto di aggiungere una nota.
Ho letto molti commenti in questo therad che sembrano dire che AMD non ha fatto altro che aggiungere qualche estensione a 64 bit ad una famiglia di processori già vecchia, mentre Intel è stta innovativa con l'Itanium.
A questo proposito, mi permetto di far notare che l'architettura multiptocessore di Intel per gli X86 è rimasta ferma all'era dei primi Pentium, con il bus condiviso. Mentre AMD ha subito proposto delle soluzioni più innovative con il bus dedicato dell'Athlon MP ed ora le interconnessioni multiple Hyper Transport degli Opteron.
Quest'ultima architettura oltre ad essere estremamente innovativa dovrebbe dare un buon boost prestazionale ai sistemi.

Originariamente inviato da cionci
Non è assolutamente lineare...dai 16 ai 32 bit non sono stati aggiunti registri...sono solamente stati estesi quelli già presenti...
Nell'x86-64 di AMD, oltre all'estensione dei registri già esistenti, sono stati aggiunti 8 registri general purpose...e sarà quello uno dei principali vantaggi nell'esecuzione di un codice a 32 bit ricompilato per AMD64... I registri general purpose sono chiamati R8...R15... Se l'azienda Pinco Pallino ad esempio avesse chiamato gli 8 registri aggiuntivi della sue estensione di x86 a 64 bit R1...R8 allora non sarebbe compatibile con AMD64...
Ancora più semplice...la codifica binaria delle istruzioni... Ovviamente è cambiata anche perchè devono essere codificati anche i nomi dei registri aggiuntivi e degli operatori a 64 bit... Dici che esiste un solo modo per codificare i codici operativi ?
Poi esistono delle direttive per la programmazione in assembler...queste direttive devono essere rispettate da chi programma in assembler e da chi scrive i compilatori... Sono direttive relative, ad esempio, al passaggio dei parametri alle procedure assembler...
Se anche solamente una di questi parametri fosse diverso tra AMD e Intel allora non sarebbero compatibili !!!
Quindi insisti ancora a dire che esiste solamente un modo per estendere x86 ai 64 bit ? Volendo Intel può fare il suo set di istruzioni proprietario...
Tutto dipende da Microsoft !!!

E' vero che tutto dipende da microsoft! ma è anche vero che ms ha già pronto in beta winxp64 che uscirà ufficilamente in aprile, nello stesso momento che uscirà, ad esempio, far cry 64 (il team ha sviluppato in parallelo le due versioni di questo gioco a 32 e a 64 bit).
Per quanto riguarda l'assembler, è vero che ci sono state fatte delle modifiche,ma per il programmatore che l'ha usato per anni a 32 bit tutto ciò sarà una passeggiata oltre ad essere una manna dal cielo! Infatti quei registri in più faranno snellire parecchio il codice (sai le bestemmie quando bisognava ogni volta svuotare un reg per farci stare una nuova varibile mantendedo nei registri il valore precedente?) e così lo velocizzeranno, senza dar troppi crucci ai programmatori.

Che difficoltà il nuovo mov per i 64 bit! (ehm...il comando più usato, se ne stima un 60% in tutte le applicazione sul totole dei comandi assembler):

movl $1, %eax # 32-bit instruction
movq $1, %rax # 64-bit instruction

Ovvio che processi come il displacement, o le allocazioni saranno un po più complicati ma la sintassi resta sempre la stessa.

Originariamente inviato da bs82
Che difficoltà il nuovo mov per i 64 bit! (ehm...il comando più usato, se ne stima un 60% in tutte le applicazione sul totole dei comandi assembler):

movl $1, %eax # 32-bit instruction
movq $1, %rax # 64-bit instruction

Ovvio che processi come il displacement, o le allocazioni saranno un po più complicati ma la sintassi resta sempre la stessa.
Non ci siamo capiti...tu dicevi che l'estensione di x86 a 64 bit è quella e non ce ne possono esserne altre dal punto di vista della programmazione...io invece volevo dire che ad Intel non ci vorrebbe niente a relizzare un'estensione proprietaria...anche mantendendo lo stesso codice assembler...basta cambiare, che so, la rrappresentazione in linguaggio macchina della mov e non ci sarebbe più compatibilità ;)

Originariamente inviato da Raid5
Mi permetto di aggiungere una nota.
Ho letto molti commenti in questo therad che sembrano dire che AMD non ha fatto altro che aggiungere qualche estensione a 64 bit ad una famiglia di processori già vecchia, mentre Intel è stta innovativa con l'Itanium.
A questo proposito, mi permetto di far notare che l'architettura multiptocessore di Intel per gli X86 è rimasta ferma all'era dei primi Pentium, con il bus condiviso. Mentre AMD ha subito proposto delle soluzioni più innovative con il bus dedicato dell'Athlon MP ed ora le interconnessioni multiple Hyper Transport degli Opteron.
Quest'ultima architettura oltre ad essere estremamente innovativa dovrebbe dare un buon boost prestazionale ai sistemi.

In effetti un 8-way con opteron funziona molto più efficacemente di un equivalente intel per il semplice motivo che i gli 8 processori non solo condividono la potenza di elaborazione ma a coppie si dedicano alla gestione dell'hardware che compone il sistema, senza interferire fra di loro.
Tra l'altro il consorzio dell'HyperTransport (cuore del multi-proc dei ssitemi amd64) sta crescendo sempre più grazie anche alla fiducia di grandi come IBM e Texas Inst.

C'è chi dice che l'architettura x86 è vetusta e intel ha deciso di rompere con il passato. Qua molti parlano senza sapere un minimo di storia informatica. L'architettura Netburst (del P4) quando è stata introdotto da intel è stata introdotta con lo scopo di salire in frequenza e dare linfa vitale al x86 x i prossimi 10-20 anni, l'itanium a 64 bit è sattto introdotto da intel per invadere il mercato delle grosse workstation (alpha, sun, IBM)con cpu relativamente + economiche, dove neanche apple mettere piede. Il merito di Amd è quello di essere la prima ha portare i 64 bit nei desktop e il fatto che l'opteron sta mettendo in discussione non tantto gli xeon ma l'Itanium a creato grossi problemi ad Intel. Molte persone parlono dell'opeteron come cpu costosa, ma forse si dimenticano che l'opteron non è la cpu per l'utente che deve giocare con il computer.
Intel adesso secondo me commette un errore simile a quello delle rambus ma non uguale! Prima ha cercato di imporre uno standard senza che il mercato lo richiedesse adesso sta cercando di negare uno standard che richiede. Molti sapientoni dicono che i 64 bit non servono a niente, perché adesso lo dice intel, ma un programma ottimizzato per i 64 bit è meglio che avere 1mega di cahce o 100mhz in +. Molti programmi di masterizzazione e di rippaggio con il supporto ai 64bit stanno già uscendo e pach per programmi di grafica stanno in cantiere e se nella fasica server l'optern ha venduto il doppio dell'itanium negli ultimi mesi, un motivo ci sarà non credete?
L'ht, le sse, sse2 sono solo modi andare un po' + veloci ma non sono niente di rivoluzionario. ALcuni si lamentano dei cambi di socket ecc... adesso si lamentano della scelta di AMd di rimanere compatibile con il passato. Intel non vuole sacrificare l'itanium che gli è costato tantissimo e non è mai avuto un grosso sucesso sin dalle prime versioni. Penso che in futuro vedremo per il desktop il Pentium 64, per server e workstation lo xeon 64 e per i super computer L'itnaium con 16mega di cache on die. Intel sta sicuramente temporeggiando per spingere l'itanium ad una fascia superiore di mercato per dopo introdure l'x86-64.

Originariamente inviato da cionci
Non ci siamo capiti...tu dicevi che l'estensione di x86 a 64 bit è quella e non ce ne possono esserne altre dal punto di vista della programmazione...io invece volevo dire che ad Intel non ci vorrebbe niente a relizzare un'estensione proprietaria...anche mantendendo lo stesso codice assembler...basta cambiare, che so, la rrappresentazione in linguaggio macchina della mov e non ci sarebbe più compatibilità ;)

Si ho solo tralasciato la risposta che volevo darti su questo. La mia risposta sarà molto terra... se intel fa un'estensione proprietaria destinata al desktop....è rovinata.
Si perchè un programmatore che vuole distibuire il suo software su tutti si sistemi windows based sarà costretto a fare ben 3 versioni del programma. anzi due: perchè se parte dai 32 bit e vuole i 64bit amd gli basterà un compilatore apposito (ovvio che se vuole tutto perfettamente ottimizzato dovrà riscrivere il codice) mentre se vuole i 64 bit intel (con estensione diversa e perciò non derivata dai precedenti 32bit) sarà costretto a riscrivere il codice e soltanto dopo a ricompilare.
Già adesso in linux se vuoi ci sono i software che ti compilano a 64bit i sorgenti a 32bit x86. Ma non ci sono, ad esempio, per convertirli nei 64bit di itanium, appunto perchè è un formato "troppo" diverso dal precedente x86 di intel: necessitano la riscrittura del codice.
Ed è qui la linearità obbligata della conversione x86-32->AMD64: è la strada più corta e più simile...ed amd l'ha intrapresa per prima. Se intel farà un'altra versione non sarà mai tanto simile e vicina ad x86 come lo è amd ora!

Continuiamo a non capirci...

AMD da x86-32 deriva il suo x86-64...e come dici tu non è necessario riscrivere il codice, ma basta ricompilare...

Intel da x86-32 deriva un altro x86 a 64 bit non compatibile con il linguaggio macchina di x86-64 di AMD (con l'assembler può anche esserlo niente lo vieta)...anche per questo non è necessario riscrivere il codice, ma basta ricompilare...

Risultato...due istruction set x86 a 64 bit non campatibili fra di loro...e se M$ da appoggio anche a x86 a 64 bit di Intel allora AMD è rovinata... ;)

Originariamente inviato da bs82
Se intel farà un'altra versione non sarà mai tanto simile e vicina ad x86 come lo è amd ora!
Perchè no ?!?!? Basta usare un'altra codifica binaria dei registri negli operatori del codice operativo delle istruzioni...
Ed ecco che è vicina quanto AMD, ma incompatibile con AMD...

Originariamente inviato da cionci
Insomma...oggi P4 e K7/K8 (li metto insieme perchè sono più simili di quanto pensiate) non è più niente da individuare alle CPU RISC...e il discorso sui difetti dell'x86 regge poco (praticamente l'unico è lalunghezza variabilie delle istruzioni) perchè ampliamente superato...
Condivido quello che hai detto.
Forse non ci siamo capiti sul "vecchiotto": non intendevo certo dire obsoleto o superato (ho infatti precisato che è ancora valido per il desktop).
Tra i difetti dell'x86 ci metterei anche il numero limitato di registri.

Comunque mi sembra poco costruttivo paragonare Athlon-64 con Itanium (o i rispettivi instruction set): non centrano niente.

Originariamente inviato da xtg
Tra i difetti dell'x86 ci metterei anche il numero limitato di registri.
Difetto superato dall'x86-64 di AMD...
Originariamente inviato da xtg
Comunque mi sembra poco costruttivo paragonare Athlon-64 con Itanium (o i rispettivi instruction set): non centrano niente.
Chiaro...sono completamente diversi...

Originariamente inviato da cionci
Difetto superato dall'x86-64 di AMD...

x86-64 di AMD è una buona estensione dell'x86 originario: lineare, pulita, compatibile (come detto in altri msg).
Però anche 16 registri g.p. sono veramente pochi, ma non è molto importante... ci sono isa con 64 o 128 gpr, ma cambiano molte cose, non solo il n.ro di registri. E comunque non sono per desktop e nemmeno per le nostre tasche (almeno non per le mie).

dopo aver chiarito penso unanimamente che gli itanium su desktop non li vedremo mai, penso che sia praticamente sicuro che prima o poi intel tiri fuori una cpu x86-64 compliant.

anche se ho molta paura che la vorrà corredare da set di istruzioni "alternative" che "velocizzeranno" l'esecuzione di tasks di un certo tipo o di un altro... :(

gggggggg A

Un saluto a tutti.:cool:

Sono alcuni mesi che vi seguo, e devo ringraziarvi perche', seguendo le vostre interessanti discussioni, ho imparato molte cose utili.

Solo questa sera, pero', ho sentito l'esigenza d'inserirmi nella discussione, ed il motivo e' molto semplice.
Tra un po' dovro' acquistare un PC (penso , a questo punto, che me lo faro' assemblare), e cominciare a familarizzare con Win, inquanto saro' costretto ad "interfacciarmi" con aziende che con Mac non "dialogano".

Ho cominciato qualche anno fa con un imac: prima, di computer, non ne volevo nemmeno sapere:lamer:
Ma il mio lavoro, la fotografia, ha preso ad andare prepotentemente in questa direzione: o imparavo , o ero tagliato fuori.
Devo dire che, per chi come me, chiede di imparare ad usare la "macchina" alla svelta, per potersi concentrare sul proprio lavoro, senza dover impazzire dietro a compatibilita', bios, aggiornamenti, drivers, compilazioni, e tutta quella valanga di termini astrusi legati a tutto cio' che e' informatica, la scelta di Mac e' soddisfacente: prodotto valido, interfaccia gradevole ed intuitiva, stabilita'.
Il risvolto della medaglia e' che sei nelle loro mani ( buone mani, per carita') e, almeno fino a qualche anno fa, all'oscuro di tutto cio' che e' hardware.
Adesso , con OSX e i nuovi G5, le cose sono cambiate ancora in meglio, pero' , , leggendovi, ho scoperto un mondo che non conoscevo.;)

Mi sono dilungato solo per gettare una luce su quello che, secondo me, e' il mercato reale: un sacco di persone che comperano PC, senza avere alba di cio' che acquistano, basandosi sul sentito dire, o sulla fama di un marchio piuttosto che di un altro ( venendo a contatto con molti clienti quotidianamente, ne ho la conferma).

Ma veniamo al dunque:O ....dopo avervi seguito per mesi ( complimenti!..proprio un bel sito), mi ero risolto per PIV 2,6, AsusP4c800 deluxe, nVidia 5900XT, un paio di Maxtor SATA 80Gb in Raid 0,1, e 1Gb di Corsair DDR4002c....eccc...ecc...( ho imparato tutto qui' da voi: prima non ne capivo un emerito BIIIIIPPPP:p ).

Confesso che qualche dubbio tra AMD e Pentium, all'inizio lo avevo, infatti mi ero orientato verso l'AMD64: sembrava darmi maggiori garanzie per eventuali evoluzioni future. Ma poi, quando hanno cominciato a giocare con i socket, ho capito che, cmq, nessuno mi garantiva che la macchina comperata oggi, potesse essere attuale e supportata completamente anche nel prossimo futuro, tanto da coprire maggiormente l'investimento.

Questa sera, poi, dopo aver letto tutti i vostri commenti, ne deduco una cosa:
che, come in molti altri campi, e' il marketing a guidare le danze:oink: , e non sara' il prodotto migliore a vincere, ma quello con i poteri piu' forti alle spalle.

Non credo nemmeno che Jobs e Bill siano poi cosi' antagonisti:
si tirano la volata a vicenda, e cmq, tutto il mondo cade in mani AMMMMERRRIKANE:cincin: :fuck:

Una cosa va detta: Apple ha molto piu' stile.

Un sincero augurio per un 2004 meno incasinato..........:bsod:

Io non ho esperienza diretta e professionale con i mac, ma tu hai detto con competenza e,appunto,esperienza fatta sulla tua pelle, quello che volevo dire io: Apple non ti fa cambiare una macchina ogni secondo,è affidabile,fa sistemi operativi che non si inchiodano mai ed è all'avanguardia. Unico problema non è "pubblicizzato" da rendere il brand di largo consumo come i tradizionali pc.
Grazie

Originariamente inviato da marcus21
fa sistemi operativi che non si inchiodano mai ed è all'avanguardia.

Tutt'altro, molti degli ultimi Mac OS prima di X si piantavano alla stessa maniera di Windows...così almeno mi è stato detto da chi con il Mac ci ha lavorato una vita intera...
Ora certo con X le cose sono cambiate...e guardata caso con un OS *nix...
Originariamente inviato da marcus21
Unico problema non è "pubblicizzato" da rendere il brand di largo consumo come i tradizionali pc.

Secondo me il Mac è molto pubblicizzato rispetto alla fetta di mercato che occupa...e credo che l'unico problema del Mac sia di non essere un PC...tutto qui...

Salve a tutti,

avete detto molto e per chi non è al vostro livello è facile perderisi.

L'utente medio non filosofeggia ma punta al concreto.

Gli Apple saranno anche fantastici, ma sono chiaramente
quasi sopra la nicchia; qui tra voi, chi è disposto a mollare di punto in bianco il mondo x86 per G5? Scommetto pochi.
Io non ho certo soldi da buttare, così come tutti quelli che hanno investito una marea di soldi in soft professionali e non x x86.

Guardare alla storia passata va bene, ma nel mondo informatico conta fino ad un certo punto.

L'Itanium, secondo me, non è da prendere neppure in considerazione perchè non è diretto al mercato Soho e Home e non è in continuità col passato.
Tra voi c'è qualcuno disposto a buttare soft da milioni
dalla finestra per spenderne altrettanti per una versione degli stessi che supportino un altra piattaforma?

Fino ad ora AMD ha giocato le sue carte in modo vincente, i prodotti che ha tirato fuori K7 e K8 si sono rilevati ottimi e convenienti. Dite di no!
Ha un venti x100, ma in crescita; da qualcosa bisogna cominciare .
Il K8 rappresenta ad oggi una soluzione conveniente e lo sarà ancor più nei mesi prossimi con l'aumento della produzione, per non parlare dell'ovvio rilascio di MS 64bit.
MS ormai si trova costretta a rilasciare un os64
per far fronte all'affrancamento senza sosta del mondo Linux e l'unica cosa che può aver promesso alla socia Intel è una minima dilazione dei tempi per dare alla società di Santa Clara un pò di respiro.

Come acquirente Intel fin dal 8086 non posso che manifestare una certa delusione per la sua politica
commerciale che tende un pò a disorientare : HT sì HT no, Prescott, Socket T, Tejas, P4EE (esiste, mah!), BTX ecc...cpu con 64bit o no.....

AMD ha cercato di essere chiara nella sua evoluzione e i frutti si vedono : K8, cpu a 64bit che può far girare
soft a 32 senza problemi e con una protezione sugli acquisti passati e futuri. Non dimentichiamoci l'integrazione del controller della memoria, un vantaggio anche sui costi.

Se bisogna scegliere con la logica : AMD è evidente.

Spero comunque che Intel si dia una mossa a tirare fuori una cpu x86-64bit comatibile con AMD per non darsi la zappa sui piedi e ravvivare la competizione.
Dopo tutto è quello che vogliamo tutti.

Originariamente inviato da cionci
Tutt'altro, molti degli ultimi Mac OS prima di X si piantavano alla stessa maniera di Windows...così almeno mi è stato detto da chi con il Mac ci ha lavorato una vita intera...
Ora certo con X le cose sono cambiate...e guardata caso con un OS *nix...

Secondo me il Mac è molto pubblicizzato rispetto alla fetta di mercato che occupa...e credo che l'unico problema del Mac sia di non essere un PC...tutto qui...


Concordo: con OS 9 e precedenti, pur potendo contare su una certa stabilita' di base, non e' vero che non si piantassero mai. Poi tutto dipende da cosa ci si fa girare. Diciamo che Mac e' molto piu' indulgente e ti perdona parecchio, anche perche' non ti permette di andare in giro per il sitema a far casini, amenoche' uno non ci si metta proprio d'impegno.
Poi,di fondo, c'e' l'architettura RISC, che indubbiamente offre dei vantaggi.
OSX, basato su UNIX, e' molto pesante, ma l'idea di rendere amichevole ed accessibile a tutti UNIX attraverso un' interfaccia splendida ed intuitiva, unita ad un architettura IBM a 64bit, sta dando i suoi risultati.
Si', e' vero: Apple, per la fetta di mercato ridotta che copre, ha sempre goduto, soprattutto negli USA e in Giappone, di un supporto pubblicitario notevole e molto raffinato.
C'e' poi, la pubblicita' indiretta. Prendiamo l'iMAC , per esempio; complice l'indovinato ed innovativo design, lo si vedeva su qualsiasi ambientazione che prevedesse l'inserimento di un computer...dal catalogo d'architettura, alla scena di qualche film.
Va dato atto a Apple di aver precorso spesso i tempi in fatto di design:
il recente fenomeno del modding ne e' una conferma.
Parlarne qui, mentre state discutendo di aspetti tecnici molto specifici, e' decisamente OT, ma penso non sfugga nemmeno alla maggior parte di voi, il fatto che molte persone decidano l'acquisto del proprio PC, basando la propria scelta piu' sull' aspetto accattivante di un case, piuttosto che sul contenuto dello stesso.
Recentemente, in uno dei soliti ipermarket, ho visto un commesso convincere un cliente per una macchina con PIV 2,66 dal case "futuribile", spacciando la CPU come piu' recente del 2,6 HT fsb800 montata su di un analogo PC dall' estetica decisamente piu' anonima. Logica vuole che 2,66 sia " di piu' " che 2,6:sofico:
D'altronde il mondo dell'IT viaggia ormai ad una velocita' tale, che il commercio non riesce piu'a stargli dietro. E il design diventa un' arma utilissima per smaltire i magazzini.:D

Originariamente inviato da marcus21
fa sistemi operativi che non si inchiodano mai

sese... come no! il numero di volte che mi si inchioda XP è molto simile a quante volte lo fa OS 9 e X... molto vicino allo zero in entrambi i casi.
Pur usando programmi pesanti e in contemporanea su multiprocessori devo dire che quando uno avvia alla mattina difficilmente lo dovrà rifare prima di sera in entrambi i casi... solo che sull'apple ci mette di più! (la maggior parte dei powerbook non vengono mai spenti per questo motivo).

Per la mia esperienza non è la ricerca di prestazioni che fa scegliere Apple o PC... ma il portafogli, il gusto e la mentalità.

Concordo con cionci, flisi, raid5 e Gio&Gio.
Aggiungo che un'architettura può essere "vecchia" quanto si vuole, ma se poi a livello prestazionale riesce ad essere competitiva o addirittura a superare (anche nettamente) le architetture più blasonate, allora tanto di cappello: la differenza la fa la velocità di esecuzione delle applicazioni, non l'architettura su cui gira.

Quanto ad EPIC, mi spiace, ma la ritengo un enorme buco nell'acqua: l'unico campo in cui "macina" è l'FP, per il resto è meglio calare un velo pietoso, visto che viene fatta fuori addirittura "in casa" dal P4 (desktop), per non parlare degli Opteron (server). Sarà pure una bellissima architettura, ma mi sembra che Intel e HP abbiano voluto strafare con questo progetto. Tanto per fare un esempio: 128 registri possono sembrare una manna, ma un programmatore "veterano" sa già che buona parte degli algoritmi che richiedono fino a 8 registri, e con 16 arriviamo a coprire la stragrande maggioranza della applicazioni reali.

Per il G5, mi spiace ma a livello di performance siamo ben sotto agli x86, ed è stato ampiamente dimostrato.

Un'ultima considerazione: il fatto che l'architettura x86 utilizzi un set d'istruzione a lunghezza variabile, IMHO porta degli enormi vantaggi rispetto alle architetture RISC a lunghezza fissa. Tanto ormai la complessità del decoder è stata spostata sulla lunghezza delle pipeline, e visto che pure i RISC ormai sono orientati verso questa direzione... ;)

Originariamente inviato da cdimauro
Concordo con cionci, flisi, raid5 e Gio&Gio.
Aggiungo che un'architettura può essere "vecchia" quanto si vuole, ma se poi a livello prestazionale riesce ad essere competitiva o addirittura a superare (anche nettamente) le architetture più blasonate, allora tanto di cappello: la differenza la fa la velocità di esecuzione delle applicazioni, non l'architettura su cui gira.

Quanto ad EPIC, mi spiace, ma la ritengo un enorme buco nell'acqua: l'unico campo in cui "macina" è l'FP, per il resto è meglio calare un velo pietoso, visto che viene fatta fuori addirittura "in casa" dal P4 (desktop), per non parlare degli Opteron (server). Sarà pure una bellissima architettura, ma mi sembra che Intel e HP abbiano voluto strafare con questo progetto. Tanto per fare un esempio: 128 registri possono sembrare una manna, ma un programmatore "veterano" sa già che buona parte degli algoritmi che richiedono fino a 8 registri, e con 16 arriviamo a coprire la stragrande maggioranza della applicazioni reali.

Per il G5, mi spiace ma a livello di performance siamo ben sotto agli x86, ed è stato ampiamente dimostrato.

Un'ultima considerazione: il fatto che l'architettura x86 utilizzi un set d'istruzione a lunghezza variabile, IMHO porta degli enormi vantaggi rispetto alle architetture RISC a lunghezza fissa. Tanto ormai la complessità del decoder è stata spostata sulla lunghezza delle pipeline, e visto che pure i RISC ormai sono orientati verso questa direzione... ;)

L'x86 è competitivo grazie all'attuale implementazione (sia pentium 3/4 che athlon). Non capisco se critichi l'EPIC come architettura oppure l'attuale implementazione Itanium. Sono d'accordo che Itanium come prestazioni non è un gran che'. Me secondo me l'architettura EPIC ha grossi margini di miglioramento. Probabilmente Intel si è mossa troppo in fretta, ma con l'ottica di essere pronta quando il mercato si sarà spostato verso l'alto.

16 registri sono abbastanza? Nel campo desktop sicuramente.
Non si scrive più in assembly? Nelle applicazioni per desktop non ha certo senso, i compilatori di oggi sono veramente ottimizzati.
Istruzioni a lung. variabile: che tipi di vantaggi avrebbero? (questa è proprio una domanda, vorrei sapere la tua opinione)
Io mi incasino già con quelle a lung. fissa ma ovviamente la (de)codifica delle istruzioni interessa a nessuno/pochissimi (chi deve fare simulazioni :D)
Tutto IMHO ed ovviamente basato sulla mia esperienza personale (credo approfondita ma sicuramente limitata)

Con Epic è praticamente impossibile lavorare in assembly vista la complessità dell'istruction set ! Servono compilatori super-ottimizzati per garantire un alto livello di parallelismo...e quindi il problema dei registri non si pone comunque...

Originariamente inviato da cionci
Con Epic è praticamente impossibile lavorare in assembly vista la complessità dell'istruction set ! Servono compilatori super-ottimizzati per garantire un alto livello di parallelismo...e quindi il problema dei registri non si pone comunque...
Infatti i 128 registri servono più che altro ai compilatori. Un bravo programmatore se la può cavare con molto meno (non 16 registri però, possono bastare per una funzione ma non per una applicazione...)
Effetivamente non conosco bene l'assembly per epic, ma solo quello di altre piattaforme vliw (sempre di derivazione hp).

bhoooooooooo per intel!!!W AMD

dai su....mi piange il cuore a leggere certe cose....perche' dove scanarvi ogni volta? perche' ogni volta fate a gara a chi la sa piu' lunga? qua non sarete certo classificati o valutatiper le vostre conoscenze o lìper la vostra mancanza di esse....

quindi perche' vedo tanta cattiveria in certi post? perche' qualcuno qua e la aggiunge sue idee e pensieri a quello che dovrebbe essere invece una spiegazione piu' specifica della news? io personalemente non capisco motlo si set di istruzioni (nove e passate), non consoco il cammino che un architettura ha seguito negli anni, non ne capisco quansi niente di registri ottimizzazioni compilazione asssembly......e come me tanti altri sono in questa situazione, e leggendo i commenti alle news cerco di apprende quanto piu' possibile cioe' che mi "manca", tante volte cdimauro o cionci (ne nomino 2 ma ce ne sono molti altri) mi hanno insegnato cose che in 10 anni di utilizzo del pc non mi ero nemmeno sognato che esistessero.... grazie a loro interventi ora ne so qualcosina di piu' ...pero' ultimamente leggo cose assurde...uno dice + l'altro - ..... no e' cosi' no e' cosa'..... io parlo perche' so....io parlo perche' vado alla ziccherazzarecche per ultra infomaniaci.....tu parli per sentito dire....lui parla per non sentirsi solo....... ma se dovessimo essere faccia a faccia tutto il giorno quanti andrebbero all'ospedale? (putroppo molti)

ma la finiaMO di abbaiarci contro o cosa? siamo una COMUNITA' con regole net-sociali e fra queste vi sono:
-educazione
-rispetto (sopratutto per chi non si conosce!!!!!)
-elasticita'....si elasticita' perche' non sempre potremmo avere intorno persone che la pensano come noi....che quando parliamo ascoltano e osannano....

siamo in tanti e tutti con esperienze diverse ma anziche' condividerle per crescere e migliorare ci scanniamo come allo stadio, facciaMO a gara a chi la sa piu' lunga....anche aggiungendo un po' di fantasia (vero che a volte si corre troppo con la fantasia?)

Scusami se ti sei sentito offeso o anniato da questa mia "missiva" ( ;) ) ma sono stufo di dover leggere certi commenti che sanno tanto di "letto e copiato ma non capito", che sanno di boria e straffotenza......


che ne dite cresciaMO un pochino? si...dai bravi cosi' vi volgio....

in superpace ilmanu

Originariamente inviato da ilmanu
Scusami se ti sei sentito offeso o anniato da questa mia "missiva" ( ;) ) ma sono stufo di dover leggere certi commenti che sanno tanto di "letto e copiato ma non capito", che sanno di boria e straffotenza......

non so se era riferito a me, comunque da parte mia sono andato decisamente ot...

ODDIO!!! quello che dice che il g5 si mangia qualsiasi pc, l'altro che non si rende conto che x86-64 è di amd tanto quanto fu di intel il passaggio a x86-32...


ragazzi, che palle il pretendere di FARE informazione! andrebbe diffusa, per la maggior parte dei casi, l'informazione, non creata dal nulla.

Originariamente inviato da PeK
il 20% del mercato può convincere amici/parenti/vicini/passanti a spendere di meno per un amd64+linux64 piuttosto che comprare un itanium+windows...

ammazza, amici e parenti che ti convincono a prendere un itanium
:sofico: :sofico: :D

scherzi? io proprio l'altro giorno a mio cuggino gliene ho consigliati un paio... lui voleva prendersi una ultrasparc....ma gli ho detto di lasciare perdere... :sofico: http://punto-informatico.it/images/emo/troll.gif

Originariamente inviato da W4rfoX
Che dire c'e' scritto tutto e il contrario di tutto. :)
Allora cerchiamo di chiarire, no? ;)
Nel 2004 ormai nessuno programma in assembler,
Dipende dall'applicazione: tanti giochi hanno ancora delle sezioni in assembly (n.b: assembly è il linguaggio, mentre assembler è il compilatore) per sfruttare al meglio le parti critiche.
aveva senso quando la potenza delle CPU era poca e il software doveva essere ottimizzato per spremere ogni ciclo, aveva senso quando scrivevo giochi sugi 486 e pentium ma solo per i giochi, ormai nemmeno piu' per quello.
C'è da dire che per i giochi adesso c'è anche un'altra forma di programmazione "assembly": gli shader... ;)
Gli apple non si scelgono per le sole performance, e' tutto il flusso di lavoro che ne ha giovamento dall'impressionante integrazione tra i vari soft[...]
Nessuno dice il contrario: difatti si parlava esclusivamente di performance. ;)

Originariamente inviato da xtg
L'x86 è competitivo grazie all'attuale implementazione (sia pentium 3/4 che athlon). Non capisco se critichi l'EPIC come architettura oppure l'attuale implementazione Itanium.
Per l'architettura in primis. Per quanto riguarda l'implementazione, per fortuna con Itanium II abbiamo cominciato a vedere delle prestazioni decenti. Certo è che fa impressione notare l'utilizzo spropositato di cache di terzo livello per rendere più performante,e quindi più competitivo, questo prodotto...
Sono d'accordo che Itanium come prestazioni non è un gran che'. Me secondo me l'architettura EPIC ha grossi margini di miglioramento.
Quando? Intel dispone della miglior tecnologia nel campo dei compilatori, e ancora non è riuscita a sfruttare per bene la sua nuova architettura. C'è qualcosa che non quadra, non credi?
Probabilmente Intel si è mossa troppo in fretta, ma con l'ottica di essere pronta quando il mercato si sarà spostato verso l'alto.
Troppo in fretta? L'Itanium come progetto ha più di 8 anni di vita: mi sembrano abbastanza per pensare, in questo lungo arco di tempo, di renderlo competitivo...
16 registri sono abbastanza? Nel campo desktop sicuramente.
Non solo, era un discorso generale. Esistono degli studi sugli algoritmi in cui si analizza il quantitativo di registri necessario per poter coprire interamente l'esecuziona di una routine. Buona parte richiedono fino a 8 registri, la stragrande maggioranza fino 16, e una piccolissima parte fino a 32 registri (l'implementazione del parser del linguaggio Perl, se non ricordo male), e si possono contare quelle che ne richiedono più di 32.
Non si scrive più in assembly? Nelle applicazioni per desktop non ha certo senso, i compilatori di oggi sono veramente ottimizzati.
Compilatori realmente ottimizzati, nell'accezione accademica del termine, non ne esistono e non ne esisteranno mai. Il problema della generazione del codice ottimale a partire da un qualunque sorgente è dimostrato essere non computabile.
Diciamo che gli attuali compilatori fanno un buon lavoro... :)
Istruzioni a lung. variabile: che tipi di vantaggi avrebbero? (questa è proprio una domanda, vorrei sapere la tua opinione)
I vantaggi sono che si utilizza (quasi sempre) il minimo numero di bit (ma è meglio parlare di byte, alla fine) che sono necessari per rappresentare l'operazione che si vuole eseguire. Sono, quindi, notevoli in termini di spazio occupato, e le implicazioni pratiche sono le seguenti:
1) minor utilizzo della cache L1
2) minor banda necessaria
3) possibilità di poter estrarre dalla linea di cache L1 un maggior numero di istruzioni
4) nessuno spreco di spazio nel caso in cui sia necessario inserire un'istruzione NOP nel flusso del codice, a causa di particolari vincoli architetturali (mi riferisco, per fare un esempio chiarificatore, ai vincoli di architettore VLIW e EPIC, che non possono eseguire sempre e comunque "n" istruzioni a causa di problemi di dipendenza e debbono quindi inserire nella "macroistruzione" delle NOP)
5) minor dimensione dell'eseguile finale

Pensa ad un'istruzione "mov registro, registro", oppure una "inc/dec registro", ad esempio: sono le più frequenti, ma occupano pochissimo spazio (la prima un byte se viene coinvolto il registro accumulatore, 2 altrimenti, mentre le altre due sempre un byte).
Il risparmio di spazio è notevole. In un'architettura RISC devi sempre e comunque occupare esattamente lo stesso spazio, anche nel caso di istruzioni piccole come quelle (ma che sono anche le più frequenti, ripeto).
Io mi incasino già con quelle a lung. fissa ma ovviamente la (de)codifica delle istruzioni interessa a nessuno/pochissimi (chi deve fare simulazioni :D)
Esattamente. ;) Comunque interessa anche i cultori delle architetture... :D
Tutto IMHO ed ovviamente basato sulla mia esperienza personale (credo approfondita ma sicuramente limitata)
Come del resto tutti, no? :)

Originariamente inviato da xtg
Infatti i 128 registri servono più che altro ai compilatori.
IMHO sono anche troppi, e possono anche essere fonte di problemi. Difatti l'accesso ai 128 registri sull'EPIC non avviene tanto velocemente quanto nelle altre architetture con un minor numero proprio per questo motivo, a cui si aggiunge anche il meccanismo di "rotazione"...
Un bravo programmatore se la può cavare con molto meno (non 16 registri però, possono bastare per una funzione ma non per una applicazione...)
Indubbiamente. Ma considera che la maggior parte del tempo che viene speso nella computazione di un'applicazione si ha nell'esecuzione di cicli, per cui alla fine è lì che devi sfruttare al meglio il numero di registri disponibile, e non mi pare che sia un'operazione difficile, anche per un compilatore, avere un tetto massimo di 16 registri... ;)
Effetivamente non conosco bene l'assembly per epic, ma solo quello di altre piattaforme vliw (sempre di derivazione hp).
L'EPIC è comunque un VLIW, per cui l'esperienza che hai acquisito con questi ultimi puoi applicarla più o meno anche con questa "nuova" architettura. :)

Originariamente inviato da cdimauro
...
Quando? Intel dispone della miglior tecnologia nel campo dei compilatori, e ancora non è riuscita a sfruttare per bene la sua nuova architettura. C'è qualcosa che non quadra, non credi?

In effetti mi stupisce che non abbia un compilatore in grado di sfruttare al meglio l'epic.


Non solo, era un discorso generale. Esistono degli studi sugli algoritmi in cui si analizza il quantitativo di registri necessario per poter coprire interamente l'esecuziona di una routine. Buona parte richiedono fino a 8 registri, la stragrande maggioranza fino 16, e una piccolissima parte fino a 32 registri (l'implementazione del parser del linguaggio Perl, se non ricordo male), e si possono contare quelle che ne richiedono più di 32.

Per quel poco che ho capito, sevono soprattutto per algo crittografici, possibilmente eseguiti in real-time.


Compilatori realmente ottimizzati, nell'accezione accademica del termine, non ne esistono e non ne esisteranno mai. Il problema della generazione del codice ottimale a partire da un qualunque sorgente è dimostrato essere non computabile.
Diciamo che gli attuali compilatori fanno un buon lavoro... :)

Infatti intendevo che più di così non si può chiedere...


I vantaggi sono che si utilizza (quasi sempre) il minimo numero di bit (ma è meglio parlare di byte, alla fine) che sono necessari per rappresentare l'operazione che si vuole eseguire. Sono, quindi, notevoli in termini di spazio occupato, e le implicazioni pratiche sono le seguenti:
1) minor utilizzo della cache L1
2) minor banda necessaria
3) possibilità di poter estrarre dalla linea di cache L1 un maggior numero di istruzioni
4) nessuno spreco di spazio nel caso in cui sia necessario inserire un'istruzione NOP nel flusso del codice, a causa di particolari vincoli architetturali (mi riferisco, per fare un esempio chiarificatore, ai vincoli di architettore VLIW e EPIC, che non possono eseguire sempre e comunque "n" istruzioni a causa di problemi di dipendenza e debbono quindi inserire nella "macroistruzione" delle NOP)
5) minor dimensione dell'eseguile finale

Se partiamo dal presupposto che la decodifica abbia lo stesso "costo" posso essere d'accordo con te. Però secondo me le dimensioni del codice sono meno critiche rispetto ad una volta.
Per questo adesso vedo più interesse per le architetture vliw.
Inoltre considera che avere istruzioni a lung fissa ti permette di sapere in anticipo dov'è la prossima istruzione (a meno di salti, ovvio): questo è un grande vantaggio per architetture in grado di "macinare" molte istruzioni per ciclo (magari per i futuri processori multicore :D ).

Originariamente inviato da cdimauro
L'EPIC è comunque un VLIW, per cui l'esperienza che hai acquisito con questi ultimi puoi applicarla più o meno anche con questa "nuova" architettura. :)
Ho dato un'occhiata all'assembly epic: effettivamente non è molto comodo da scrivere rispetto al vliw che conosco :( .
Ma non è che l'assembly x86 l'ho capito in un giorno, anzi sicuramente non lo conosco tuttora bene...

In altre architetture la conoscenza dell'assembly era sicuramente utile per scrivere pezzi di codice ottimizzato... Con EPIC invece è praticamente impossibile superare l'efficienza del compilatore nello scrivere codice... Uno dei motivi principali, oltre alla difficoltà del codice stesso, è l'istruction level parallelism...
Sarebbe come mettersi a scrivere a mano codice SSE2 e poi confrontare il risultato con quello generato dal compilatore Intel ;)

Intel stessa mi sembra che sconsigli l'uso di parti di codice in assembly...

Originariamente inviato da cionci
In altre architetture la conoscenza dell'assembly era sicuramente utile per scrivere pezzi di codice ottimizzato... Con EPIC invece è praticamente impossibile superare l'efficienza del compilatore nello scrivere codice... Uno dei motivi principali, oltre alla difficoltà del codice stesso, è l'istruction level parallelism...
Sarebbe come mettersi a scrivere a mano codice SSE2 e poi confrontare il risultato con quello generato dal compilatore Intel ;)

boh, io scrivo "pezzi" di codice ilp meglio del compilatore (non intel, non epic, ma vliw), certo il loop unrolling glielo lascio fare a lui :D , ma in altri punti mi sembra un po' troppo "conservativo"...
certo un programma intero in assembly non lo scrivo neanche per x86


Intel stessa mi sembra che sconsigli l'uso di parti di codice in assembly...
Non c'è bisogno che lo sconsigli, si sconsiglia da solo...

Intendevo "pezzi" proprio nel senso che è raro scrivere un programma intero in assembly...in qualsiasi architettura...

Il discorso che facevo si riferiva interamente ad Epic...

Originariamente inviato da cionci
Intendevo "pezzi" proprio nel senso che è raro scrivere un programma intero in assembly...in qualsiasi architettura...

Il discorso che facevo si riferiva interamente ad Epic...
ops, mi era scappato il riferimento ai "pezzi" nel tuo post originario...
però perchè confidi così poco nelle capacità dei bravi programmatori? :)

ps: mi ero scusato per essere andato ot e ci sono ricascato!

Originariamente inviato da xtg
però perchè confidi così poco nelle capacità dei bravi programmatori? :)
Perchè da quello che ho visto ci sono decine di barbatrucchi in Epic per mantere un alto livello di istruction level parallelism... Mantente questo livello alto è l'unico modo per far sì che Itanium dia buone prestazioni...

se intel utilizzasse le stesse istruzioni introdotte da amd non si risolverebbero tutti i problemi? :D

Ragazzi ........... capire quello che scrivete è davvero difficile!!!
Venite forse da un'altro pianeta ............ :D
Scherzi a parte è interessante assistere ad un dibattito (scritto) tra utenti evidentemente competenti!!! ;)
Ciao a tutti e felice anno nuovo!!!!!!


Gio&Gio

Originariamente inviato da xtg
Per quel poco che ho capito, sevono soprattutto per algo crittografici, possibilmente eseguiti in real-time.
Sbagli: per questo tipo di algoritmi servono di più registri più ampi (64, 128 e più bit), non una quantità maggiore di registri (diciamo in misura minore).
Più registri servono, ad esempio, per il parsing di linguaggi molto complessi, come il Perl.
Infatti intendevo che più di così non si può chiedere...
Beh, i margini di miglioramento ci sono sempre, semplicemente non pensiamo che possano esistere compilatori, anche in un lontano futuro, che possano generare codice ottimizzato. ;)
Se partiamo dal presupposto che la decodifica abbia lo stesso "costo" posso essere d'accordo con te.
Considera che il "costo" della decodifica viene "spalmato" sui primi stadi di pipeline, per cui l'overhead introdotto da questa prima fase ormai è decisamente contenuto rispetto al passato. Difatti se guardi gli x86, abbiamo processori da 10 (Athlon), 12 (AMD64) e 20+ (P4) stadi di pipeline: rispetto al passato sono veramente molti, e in futuro assisteremo a ulteriori aumenti. Inoltre anche RISC sono ormai orientati verso quest'approccio: vedi Power4 e G5 di IBM, che addirittura presentano anche più stadi di pipeline del P4 (fino a 26!), e suddividono le istruzioni in una o più microistruzioni "ancora più RISC".
Insomma, mi sembra che l'approccio a lunghezza variabile non sia più penalizzante, ma al contrario sia diventato un punto di forza. :)
Però secondo me le dimensioni del codice sono meno critiche rispetto ad una volta.
Lo sono comunque se consideri che la dimensione della cache codice L1 non è elevata.
Per questo adesso vedo più interesse per le architetture vliw.
Sono interessanti perché sono più semplici da implementare. :)
Inoltre considera che avere istruzioni a lung fissa ti permette di sapere in anticipo dov'è la prossima istruzione (a meno di salti, ovvio): questo è un grande vantaggio per architetture in grado di "macinare" molte istruzioni per ciclo (magari per i futuri processori multicore :D ).
Lo puoi comunque fare anche con istruzioni a lunghezza variabile nella fase di pre-decodifica delle istruzioni, come ho già riportato. Addirittura gli Athlon e AMD64 conservano nella cache L1 e L2 delle informazioni aggiuntive per conoscere queste informazioni. :D

Originariamente inviato da cionci
Intendevo "pezzi" proprio nel senso che è raro scrivere un programma intero in assembly...in qualsiasi architettura...
Dipende anche dal tipo di architettura. Ai tempi dell'Amiga i programmi li facevo sempre in assembly Motorola 680x0 (a parte alcuni programmi per la scuola o università): dal comando "DOS", all'editor a oggetti (per sprite, tile, mappe, ecc.) dotato di GUI, fino all'emulatore 80186 a cui stavo lavorando; per non parlare dei giochi... ;)

Originariamente inviato da ilmanu
se intel utilizzasse le stesse istruzioni introdotte da amd non si risolverebbero tutti i problemi? :D
Sicuramente. E avremmo di nuovo una sana concorrenza... :)