Link alla notizia: http://www.hwupgrade.it/news/cpu/16248.html

La prossima evoluzione di cpu Intel per segmento desktop verrà proposta con due differenti dimensioni di cache L2, a seconda del modello

Click sul link per visualizzare la notizia.

Vorrei porre una domanda: qualcuno puo' spiegarmi la differenza tra la tecnologia EM64T dei processori intel con l'architettura a 64 bit dei processori AMD? Ho sentito dire che sono due cose diverse... Scusatemi ma io sono rimasto fedele ai buon vecchi 32 bit :D

Solo una cosa: non mi spiegate però l'architettura a 64 bit che la conosco ;) Solo che continuo a leggere di EM64T come di "supporto ai 64 bit". :confused:

Scusate mi autoquoto:

Solo una cosa: non mi spiegate però l'architettura a 64 bit che la conosco ;) solo che continuo a leggere di EM64T come di "supporto ai 64 bit". :confused:

Ok ho già letto tutto nella wikipedia :D

La VT di intel è come la Pacifica di AMD giusto ??? Ma mi spiegate come funzionano è quall'è il loro scopo ???

Da quel che ricordo hanno a che fare con ex palladium...

La VT di intel è come la Pacifica di AMD giusto ??? Ma mi spiegate come funzionano è quall'è il loro scopo ???

Da quel che ricordo hanno a che fare con ex palladium...

Sia VT che che Pacifica sono metodi di virtualizzazione implementate in hardware, che permette di far girare più macchine virtuali contemporaneamente sullo stesso processore fisico:nulla a che fare con palladium (se ricordo bone cos'è palladium :))
Tecniche di virtualizzazione software esistono da tempo (vedi XEN per linux o VMWare per Linux o Windows - Anche Microsoft mi pare abbia il suo software di virtualizzazione), ma avere tale possibilità in hardware è molto più vantaggioso in termini di prestazioni.

Il discorso sarebbe lungo, per una infarinatura puoi vedere qui (http://punto-informatico.it/p.asp?i=52148) , oppure sui siti di AMD e Intel, nella sezione dedicata alle soluzioni Enterprise (server).

Dimenticavo un link:

Per un approfondimento sulla virtualizzazione hardware, con particolare riferimento alla tecnologia Intel Vanderpool (VT), potete leggere qui (http://www.theinquirer.net/?article=21448) , se masticate un po' di inglese ;)

E nel frattempo AMD pare posticipi l'uscita del socket M2 (http://www.theinquirer.net/?article=29320) che porta la DDR2 & C al 3Q dell'anno.

In teoria la notizia può suonare negativa ma mi sa che invece stavolta è una mossa di marketing, lato nel quale AMD è sempre stata inferiore rispetto alla rivale.

Si crea attesa per le nuove Cpu AMD distogliendo potenziali acquirenti dal Conroe che tra l'altro non si sa ancora che livello di competitività potrà avere con le attuali cpu AMD Athlon 64X2.

Io credo che Intel dovrà rincorrere anche col Conroe riguardo alle prestazioni, ergo se la giocherà sul prezzo.

Non sono molto informato su questi aspetti tecnici: quanti stadi ha la pipeline degli attuali Pentium 4 e Pentium D? E gli Athlon 64?

Pentium 4 e Pentium D hanno 31 stadi di pipeline. Gli Athlon64 14, gli Athlon XP 12. Questo per quanto riguarda il calcolo sugli interi.

Io credo che Intel dovrà rincorrere anche col Conroe riguardo alle prestazioni, ergo se la giocherà sul prezzo.

Scusa ma su che basi affermi ciò? Ci sono già dei test in giro o sei semplicemente un fanboy AMD?? :mbe:

hanno ricominciato ad allungare la pipeline? :mbe:
ma non imparano mai?

Aspetto le recensioni future sui Conroe, sono curioso della risposta che Intel ha preparato, anche se prevedo che sarà dura scalzare il vantaggio di Amd.

hanno aumentato di 2 stadi la lunghezza della pipeline rispetto al Pentium M se non erro, sintomo che queste CPU scaleranno un po' meglio in frequenza :O anche perché immagino saranno dotate di Quad Pumped BUS a 800 e 1066 (per gli EE)!!!
AMD ha anche posticipato il Socket M2, sinceramente non capisco il motivo, Intel aveva annunciato il suo Conroe per il Q306 e AMD ha ritardato il debutto delle nuove soluzioni per lo stesso periodo :confused: avrebbe potuto avere ancora un po' di vantaggio?!
@overclock80 su che cosa ti basi per dire che gli AMD saranno ancora superiori agli Intel?

per le prestazioni...
prendi un Core Duo, gli autmenti le frequenze (tipo dual 2600/2800) e ottini le prestazioni di Conroe (più o meno) anche se Conroe avrà una FPU completamente nuova e non una semplice revisione come è successo per Yonah :O

Una domanda: una lunga pipeline, pur essendo più complessa da gestire per diversi motivi con l'aumentare della lunghezza, non porta sempre vantaggi prestazionali? Se no, quali sono gli aspetti che possono portare ad avere vantaggio ad usare una pipeline più corta?

Una domanda: una lunga pipeline, pur essendo più complessa da gestire per diversi motivi con l'aumentare della lunghezza, non porta sempre vantaggi prestazionali? Se no, quali sono gli aspetti che possono portare ad avere vantaggio ad usare una pipeline più corta?
Le pipeline più corte consentono di avere una maggiore efficienza a parità di clock. Le moderne CPU hanno dei meccanismi di branch prediction (tentano di indovinare quale sarà l'istruzione successiva), che gli consentono di avere sempre tutti gli stadi della pipeline pieni e operativi.
Se questi algoritmi falliscono la previsione, si avrà una cosiddetta "bolla", cioè stadi della pipeline vuoti.
A quel punto sarà necessario cancellare il contenuto dell'intera pipeline, e ciò comporta maggiori sprechi di cicli di clock, maggiore è il numero degli stadi.
Per questo una pipeline più corta è più efficiente di una lunga.

Le pipeline più corte consentono di avere una maggiore efficienza a parità di clock. Le moderne CPU hanno dei meccanismi di branch prediction (tentano di indovinare quale sarà l'istruzione successiva), che gli consentono di avere sempre tutti gli stadi della pipeline pieni e operativi.
Se questi algoritmi falliscono la previsione, si avrà una cosiddetta "bolla", cioè stadi della pipeline vuoti.
A quel punto sarà necessario cancellare il contenuto dell'intera pipeline, e ciò comporta maggiori sprechi di cicli di clock, maggiore è il numero degli stadi.
Per questo una pipeline più corta è più efficiente di una lunga.

Molto chiaro. Non ricordavo che in presenza di una 'bolla' si dovesse svuotare l'intera pipeline. Ricordavo erroneamente che questo non fosse necessario. Thx ;)

ottimo son contento....questa architettura dovrebbe promettere bene, almeno in partenza

una pipeline lunga è ottima per scalare in frequenza ma ovviamente è molto complessa da gestire e la circuiteria di branch prediction è molto complicata...questo avveniva con i primi Pentium 4 core Northwood (versioni A e B) poi con la versione C (e con solo alcune versioni della B) c'è stata l'introduzione del HT che in pratica divide la pipeline in due parti (creando una sorta di parallelismo) e lo svuotamente e l'eventuale immissione di micro-istruzioni da elaborare poteva essere fatto anche a metà della pipeline :O
ora si tende ad aumentare l'efficenza come ha detto quartz piuttosto che ha curarsi della forza bruta ;)

una pipeline lunga è ottima per scalare in frequenza ma ovviamente è molto complessa da gestire e la circuiteria di branch prediction è molto complicata...questo avveniva con i primi Pentium 4 core Northwood (versioni A e B) poi con la versione C (e con solo alcune versioni della B) c'è stata l'introduzione del HT che in pratica divide la pipeline in due parti (creando una sorta di parallelismo) e lo svuotamente e l'eventuale immissione di micro-istruzioni da elaborare poteva essere fatto anche a metà della pipeline :O
ora si tende ad aumentare l'efficenza come ha detto quartz piuttosto che ha curarsi della forza bruta ;)

Rigrazie per l'ulteriore approfondimento ;)

Ma c'è davvero l'esigenza di avere 4MB di cache l2, oppure Intel ha abbandonato la corsa ai MHz per iniziare a fare a gara per vedere chi ha la cahe più grossa? :confused:

Ma c'è davvero l'esigenza di avere 4MB di cache l2, oppure Intel ha abbandonato la corsa ai MHz per iniziare a fare a gara per vedere chi ha la cahe più grossa? :confused:

Beh stai parlando di cache di secondo livello. Le cache di primo livello sono in genere piccole, per essere più veloci, e quindi sarebbe poco intelligente farla troppo grossa. La cache di secondo livello va allargandosi perchè, anche se è più lenta di una cache più piccola, ha un cache hit più alto. Non a caso la cache si divide in più livelli da un po' di anni proprio per questo.
Quindi mi pare più che buono che la cache di secondo livello sia sempre più ampia, poi se si allarga troppo si provvede ad un terzo livello.
Il problema della cache, oltre a difficolta' di progettazione, è il fatto che COSTA, molto più che la ram :) Quindi la aumentano via via che il costo realizzativo diminuisce.
Credo che sia solo un bene quindi se aumentano la cache della cpu, con i criteri esposti prima.

Pentium 4 e Pentium D hanno 31 stadi di pipeline. Gli Athlon64 14, gli Athlon XP 12. Questo per quanto riguarda il calcolo sugli interi.
mi sembra che per gli interi siano 10 per gli XP e 12 per A64

mmmhhh... :mbe:
forse che Intel abbia cambiato la nomenclatura dei processori, passando dalla frequenza a un numero, proprio perché tornando a un'architettura meno "sborona", con poche pipeline, dovranno abbassare la frequenza (senza farsi notare)? ;)

Cmq questa scelta architetturale in sostanza é la palese ammissione di aver cannato in pieno le scelte passate, a differenza di AMD... :D
- 64 bit:
intel ha introdotto IA64 ---> naufragato
amd ha introdotto x86-64 ---> successone imitato da intel con EMT64
- multithreading:
intel ha introdotto l'hyperthreading in CPU single core ---> brodino
amd ha introdotto il dual core ---> imitato da intel che adesso abbandona pure l'hyperhreading
- architettura:
intel ha introdotto un'architettura meno evoluta della precedente mettendo una marea di pipeline per salire di frequenza (tattica di marketing) ---> dopo un po' si é dovuta fermare per limiti tecnologici
amd si é dedicata allo sviluppo serio dell'architettura invece che ai trucchetti di marketing ---> intel adesso ha dovuto rifare tutto da capo imitando AMD

Che batoste... :D

Sarà interessante vedere se l'architettura Conroe sarà superore, pari o inferiore a quella AMD, ma a guardare le specifiche, il progetto in sostanza é stato "va bene, le CPU fatte al modo di AMD sono migliori, imitiamole e partendo da lì cerchiamo di fare di meglio".
Un pò il ragionamento che faceva AMD 11-12 anni fa quando rincorreva il Pentium di Intel.. come cambiano le cose!!

Scusatemi ma ho una domanda a cui non riesco a darmi una risposta:
perchè una pipeline più lunga permette una frequenza di clock maggiore mentre una pipe più corta no?

Scusatemi ma ho una domanda a cui non riesco a darmi una risposta:
perchè una pipeline più lunga permette una frequenza di clock maggiore mentre una pipe più corta no?
prendila con le molle, ma la motivazione per quanto ne so é questa:

in un processore, ogni istruzione per essere eseguita ha un certo tempo di latenza, che dipende da quanto il segnale elettrico ci mette a passare dai circuiti e ad essere elaborato.
Quindi il segnale di clock non può superare una certa frequenza, perché bisogna tenere conto del tempo di propagazione del segnale elettrico nel circuito.

Ovviamente, questo dipende anche dalla miniaturizzazione del processo produttivo.
Questo é il motivo per cui più la tecnologia progredisce e fanno processori miniaturizzati, più possono aumentare la frequenza: più sono miniaturizzati i circuiti, meno tempo il segnale elettrico ci impiega a propagarsi.

Ma a parità di miniaturizzazione della tecnologia costruttiva, é chiaro che in un circuito più grande e complesso il tempo di propagazione del segnale sarà maggiore, mentre in un circuito più piccolo e semplice, il tempo di propagazione del segnale sarà minore.

Quindi di conseguenza, il discorso degli stadi della pipeline:
Più sono gli stadi in cui é suddivisa la pipeline di esecuzione di un processore, meno ogni singolo elemento della pipeline é grande e complesso, e minore é il tempo di propagazione del segnale all'interno dei singoli elementi della pipeline.

Minore é il tempo di propagazione, più si può salire di frequenza di clock.

Si capisce? ;)

Minore é il tempo di propagazione, più si può salire di frequenza di clock.

Si capisce? ;)

Si capisce e ti ringrazio :) Ma parti da un presupposto: in una pipeline più lunga ogni singolo stadio e più grande in termini di circuiteria di una pipe più corta. Per quanto ne sapevo io invece ogni singolo stadio della pipe non varia di dimensione, semplicemente una pipe più lunga ha più stadi. Ed ogni stadio carica i valori con flip flop "paralleli" ad ogni colpo di clock (da cui un tempo di propagazione uguale per ogni signolo stadio).
Se il tuo presupposto è giusto tutto ok: qualcuno puo' confermare? :confused:

Si capisce e ti ringrazio :) Ma parti da un presupposto: in una pipeline più lunga ogni singolo stadio e più grande in termini di circuiteria di una pipe più corta.
no no un momento, mi sono spiegato male io oppure tu hai capito giusto ma ti sei confuso a scrivere. ;)
In una pipeline più lunga, cioé con più stadi, ogni singolo stadio é PIU' PICCOLO in termini di circuiteria, cioé in termini di quantità di transistor...
perché il numero totale di transistor del processore non varia!! :D
O meglio: puoi anche farlo variare, ma aumentre il numero di transistor vuol dire usare un wafer di silicio più grande e sfornare quindi un processore più costoso!! :D

Quindi a parità di numero totale di transistor nel processore, più sono gli stadi della pipeline, e minore é il tempo di propagazione dei segnali nei singoli elementi della pipeline.

Questo é il motivo per cui il Pentium 4 ha una frequenza molto più elevata rispetto all'Athlon 64, infatti il P4 ha una pipeline a 31 stadi contro i 12 dell'athlon 64.

mmmhhh... :mbe:
forse che Intel abbia cambiato la nomenclatura dei processori, passando dalla frequenza a un numero, proprio perché tornando a un'architettura meno "sborona", con poche pipeline, dovranno abbassare la frequenza (senza farsi notare)? ;)

Cmq questa scelta architetturale in sostanza é la palese ammissione di aver cannato in pieno le scelte passate, a differenza di AMD... :D
- 64 bit:
intel ha introdotto IA64 ---> naufragato
amd ha introdotto x86-64 ---> successone imitato da intel con EMT64

IA64 è un'architettura riservata ai server :rolleyes: ti aspettavi di vedere degli Itanium2 (dal costo non indifferente) sul mercato desktop :mbe: e quale sarebbe poi il vantaggio di AMD64 ed EM64T, io non lo sto ancora vedendo :asd:


- multithreading:
intel ha introdotto l'hyperthreading in CPU single core ---> brodino
amd ha introdotto il dual core ---> imitato da intel che adesso abbandona pure l'hyperhreading

se non vado errando Intel ha introdotto i DUAL CORE prima di AMD e comunque HT era unsa tecnologia che mirava ad aumentare l'efficenza dell'architettura NetBurst più che a parallelizzare i processi :O


- architettura:
intel ha introdotto un'architettura meno evoluta della precedente mettendo una marea di pipeline per salire di frequenza (tattica di marketing) ---> dopo un po' si é dovuta fermare per limiti tecnologici
amd si é dedicata allo sviluppo serio dell'architettura invece che ai trucchetti di marketing ---> intel adesso ha dovuto rifare tutto da capo imitando AMD

beh fino all'introduzione del Athlon64 mi sembra proprio che la scelta Intel fosse migliore, il paragone tra Athlon XP e Pentium 4 non era proprio alla pari :rolleyes:


Che batoste... :D

Sarà interessante vedere se l'architettura Conroe sarà superore, pari o inferiore a quella AMD, ma a guardare le specifiche, il progetto in sostanza é stato "va bene, le CPU fatte al modo di AMD sono migliori, imitiamole e partendo da lì cerchiamo di fare di meglio".
Un pò il ragionamento che faceva AMD 11-12 anni fa quando rincorreva il Pentium di Intel.. come cambiano le cose!!
ma che cosa stai dicendo? imitiamole... :doh: Intel ha iniziato con questa architettura ai tempi dell'introduzione di Centrino con il core Banias :O quindi diciamo che è nata prima dell'architettura K8 :muro:

e se avrà una fpu nuova che parli a fare ,hai visto dei test in giro?
.. ma lol
infatti ho detto che dovrebbero essere simili non identiche, una FPU nuova non è che stravolgerà le prestazioni ;) al massimo migliorerà in video editing e cose simili...

staremo a vedere,io prima di farmi un'idea preferisco vedere qualche bench serio.. anche perchè come cpu è davvero poco paragonabile sia allo yonah che ai vecchi p4.
beh l'architettura è la medesima dello Yonah...ossia la P6+ ;) quindi un minimo di paragone si può comunque fare.

IA64 è un'architettura riservata ai server :rolleyes: ti aspettavi di vedere degli Itanium2 (dal costo non indifferente) sul mercato desktop :mbe:
Frena frena frena... tutte le innovazioni tecnologiche, per svariati motivi, vengono sempre introdotte PRIMA nelle soluzioni hardware high-end, cioé nel caso di Intel e AMD parlamo di server e workstation di fascia alta.
Sia IA64 che x86-64 sono state introdotte sul mercato su processori di fascia alta, rispettivamente Itanium e Opteron, solo che IA64 non ha avuto successo e quindi non é stata portata sui desktop, mentre x86-64 ha avuto successo eccome E PERCIO' é stata portata sui procesori di fascia desktop.
Non rimescoliamo le carte... ;)
Limitandosi al confronto fra le soluzioni server, l'Opteron ha avuto molto più successo dell'Itanium...



e quale sarebbe poi il vantaggio di AMD64 ed EM64T, io non lo sto ancora vedendo :asd
forse tu usi Windows che é ancora a 32 bit? ;)
Comunque l'architettura K8 é ha 64 bit ma ha 1 riprogettazione intelligente in funzione di quello, che le permette di avere vantaggi notevoli anche nell'esecuzione di processi a 32 bit.
Mentre invece l'EMT64 é stato aggiunto ai Pentium solo come "una pezza" per stare dietro ad AMD, quindi sui processi a 32 bit non ha vantaggi prestazionali apprezzabili...


se non vado errando Intel ha introdotto i DUAL CORE prima di AMD
vai errando in senso stretto perché AMD é uscita poco prima, ma soprattutto vai errando in senso lato perché i Dual-core AMD sono stati fin da subito accessibili da un'utenza molto più vasta degli intel, vista la differenza di costo iniziale.
E il dual core AMD é stato lanciato praticamente in contemporanea anche sulle soluzioni server con Opteron.
Se a ciò aggiungi che mentre AMD ha fatto i dual-core su un wafer unico, come si deve, ottimizzando i consumi, mentre Intel ha messo 2 wafer sullo stesso connettore, si osserva come Intel abbia lanciato i suoi dual core in contempoaranea con AMD giusto per poter dire "li abbiam fatti anche noi", ma la soluzione Intel inizialmente era MOLTO meno fruibile, anche in questo caso fatta per star dietro ad AMD che era in vantaggio sul tempo... :D



e comunque HT era unsa tecnologia che mirava ad aumentare l'efficenza dell'architettura NetBurst più che a parallelizzare i processi :O
più che altro era una soluzione che, sfruttando la parallelizzazione dei processi, mirava a ottimizzare le pecche di un'architettura con una simile pipeline.
Senza la parallelizzazione dei processi del'HT non te ne fai niente. :D



beh fino all'introduzione del Athlon64 mi sembra proprio che la scelta Intel fosse migliore, il paragone tra Athlon XP e Pentium 4 non era proprio alla pari :rolleyes:
Ah no? Bella questa... :rotfl:
Se confronti una soluzione AthlonXP e una Pentium 4 di pari costo, l'Athlon XP la spunta sempre a parte in alcune situazioni... :D
Il che fa del P4 una CPU molto meno general purpose dell'Athlon XP... niente di male eh, se solo i consumatori ricevessero dei "consigli per gli acquisti" che non distorcono la realtà, saremmo tutti più contenti... :D
Alla lunga la corsa ai MHz del P4 effettuata grazie alla sua pipeline (che ricordiamolo, di recente col prescott é stata aumentata da 21 a 31 stadi) poteva avere la meglio, peccato che tale corsa si sia arrestata sbattendo il grugno contro i limiti tecnologici della tecnologia costruttiva...
:muro:



ma che cosa stai dicendo? imitiamole... :doh: Intel ha iniziato con questa architettura ai tempi dell'introduzione di Centrino con il core Banias :O quindi diciamo che è nata prima dell'architettura K8 :muro:
si ma il momento in cui AMD ha superato Intel mantenendo un'architettura con un numero ragionevole di stadi nella pipeline, é stato con l'introduzione dell'architettura K7.
La NetBurst di Intel é uscita dopo col P4 per cercare di recuperare, ma senza successo...
NetBurst ha "tenuto" sul piano delle vendite facendo leva sulla "pecoraggine" degli acquirenti che guardano il numero di MHz senza sapere cosa significa, ma non ha recuperato dal punto di vista tecnologico.

Quindi adesso Intel se torna ad un'architettura di QUELLA concezione, con molti meno stadi nella pipeline, deve rincorrere anche il K7, perché la migliore architettura mai avuta per le mani da Intel con QUEL tipo di pipeline era quella del Pentium3, che era inferiore all'architettura del K7.

Poi ripeto: magari il Conroe sarà meglio dei processori AMD, ma in tal caso questo significherà semplicemente che la "rincorsa" di Intel sarà riuscita!! ;)


PS: il K7 é uscito quasi 4 anni prima del Banias, per la precisione 3 anni e 9 mesi prima.

no no un momento, mi sono spiegato male io oppure tu hai capito giusto ma ti sei confuso a scrivere. ;)
In una pipeline più lunga, cioé con più stadi, ogni singolo stadio é PIU' PICCOLO in termini di circuiteria, cioé in termini di quantità di transistor...
perché il numero totale di transistor del processore non varia!! :D
O meglio: puoi anche farlo variare, ma aumentre il numero di transistor vuol dire usare un wafer di silicio più grande e sfornare quindi un processore più costoso!! :D

Quindi a parità di numero totale di transistor nel processore, più sono gli stadi della pipeline, e minore é il tempo di propagazione dei segnali nei singoli elementi della pipeline.

Questo é il motivo per cui il Pentium 4 ha una frequenza molto più elevata rispetto all'Athlon 64, infatti il P4 ha una pipeline a 31 stadi contro i 12 dell'athlon 64.

Aaah ora ci siamo! :D

Dimenticavo una cosa:

[/QUOTE=quarz]Se questi algoritmi falliscono la previsione, si avrà una cosiddetta "bolla", cioè stadi della pipeline vuoti.
A quel punto sarà necessario cancellare il contenuto dell'intera pipeline[/QUOTE]

Sono andato a ripescare un libro dei tempi dell'università, dove diceva (come effettivamente ricordavo :)) che in caso di fallimento del branch predictor, è necessario un trace back sulla pipeline fino ad arrivare allo stadio che permette la rettifica dell'errore. Più lunga è la pipeline, più lungo sarà di norma il traceback, con conseguente calo delle prestazioni.
Quindi non è necessario svuotare l'intera pipeline. Giusto per amore della precisione ;)

Ragazzi non vi scannate girando attorno alle cose però :O
HT, sfruttando la parallelizzazione dei processi, aumenta le prestazione dell'architettura Netburst, che comunque GIA' prevede l'ottimzzazione di 31 stadi di pipeline (grazie alla feature chiamata Hyper Pipelined Technology).
E' quindi SIA vero che HT "ottimizza" l'architettura Netburst, SIA che se non usi un processo multithread (o piu' processi che contemporaneamenterichiedono potenza di calcolo) l'HT non serve praticamente a nulla. Cmq è stato visto che in ambito general pupose l'HT veniva usato eccome...
Comunque, grazie all'architettura Netburst, Intel si è potuta permettere di allungare le pipeline e di conseguenza aumentare le frequenze di clock (e ora capito pure il perchè :D), ma alla fine non ha raggiunto i risultati sperati dal momento che le CPU fondevano (come ha detto giustamente vetrofragile).

In una pipeline più lunga, cioé con più stadi, ogni singolo stadio é PIU' PICCOLO in termini di circuiteria, cioé in termini di quantità di transistor...
perché il numero totale di transistor del processore non varia!! :D

Azz mi è venuta un'altra domanda:

ma se fosse così, a parità di transistor, non posso fare una pipe più corta ma con lo stesso numero di trasistor di una lunga? Così quelli "che avanzano" (eheheh :D) li uso per altro? :confused:

Azz mi è venuta un'altra domanda:

ma se fosse così, a parità di transistor, non posso fare una pipe più corta ma con lo stesso numero di trasistor di una lunga? Così quelli "che avanzano" (eheheh :D) li uso per altro? :confused:
sì che puoi, puoi fare tutto quello che vuoi, basta che poi tu faccia una CPU che funziona!! :D
Ma la domanda é: per "altro" cosa intendi? Una cache più ampia? Un altro core ottimizzato per esempio per le operazioni floating point? O che altro ancora?
:mbe:

Ma la domanda é: per "altro" cosa intendi? Una cache più ampia? Un altro core ottimizzato per esempio per le operazioni floating point? O che altro ancora?
:mbe:

Se lo sapessi probabilmente proverei a chiedere lavoro presso Intel o AMD :D
A parte gli scherzi, sono preparato sulle architetture, ma non sono un elettronico puro. Chiedevo apposta per saperne di più ;)

IA64 è un'architettura riservata ai server :rolleyes: ti aspettavi di vedere degli Itanium2 (dal costo non indifferente) sul mercato desktop :mbe: e quale sarebbe poi il vantaggio di AMD64 ed EM64T, io non lo sto ancora vedendo :asd:

le intenzioni originarie di intel erano di portare l'Itanium anke nei sistemi desktop...vana speranza...
i vantaggi di AMD 64 ci sono se usi sistemi operativo e prograami a 64 bit soprattutto per quanto riguarda l'encoding video e il rendering...quelle di emt64 molto meno onestamente :asd:

se non vado errando Intel ha introdotto i DUAL CORE prima di AMD e comunque HT era unsa tecnologia che mirava ad aumentare l'efficenza dell'architettura NetBurst più che a parallelizzare i processi :O

AMD ha progettato i K8 già con uno sguardo ai dual core da BEN prima che intel iniziasse a parlare di dual core..
infatti mentre i PD sono semplicemente due core attaccati con necessità di scambiarsi i dati tra le cache passando per l'FSB esterno, i dual core AMD hanno una soluzione molto piu' raffinata che permette di scambiarsi i dati tra le due cahce SENZA uscire dal chip per mezzo di una System Request Queue e di un Crossbar Switch.

beh fino all'introduzione del Athlon64 mi sembra proprio che la scelta Intel fosse migliore, il paragone tra Athlon XP e Pentium 4 non era proprio alla pari :rolleyes:

sbagliato.
Tra Athlon XP e willamette con SDRAM non c'era paragone... in media un XP andava come un P4 con 200 mhz in piu' del rating (ES. il mio XP 1600+ andava in media come un P4 1.8 con SDRAM).
Diciamo ke intel si è ripresa solo col northwood 800 dato che ancora con i 533 se la giocava con gli athlon xp....

ma che cosa stai dicendo? imitiamole... :doh: Intel ha iniziato con questa architettura ai tempi dell'introduzione di Centrino con il core Banias :O quindi diciamo che è nata prima dell'architettura K8 :muro:
non c'entra niente...
INTEL ha semplicemente portato avanti l'arkitettura dei P3 SOLO sui portatili, mentre AMD ha sempre portato avanti la sua arkitettura in tutti i campi.
Il K8 è un miglioramento del K7 ke però ne segue la filosofia generale.
Quindi mi pare corretto dire che intel in ambito desktop e server abbia cannato delle scelte tanto è vero ke si è trovata costretta a cestinare il progetto netburst (ke sarebbe dovuto arrivare ai 10ghz) in favore dell'arkitettura piu' efficiente evoluzione di quella del P3 (Un pò come il K8 è un evoluzione naturale del K7).

la gente parla di cose che non conosce, avesse visto come si progettano i processori altro che chiacchere da fan boy ...
con netburst intel aveva seriamente intenzione di bucare i 5 ghz , ma per problemi di calore dissipato dal processore conseguenti ai problemi legati all'introduzione del 90 nm hanno dovuto ridimensionare le attese e cercare altre vie per migliorare quello che già esisteva.
L'ht non è stato inventato per il pentium4 , ma applicandolo hanno visto che le performance in general porpouse venivano incrementate.
Per quanto riguarda la guerra dei fan boy .. va bhè che c'è da aggiungere?
In realtà già il prescott sarebbe dovuto arrivare a 5 ghz e tejas (poi bidonato) o il suo successore avrebbe dovuto sfondare i 10 ghz...
a posteriori sappiamo tutti come sono andate le cose in realtà....
Per quanto riguarda l'HT è l'approccio + natuarale da seguire con processori con pipeline lunghe e le cui unità di calcolo sono spesso e volentieri a girarsi i pollici...
infatti l'elaborazione di due thread simultanei non fa altro ke sfruttare piu' efficientemente le unità di calcolo del P4.

Azz mi è venuta un'altra domanda:

ma se fosse così, a parità di transistor, non posso fare una pipe più corta ma con lo stesso numero di trasistor di una lunga? Così quelli "che avanzano" (eheheh :D) li uso per altro? :confused:
:mbe:
non "avanzano" transitor da una pipeline....
I transitor necessari per le operazioni da compiere sono praticamente equivalenti.....
casomai in ogni stadio della pipeline lunga, dovendo svolgere operazioni + elementari, potrai mettere meno transistor...
ma i transistor di TUTTA la pipeline sono piu' o meno simili sia ke hai una pipeline corta che lunga.
i termini "corta" o "lunga" non indicano in alcun modo il numero di transistor totali della pipe, ma solo il numero di stadi utilizzati...

:mbe:
non "avanzano" transitor da una pipeline....
I transitor necessari per le operazioni da compiere sono praticamente equivalenti.....
casomai in ogni stadio della pipeline lunga, dovendo svolgere operazioni + elementari, potrai mettere meno transistor...
ma i transistor di TUTTA la pipeline sono piu' o meno simili sia ke hai una pipeline corta che lunga.
i termini "corta" o "lunga" non indicano in alcun modo il numero di transistor totali della pipe, ma solo il numero di stadi utilizzati...
questo l'avevamo già chiarito io e fidel, poi lui ha posto questa domanda così, tanto per fare un'ipotesi... :D

Cioé tu prendi un'architettura, chessò, x86 a 100 milioni di transistor con una pipeline a 20 stadi.
Di questi 100 milioni di transistor, 60 sono usati per la pipeline e 30 per tutto il resto (cache eccetera).
Facendo una rapida divisione, 60/20=3, vuol dire che ogni stadio della pipeline ha 3 milioni di transistor.
A questo punto decidi che fai diventare la pipeline a 10 stadi facendo rimanere 3 milioni il numero di transistor per ogni stadio.
Ti avanzano 3*10=30 milioni di transistor (usando un wafer di silicio delle stesse dimensioni).
La sua domanda era: quei 30 milioni di transistor posso usarli x fare qualcos'altro?

Io comincerei col dire che innanzitutto le prestazioni con cui vengono eseguiti i processi sulla pipeline principale calerebbero di brutto (ovvio), secondariamente dico che quei 30 milioni di transistor, essendo ALTRO rispetto alla pipeline, probabilmente potrebbero essere utilizzati o per ampliare la cache on-die, oppure per mettere on-die un altro core, o con la stessa architettura o con un'architettura diversa... ad esempio una sorta di dsp ottimizzato per il calcolo floating point...
ma non so fino a che punto avrebbe senso stravolgere l'architettura di un processore in questo modo... tanto vale riprogettarlo da zero... :D

:mbe:
non "avanzano" transitor da una pipeline....
I transitor necessari per le operazioni da compiere sono praticamente equivalenti.....
casomai in ogni stadio della pipeline lunga, dovendo svolgere operazioni + elementari, potrai mettere meno transistor...
ma i transistor di TUTTA la pipeline sono piu' o meno simili sia ke hai una pipeline corta che lunga.
i termini "corta" o "lunga" non indicano in alcun modo il numero di transistor totali della pipe, ma solo il numero di stadi utilizzati...

Sì in effetti dovresti rileggere i post precedenti :)

La domanda a questo punto resta: PERCHE' una pipe più lunga permette frequenze di clock più elevate, se ogni stadio di pipeline ha pressoché lo stesso numero di transistor sia che essa abbia più stadi o meno, e quindi i tempi di propagazione sono gli stessi?

questo l'avevamo già chiarito io e fidel, poi lui ha posto questa domanda così, tanto per fare un'ipotesi... :D

Cioé tu prendi un'architettura, chessò, x86 a 100 milioni di transistor con una pipeline a 20 stadi.
Di questi 100 milioni di transistor, 60 sono usati per la pipeline e 30 per tutto il resto (cache eccetera).
Facendo una rapida divisione, 60/20=3, vuol dire che ogni stadio della pipeline ha 3 milioni di transistor.
A questo punto decidi che fai diventare la pipeline a 10 stadi facendo rimanere 3 milioni il numero di transistor per ogni stadio.
Ti avanzano 3*10=30 milioni di transistor (usando un wafer di silicio delle stesse dimensioni).
La sua domanda era: quei 30 milioni di transistor posso usarli x fare qualcos'altro?

Io comincerei col dire che innanzitutto le prestazioni con cui vengono eseguiti i processi sulla pipeline principale calerebbero di brutto (ovvio), secondariamente dico che quei 30 milioni di transistor, essendo ALTRO rispetto alla pipeline, probabilmente potrebbero essere utilizzati o per ampliare la cache on-die, oppure per mettere on-die un altro core, o con la stessa architettura o con un'architettura diversa... ad esempio una sorta di dsp ottimizzato per il calcolo floating point...
ma non so fino a che punto avrebbe senso stravolgere l'architettura di un processore in questo modo... tanto vale riprogettarlo da zero... :D
appunto...
è sbagliato il ragionamento di fondo...
se per una pipeline a 20 stadi avrai bisogno di 3 milioni di transistor per ogni stadio, per una pipeline a 10 stadi avrai bisogno di circa 6 milioni di transitor ad ogni stadio..
quindi alla fine i transistor utilizzati nella pipeline sono sempre uguali sia con la pipe corta che con quella lunga...

Sì in effetti dovresti rileggere i post precedenti :)

La domanda a questo punto resta: PERCHE' una pipe più lunga permette frequenze di clock più elevate, se ogni stadio di pipeline ha pressoché lo stesso numero di transistor sia che essa abbia più stadi o meno, e quindi i tempi di propagazione sono gli stessi?
appunto..
una pipeline lunga permette frequenze piu' elevate perchè ogni stadio necessita di un numero minore di transistor dovendo fare operazioni piu' semplici di uno stadio di una pipeline corta che necessità di piu' transistor.

appunto..
una pipeline lunga permette frequenze piu' elevate perchè ogni stadio necessita di un numero minore di transistor dovendo fare operazioni piu' semplici di uno stadio di una pipeline corta che necessità di piu' transistor.

Ok ora ho capito ;) Il fatto è che non mi risultava che una pipe più corta dovesse fare operazioni più complesse ad ogni stadio rispetto ad una più lunga, da qui la necessità di usare più transistor ad ogni stadio di una pipe corta.

perfetto ;)

Frena frena frena... tutte le innovazioni tecnologiche, per svariati motivi, vengono sempre introdotte PRIMA nelle soluzioni hardware high-end, cioé nel caso di Intel e AMD parlamo di server e workstation di fascia alta.
Sia IA64 che x86-64 sono state introdotte sul mercato su processori di fascia alta, rispettivamente Itanium e Opteron, solo che IA64 non ha avuto successo e quindi non é stata portata sui desktop, mentre x86-64 ha avuto successo eccome E PERCIO' é stata portata sui procesori di fascia desktop.
Non rimescoliamo le carte... ;)
Limitandosi al confronto fra le soluzioni server, l'Opteron ha avuto molto più successo dell'Itanium...

mamma mia...
allora IBM (Power5) e SUN (Ultra SPARC4) hanno fallito con le loro architetture simil Itanium perché non le hanno portate sui desktop :muro:
non tutto nasce per essere immesso sul mercato desktop, nello specifico Itanium (1 prima e 2 dopo) ha prestazioni general purpose non degne di nota, questa CPU è adatta al calcolo matematico e poco altro ed è quello il motivo per cui è nata (e poi la IA64 nulla a che vedere con X86 ne tantomeno con X86-64 e non è minimamente paragonabile).



forse tu usi Windows che é ancora a 32 bit? ;)
Comunque l'architettura K8 é ha 64 bit ma ha 1 riprogettazione intelligente in funzione di quello, che le permette di avere vantaggi notevoli anche nell'esecuzione di processi a 32 bit.
Mentre invece l'EMT64 é stato aggiunto ai Pentium solo come "una pezza" per stare dietro ad AMD, quindi sui processi a 32 bit non ha vantaggi prestazionali apprezzabili...

ovvio che uso Windows e Linux a 32bit, non dispongo di processori a 64bit, sai faccio upgrade del ogni 5/6 anni e l'ultima volta ho preso un P3 ;) (ora con qualche € meno di 100 per l'esattezza ho preso mobo e memorie ed ho omontato un vecchio P4 [email protected])
concordo con te che comunque l'implementazione dei 64bit Intel è "penosa" ed è una pezza, tuttavia da 3 anni a questa parte non si sono ancora visti i vantaggi dei 64bit, questo lo dovrai ammettere (con un Windows XP x64 disponibile in versione OEM e basta c'è poco da vedere) :(


vai errando in senso stretto perché AMD é uscita poco prima, ma soprattutto vai errando in senso lato perché i Dual-core AMD sono stati fin da subito accessibili da un'utenza molto più vasta degli intel, vista la differenza di costo iniziale.
E il dual core AMD é stato lanciato praticamente in contemporanea anche sulle soluzioni server con Opteron.
Se a ciò aggiungi che mentre AMD ha fatto i dual-core su un wafer unico, come si deve, ottimizzando i consumi, mentre Intel ha messo 2 wafer sullo stesso connettore, si osserva come Intel abbia lanciato i suoi dual core in contempoaranea con AMD giusto per poter dire "li abbiam fatti anche noi", ma la soluzione Intel inizialmente era MOLTO meno fruibile, anche in questo caso fatta per star dietro ad AMD che era in vantaggio sul tempo... :D

molto probabile che mi sbagli, ma comunque è questione di giorni e non di mesi ;) comunque tu sbagli sui prezzi perché da subito le CPU DC Intel hanno avuto un prezzo inferiore agli AMD (ora invece stanno ad un livello simile) ;)
per quanto riguarda il Core, i Pentium D 8xx e il Pentium XE 8xx avevano due core sullo stesso "pezzo" di silicio, mentre solo con la serie 9xx i core sono stati separati per permettere una maggior flessibilità delle linee produttive in favore dei costi.
(per la cronaca i Core Duo posseggono due CORE sullo stesso "pezzo" di silicio)


si ma il momento in cui AMD ha superato Intel mantenendo un'architettura con un numero ragionevole di stadi nella pipeline, é stato con l'introduzione dell'architettura K7.
La NetBurst di Intel é uscita dopo col P4 per cercare di recuperare, ma senza successo...
NetBurst ha "tenuto" sul piano delle vendite facendo leva sulla "pecoraggine" degli acquirenti che guardano il numero di MHz senza sapere cosa significa, ma non ha recuperato dal punto di vista tecnologico.

Quindi adesso Intel se torna ad un'architettura di QUELLA concezione, con molti meno stadi nella pipeline, deve rincorrere anche il K7, perché la migliore architettura mai avuta per le mani da Intel con QUEL tipo di pipeline era quella del Pentium3, che era inferiore all'architettura del K7.

Poi ripeto: magari il Conroe sarà meglio dei processori AMD, ma in tal caso questo significherà semplicemente che la "rincorsa" di Intel sarà riuscita!! ;)


PS: il K7 é uscito quasi 4 anni prima del Banias, per la precisione 3 anni e 9 mesi prima.
sono con te quando dici che l'architettura NetBurst non era corretta ma bisognava continuare con l'architettura P6+ (Pentium III) però per un certo momento ha avuto i sui vantaggi ;)
comunque non mi sento di dire che nel suo ritorno agli albori (P6+) Intel stiamo imitando AMD ne tantomeno che debba recuperare dato che la base di cui dispone (core Dothan, ora Yonah) è quantomeno alla pari con AMD nella maggior parte dei campi di utilizzo :O

Vorrei sapere perchè la gente continua a sperare che su una CPU come questa venga supportato l'HT... guardando i bench, al momento già è difficile sfruttare due core e sulle CPU dualcore che hanno l'HT si vedono solo skazzi del SO (con addirittura cali di prestazioni).
Oltre a questo, ovviametne stiamo ancora aspettando, in ambito Home user dei software veramente ottimizzati per i dualcore perchè è impossibile pretendere che l'HT (o i dualcore) abbiano giovamenti in programmi non ottimizzati per il multithreading e di conseguenza, gli unici ambiti in cui si traggono giovamenti, sono il multitasking.
Io smetterei quindi di dire che l'HT serve ad ottimizzare l'uso delle pipe lunghe perchè senza software adatto, l'unico vantaggio che si ha, lo si ha nel multitasking.
Questo però và anche ridimensionato perchè al giorno d'oggi, solo nei bench delle recensioni non si fà uso di multitasking sul PC e solo per questo un P4 HT può essere ancora paragonato ad un Athlon XP e ci si può permettere di dire che reggevano il confronto perchè, nella realtà, fare partire due applicazioni contemporaneamente, significava vedere crollare gli XP (e ancora adesso con gli A64).
Per quanto mi riguarda, sebbene AMD abbia progettato molto prima i dualcore (ovvero gli A64 sono usciti con in progetto la funzione di dualcore... ad esempio già sugli A64 singlecore era presente il SRQ... inutilizzato ma c'era)... ormai si stà "fossilizzando".
Effettivamente c'è da dire che sulle estensioni a 64bit è in vantaggio... ma è proprio questo che c'è di innovativo nei Merom, il fatto che dovrebbero essere una 64bit nativa (anzichè lo Yonah o i Conroe) e, a quanto pare, ormai in casa Intel hanno abbandonato l'idea di usare l'ambito server come segmento top per introdurre le innovazoioni e sia passato all'ambito Notebook per sfornare i prodotti più evoluti.
Io non capisco poi a cosa serva dire chi rincorre chi: Intel con la Netburst ha avuto il suo momento di superiorità... e manco troppo breve... e ancora adesso in svariati ambiti non la si può certo considerare fallimentare (se non per i consumi).
Di sicuro, nelle varie case a livello di progettazione sono molto più avanti di quanto si sappia per cui, dire cosa è uscito prima è assolutamente ridicolo: magari Intel o AMd hanno sfornato un certo prodotto solo dopo averlo tenuto nel cassetto per anni.

tuttavia da 3 anni a questa parte non si sono ancora visti i vantaggi dei 64bit, questo lo dovrai ammettere (con un Windows XP x64 disponibile in versione OEM e basta c'è poco da vedere) :(

Con XP 64 non saprei, io ho provato linux con kernel a 64 bit e i miglioramenti li ho visti in ambito videostreaming (per ovvii motivi), poi non ho potuto fare test più approfonditi in ambito general purpose. Per quello che ho potuto provare, miglioramenti generali non ne ho visti. D'altro canto, a volte l'architettura 64 bit porta svantaggi sugli algoritmi di calcolo, che farebbero volentieri a meno dell'allineamento dei puntatori in memoria sui 64 bit. Magari bisogna aspettare ancora un po' per vedere miglioramenti (se ce ne saranno)? La possibilità però di superare il limite dei 4 giga di memoria sta diventando sempre più allettante, visto anche il cerescente aumento delle risorse richieste dalle applicazioni anche non di fascia server.
Sarà un caso, ma proprio ieri dovevo masterizzare un file di 4,2 giga e K3b mi ha detto "Impossibile masterizzare files più grandi di 4 Gigabytes" :mc: Non so se questo limite sia superabile però, non mi intendo a livello programmativo della masterizzazione.

Io smetterei quindi di dire che l'HT serve ad ottimizzare l'uso delle pipe lunghe perchè senza software adatto, l'unico vantaggio che si ha, lo si ha nel multitasking.

Evidentemente non hai letto i post precedenti. Per quanto mi riguarda, ho proprio affermato che il multitasking e il multithreading nella tecnologia HT va ad ottimizzare l'uso della pipe più lunga.
Va da sè che senza multitasking/multithreading, i miglioramenti della tecnologia HT non esistono. Meglio leggere prima di postare :rolleyes:
Per il resto quoto quasi tutto :)

appunto...
è sbagliato il ragionamento di fondo...
se per una pipeline a 20 stadi avrai bisogno di 3 milioni di transistor per ogni stadio, per una pipeline a 10 stadi avrai bisogno di circa 6 milioni di transitor ad ogni stadio..
quindi alla fine i transistor utilizzati nella pipeline sono sempre uguali sia con la pipe corta che con quella lunga...
eh, dipende... in linea di massima sì... se vuoi mantenere un processore che abbia un'architettura dalla complessità paragonabile...
ma se ti accontenti di un'architettura molto meno evoluta, puoi diminure il numero di stadi della pipeline lasciando invariato il numero di transistor per ogni stadio.
Ovviamente l'architettura cambia diventando meno complessa, quindi gli stadi della pipeline pur mantenendo lo stesso numero di transistor non saranno UGUALI ai precedenti, perché con la metà dei transistor totali devono svolgere gli stessi compiti...
Infatti se noti ho scritto che in questa ipotesi, sulla pipeline ci sarebbe un calo pesante di prestazioni nell'esecuzione dei processi, proprio perché si avrebbe un'involuzione dell'architettura... :D

Ovviamente siamo nel campo delle ipotesi eh...
era per rispondere alla domanda di fidel!!


PS: per fare un esempio, il Pentium MMX aveva 4,5 milioni di transistor, mentre il primo Pentium 3 (core Katmai a 250nm) aveva 9,5 milioni di transistor.
Cioé: puoi ridurre il numero totale di transistor, ovviamente TORNANDO ad un'architettura molto meno evoluta :D
(e poi per la domanda di fidel, coi transistor che ti avanzano puoi fare altre cose) :D

mamma mia...
...dammi 100 lire che in America voglio andaaaaaaaaaar! :D



allora IBM (Power5) e SUN (Ultra SPARC4) hanno fallito con le loro architetture simil Itanium perché non le hanno portate sui desktop :muro:
non tutto nasce per essere immesso sul mercato desktop, nello specifico Itanium (1 prima e 2 dopo) ha prestazioni general purpose non degne di nota, questa CPU è adatta al calcolo matematico e poco altro ed è quello il motivo per cui è nata (e poi la IA64 nulla a che vedere con X86 ne tantomeno con X86-64 e non è minimamente paragonabile).
1) allora innanzitutto sta di fatto che Intel aveva intenzione di portare IA64 anche sui desktop ma ha dovuto abbandonare il progetto. Poi é ovvio che non tutte le soluzioni server vengono portate su desktop, ma nelle intenzioni di Intel, IA64 doveva esserlo, infatti dentro Itanium inizialmente era incluso un "emulatore" hardware per le istruzioni a 32 bit.
2) Dici che IA64 non é neanche lontanamente paragonabile a x86-64: dal punto di vista tecnico e architetturale certo che non lo é, ma nel campo delle prestazioni nel medesimo ambito applicativo (in parole povere, sul mercato), i fatti parlano chiaro: Opteron ha avuto la meglio...
(e infatti io li stavo paragonando da QUEL punto di vista, cioé quello dei risultati, é ovvio che le architetture siano MOLTO diverse... ;) )



ovvio che uso Windows e Linux a 32bit, non dispongo di processori a 64bit, sai faccio upgrade del ogni 5/6 anni e l'ultima volta ho preso un P3 ;) (ora con qualche € meno di 100 per l'esattezza ho preso mobo e memorie ed ho omontato un vecchio P4 [email protected])
ti capisco, anch'io cambio il mio hardware di rado, purtroppo i soldi non crescono sugli alberi :D



concordo con te che comunque l'implementazione dei 64bit Intel è "penosa" ed è una pezza, tuttavia da 3 anni a questa parte non si sono ancora visti i vantaggi dei 64bit, questo lo dovrai ammettere (con un Windows XP x64 disponibile in versione OEM e basta c'è poco da vedere) :(
x quanto riguarda windows: anche con windows a 32bit ci sono stati notevoli vantaggi nel passaggio dall'architettura AMD K7 all'architettura AMD K8, proprio per i motivi che dicevo prima... certo che avendo un Intel, passando da un P4 senza EMT64 a un P4 con EMT64, di differenza non se ne vede manco l'ombra... :D
Ad ogni modo, x chi usa linux, c'é a 64 bit già da MOOOOLTO tempo, ed é perfettamente uguale a quello a 32 bit (stesse applicazioni ecc), non come Windows 64bit che ha il problema della compatibilità delle applicazioni...



molto probabile che mi sbagli, ma comunque è questione di giorni e non di mesi ;) comunque tu sbagli sui prezzi perché da subito le CPU DC Intel hanno avuto un prezzo inferiore agli AMD (ora invece stanno ad un livello simile) ;)
per quanto riguarda il Core, i Pentium D 8xx e il Pentium XE 8xx avevano due core sullo stesso "pezzo" di silicio, mentre solo con la serie 9xx i core sono stati separati per permettere una maggior flessibilità delle linee produttive in favore dei costi.
(per la cronaca i Core Duo posseggono due CORE sullo stesso "pezzo" di silicio)
Si ma come ti diceva qulacun altro nel thread, al di là che i 2 "quadratini" di silicio siano uniti o divisi, rimane la questione che ti ha detto prima anche tigershark, cioé (lo quoto così facciam prima :D ):
mentre i PD sono semplicemente due core attaccati con necessità di scambiarsi i dati tra le cache passando per l'FSB esterno, i dual core AMD hanno una soluzione molto piu' raffinata che permette di scambiarsi i dati tra le due cahce SENZA uscire dal chip per mezzo di una System Request Queue e di un Crossbar Switch.
ripeto, questo indipendentemente che i 2 "quadratini" di silicio sui processori intel siano attaccati o divisi.



sono con te quando dici che l'architettura NetBurst non era corretta ma bisognava continuare con l'architettura P6+ (Pentium III) però per un certo momento ha avuto i sui vantaggi ;)
non dico che "bisognava", osservo semplicemente che in quel momento Intel era molto in difficoltà nei confronti di AMD, e non ha saputo far di meglio che tirare fuori dal cappello l'architettura NetBurst, che doveva, nelle sue previsioni:
1) inizialmente "tenere" sul piano delle vendite grazie alla pubblicità che deriva dall'alto numero di MHz (quindi grazie a un "falso" vantaggio prestazionale)
2) alla lunga superare e distaccare gli AMD grazie all'aumento vertigionoso dei MHz (quindi grazie a un "vero" vantaggio prestazionale)
Obiettivo 1 raggiunto, obiettivo 2 cannato in pieno, quindi per non farsi travolgere da AMD stanno correndo ai ripari. :D



comunque non mi sento di dire che nel suo ritorno agli albori (P6+) Intel stiamo imitando AMD ne tantomeno che debba recuperare dato che la base di cui dispone (core Dothan, ora Yonah) è quantomeno alla pari con AMD nella maggior parte dei campi di utilizzo :O
insomma... :mbe:

x quanto riguarda windows: anche con windows a 32bit ci sono stati notevoli vantaggi nel passaggio dall'architettura AMD K7 all'architettura AMD K8, proprio per i motivi che dicevo prima... certo che avendo un Intel, passando da un P4 senza EMT64 a un P4 con EMT64, di differenza non se ne vede manco l'ombra... :D
Ad ogni modo, x chi usa linux, c'é a 64 bit già da MOOOOLTO tempo, ed é perfettamente uguale a quello a 32 bit (stesse applicazioni ecc), non come Windows 64bit che ha il problema della compatibilità delle applicazioni...

Come ho scritto nel precedent post, almeno usando linux, grandi incrementi di prestazioni non ne ho visti. Ribadisco (al massimo rileggere il mio precedente post :)) sulle (non moltissime) prove che ho avuto modo di fare, ho avuto miglioramenti nel video streaming, ma non ho apprezzato miglioramenti sostanziali dall'uso dei 64 bit. Almeno io non me ne sono accorto.
Hai dei bench seri effettuati da terzi in proposito?

...
ti capisco, anch'io cambio il mio hardware di rado, purtroppo i soldi non crescono sugli alberi :D

già...ma tra poco arriverà il notebook (causa progetti universitari) ;)


x quanto riguarda windows: anche con windows a 32bit ci sono stati notevoli vantaggi nel passaggio dall'architettura AMD K7 all'architettura AMD K8, proprio per i motivi che dicevo prima... certo che avendo un Intel, passando da un P4 senza EMT64 a un P4 con EMT64, di differenza non se ne vede manco l'ombra... :D
Ad ogni modo, x chi usa linux, c'é a 64 bit già da MOOOOLTO tempo, ed é perfettamente uguale a quello a 32 bit (stesse applicazioni ecc), non come Windows 64bit che ha il problema della compatibilità delle applicazioni...

un momento...
se si usa Windows XP x32 i vantaggi dal K7 al K8 sono tutti dovuti al miglioramento architetturale e non hai 64bit, infatti utilizzando un compilatore assembly con annesso debugger i registri della CPU vengono visti a 32bit ;)
con Windows XP x64 concordo con te che con AMD64 ci sono più vantaggi che con EM64T (che è a mio modo di vedere male implementata) :)
comunque le distro Linux 64bit sono ancora un po' acerbe e non c'è molto software!!!


Si ma come ti diceva qulacun altro nel thread, al di là che i 2 "quadratini" di silicio siano uniti o divisi, rimane la questione che ti ha detto prima anche tigershark, cioé (lo quoto così facciam prima :D ):

ripeto, questo indipendentemente che i 2 "quadratini" di silicio sui processori intel siano attaccati o divisi.

vero ;) semplicemente perché quando si è trattato di introdurre i DUAL CORE in Intel si era già deciso che NetBurst sarebbe morta di li a breve e che qualsiasi sviluppo successivo sarebbe solo stato uno spreco.


non dico che "bisognava", osservo semplicemente che in quel momento Intel era molto in difficoltà nei confronti di AMD, e non ha saputo far di meglio che tirare fuori dal cappello l'architettura NetBurst, che doveva, nelle sue previsioni:
1) inizialmente "tenere" sul piano delle vendite grazie alla pubblicità che deriva dall'alto numero di MHz (quindi grazie a un "falso" vantaggio prestazionale)
2) alla lunga superare e distaccare gli AMD grazie all'aumento vertigionoso dei MHz (quindi grazie a un "vero" vantaggio prestazionale)
Obiettivo 1 raggiunto, obiettivo 2 cannato in pieno, quindi per non farsi travolgere da AMD stanno correndo ai ripari. :D

obiettivo 1 raggiunto in pieno direi ;) il 2 è stato raggiunto per un certo periodo e ciò è a mio modo di vedere innegabile :O quando sono apparsi i Northwood C i Pentium 4 dominavano il mercato :O

comunque sono solo felice di questo "ritorno al passato" di Intel :O

Come ho scritto nel precedent post, almeno usando linux, grandi incrementi di prestazioni non ne ho visti. Ribadisco (al massimo rileggere il mio precedente post :)) sulle (non moltissime) prove che ho avuto modo di fare, ho avuto miglioramenti nel video streaming, ma non ho apprezzato miglioramenti sostanziali dall'uso dei 64 bit. Almeno io non me ne sono accorto.
Hai dei bench seri effettuati da terzi in proposito?
no non ho "bench seri effettuati in proprosito", d'altra parte bench su linux non saprei così su 2 piedi dove andarli a trovare.

Comunque, io non ho mica capito se hai fatto 'sti test con una CPU Intel o AMD, ma io ho provato a vedere linux x32 e linux x64 sulla stessa macchina, AMD Athlon 64, e l'aumento di prestazioni si vede.

Poi benchmark non ne ho... io non sono un grande appassionato di benchmark... e se trovo un benchmark in giro leggendo 1 articolo, di certo non sono quello che si tiene il bookmark per usarlo come argomento nei forum!!!
:D

già...ma tra poco arriverà il notebook (causa progetti universitari) ;)


un momento...
se si usa Windows XP x32 i vantaggi dal K7 al K8 sono tutti dovuti al miglioramento architetturale e non hai 64bit, infatti utilizzando un compilatore assembly con annesso debugger i registri della CPU vengono visti a 32bit ;)
Ma come fai a separare, da questo punto di vista, il "miglioramento architetturale" dai "64 bit"? ;)
E' la stessa cosa...
Cioé: tu devi progettare una CPU che supporti 32 e 64 bit, qui gli approcci possibili sono molteplici:
==> AMD x86-64: fare un'architettura sfruttabilile in maniera ottimale sia a 32bit che a 64 bit, in questo modo anche facendo girare applicazioni a 32 bit si hanno miglioramenti rispetto alla vecchia architettura
==> Intel x86-32+EMT64: classica architettura a 32 bit con "appeso" il supporto a 64 bit, risultato: a 32 bit é uguale, e i 64 bit non sono ben sfruttati
==> Intel IA64 (itanium) con "appesa" emulazione hardware x86-32: prestazioni ottimali a 64 bit (sulla carta migliori di x86-64, nella realtà soltanto forse in alcuni ambiti :D ), prestazioni ridicole a 32 bit.

Sono diversi approcci, ma non é che puoi separare le 2 cose... é come dire che le prestazioni del motore di una macchina sono dovute al numero dei cilindri e non alla cilindrata totale!! :D



con Windows XP x64 concordo con te che con AMD64 ci sono più vantaggi che con EM64T (che è a mio modo di vedere male implementata) :)
comunque le distro Linux 64bit sono ancora un po' acerbe e non c'è molto software!!!
Non capisco a che ti riferisci...
Le distro Linux a 64 bit sono le stesse che vedi a 32 bit, soltanto ricompilate a 64bit, quindi le applicazioni sono le stesse, perché la quasi totalità del software linux é open-source!! :D



vero ;) semplicemente perché quando si è trattato di introdurre i DUAL CORE in Intel si era già deciso che NetBurst sarebbe morta di li a breve e che qualsiasi sviluppo successivo sarebbe solo stato uno spreco.
ah certo, questo può anche darsi, non lo metto in dubbio, ma il discorso che facevo io é semplicemente che il dual-core Intel é molto meno raffinato di quello AMD!! :D



obiettivo 1 raggiunto in pieno direi ;)
ah su questo siam d'accordo!! ;)



il 2 è stato raggiunto per un certo periodo e ciò è a mio modo di vedere innegabile :O quando sono apparsi i Northwood C i Pentium 4 dominavano il mercato :O
C'é stato un momento in cui i Pentium 4 prestazionalmente, si sono avvicinati agli Athlon ma poi sono stati ridistaccati perché Intel ha incontrato le difficoltà tecniche che dicevo prima nel salire di MHz, ma il motivo per cui "dominavano il mercato" come dici tu, é lo stesso del punto 1...
:D



comunque sono solo felice di questo "ritorno al passato" di Intel :O
mi verebbe da dire:
"anche a me, perché se si ravviva la concorrenza per noi utenti é sempre un bene"
ma purtroppo si osserva empiricamente (!! ;) ) che per motivi "inspegabili", Intel abbia lo stesso in pugno tutt'ora una quota di mercato che é un multiplo di quella di AMD!! :D
Quindi se Intel recupera terreno, più che ravvivarsi la concorrenza ricomincia ad andare in coma... :D

no non ho "bench seri effettuati in proprosito", d'altra parte bench su linux non saprei così su 2 piedi dove andarli a trovare.

Nono dicevo bench in generale, non solo per linux ;)

Comunque, io non ho mica capito se hai fatto 'sti test con una CPU Intel o AMD, ma io ho provato a vedere linux x32 e linux x64 sulla stessa macchina, AMD Athlon 64, e l'aumento di prestazioni si vede.

Provato su un Amd Athlon 64, installato sia linux 32 sia 64. Usato qualche giorno ;) Si i miglioramenti c'erano, ma non in general purpose. Sostanziali in videostreaming, nell'uso quotidiano non me ne sarei accorto se non avessi saputo che c'era installata la versione 64 bit. Ah, tutto questo è pura impressione personale, non ho fatto alcun test di prestazioni (tipo tempo avvio programmi ecc.). Però siamo sulla buona strada :D

:mbe:
non "avanzano" transitor da una pipeline....
I transitor necessari per le operazioni da compiere sono praticamente equivalenti.....
casomai in ogni stadio della pipeline lunga, dovendo svolgere operazioni + elementari, potrai mettere meno transistor...
ma i transistor di TUTTA la pipeline sono piu' o meno simili sia ke hai una pipeline corta che lunga.
i termini "corta" o "lunga" non indicano in alcun modo il numero di transistor totali della pipe, ma solo il numero di stadi utilizzati...

Insomma.. non è proprio così: a parte il fatto che architetture come quella del P4 e degli Athlon (e PIII) non sono confrontabili in maniera diretta (perchè nonostante siano entrambi processori X86 le differenze architetturali sono notevoli, basti pensare alle differenze tra la cache L1 degli Athlon e la trace cache dei P4, che sposta lo stadio di decodifica a monte delle pipeline, al diverso execution core, all'hyperthreading, ecc.) normalmente anche gli stadi in più servono a fare svolgere al singolo stadio meno lavoro, la circuiteria di controllo e di sincronizzazione della pipeline cresce all'aumentare del numero degli stadi, per cui è molto più probabile che pipeline più lunghe portino all'aumento del numero dei transistor totali che non delle pipeline più corte (a parità di "lavoro teorico totale" su tutti gli stadi, cosa che non ha poi un gran senso in realtà). tra l'altro nei P4 ci sono almeno 2 stadi di pipeline detti di "drive", che praticamente non svolgono nessun lavoro se non quello di trasmettere il segnale allo stadio successivo ;)

Nono dicevo bench in generale, non solo per linux ;)
eh ma "bench in generale", se vuoi testare il vantaggio dei 64 bit, Windows a 32 bit non va bene, quindi o li fai su Windows a 64 bit oppure su linux a 64 bit.
Siccome Windows a 64bit é ancora poco supportato non credo ci siano in giro molti benchmark, quindi bisogna "accontentarsi" di quelli su linux... :D



Provato su un Amd Athlon 64, installato sia linux 32 sia 64. Usato qualche giorno ;) Si i miglioramenti c'erano, ma non in general purpose. Sostanziali in videostreaming, nell'uso quotidiano non me ne sarei accorto se non avessi saputo che c'era installata la versione 64 bit. Ah, tutto questo è pura impressione personale, non ho fatto alcun test di prestazioni (tipo tempo avvio programmi ecc.). Però siamo sulla buona strada :D
ah vabbé...
cmq dipende anche cosa intendi per "uso quotidiano", perché se intendi la lettura della posta elettronica, lì il collo di bottiglia é l'hard disk, cioé voglio dire in quanto a elaborazione dati é ovvio che non vedi differenze sostanziali tra cpu di ultima generazione e cpu di 2/3 anni fa... indipendentemente dal fatto che siano a 32 o a 64 bit. :D