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

Il processore che segnerà l'addio all'architettura NetBurst sarà pin-to-pin compatibile con Yonah

Click sul link per visualizzare la notizia.

Troppo facile...dopo avere venduto una quantità "enorme" di processori con architettura "NetBurst" dire che adesso si è "pronti a salutarla"...
La NetBurst non doveva nemmeno comparire al di fuori dei laboratori di ricerca...
Troppo elefantiaca e con i primi due nuclei Willamette e Northwood privi di
barrel shifter per le operazioni di rotazione di bit "logiche" ecc.
Le A.L.U a doppia frequenza rispetto al nucleo "centrale" del processore poi sono dovute solo a "ritardi tecnologici" che nè hanno richiesto l'utilizzo: anche in virtù della mancanza di cui sopra e per avere un numero di cicli di clock per le istruzioni "intere" comparabile a quelle della architettura Pentium III.
Questo è detto da un possessore di sistemi basati su Pentium 4 a malinquore, sigh.
Quando il marketing prende il sopravvento sulla scienza e sulla tecnica/tecnologia questi sono i risultati.
Grazie.

Marco71.

NetBurst secondo me è venuta fuori da una necessità... Si aspettavano che il P3 scalasse meglio in frequenza a 0.18 micron e avesse rese migliori a 0.13 micron (il Tualatin non ha potuto rese molto scarse)...e quando AMD ha invaso il mercato con i ThunderBird fino a 1333 non avevano un progetto pronto migliore di NetBurst...

Quindi si avrà una maggior efficienza a parità di frequenza?
E anche minori consumi?

Giusto?

Beh dai, i Northwood (particolarmente gli 800MHz) sono stati comunque i processori + potenti presenti sul mercato al tempo.
Ciao.

Finalmente Intel getta uno sguardo su risparmio energetico ed efficienza.
In pratica AMD e Intel torneranno alla pari su questi due importanti fattori, chi la spunterà dei due lo farà probabilmente in modo poco evidente.
Visto che Intel è riuscita a stravendere cmq con quel cesso di architettura netburts, dai consumi energetici paurosi, almeno adesso un beneficio sicuramente ci sarà.
Intel ha sempre venduto e venderà sempre tantovale che lo faccia facendoci risparmiare energia.

Quindi si saluta anche Hyper Threading?

con le pipeline così corte l'Hyper Threading non sarà utilizzato...

Quindi si saluta anche Hyper Threading?
Abbassando gli stadi di pipeline, e con il dual core, non ce n'è minimamente bisogno

Beh dai, i Northwood (particolarmente gli 800MHz) sono stati comunque i processori + potenti presenti sul mercato al tempo.
Ciao.
Senza dubbio...

Sarà che Intel - numeri alla mano - di fatto è leader del settore, ma il fatto che un leader di questo calibro, si sia schiantata pesantemente con i Prescott contro la barriera dei 90 nm, abbia tecnicamente fallito nel prodotto del Tualatin - Tualatin che secondo me è stato ucciso volontariamente in favore del P4 e per resuscitarlo poi come Banjas-Centrino - Parlando da power-user, mi ha scocciato parecchio vedere la scomparsa prematura del Tualatin, in favore di un prodotto del marketing come è tuttora il P4, con frequenze da capogiro, e consumi altrettanto inequivocabili.
Ora che il marketing è rimasto senza frutti nel campo del Netburst, che è rimasto inchiodato ai 3,6-3,8 GHz senza essere riuscito a sfondare la soglia psicologica del 4000 (cosa che invece AMD sta facendo, senza inventare numeri di serie indecifrabili), si esce con questo "passo indietro" sulle frequenze, che però ricalca un passaggio di consegne che ha le radici del Coppermine e Tualatin...
E se l'HT verrà dismesso, ben venga, preferisco un vero nucleo solo, o due veri nuclei, che non uno vero che finge di lavorare per due!
In ultimo, la mia convinzione che le L1 che dialogano e la L2 condivisa non mi sembrano delle genialate, sembra quasi un voler risparmiare su qualcosa... ma su questo dettaglio non commento, diversamente da Marco71, non ritengo di saper dare un parere informato... :)

be' 14 stadi di pipeline sono sicuramente peggio di 12 se si segue la "via" del Netburst......sono sicuro che con tecniche di predizione azzeccate le prestazioni globali siano migliori....ora la risposta ad AMD ke deve fare altri passi in avanti (spero)

Mi chiedo spesso (e se qualcuno puo dire qualcosa lo dica) perchè Intel inserisce cache di secondo livello unificata fino 4mb (o nella maggioranza dei casi cache da 1 mb) facendola pagare una cifra!!

Ma non possono metterne una da 16mb!!???"""

Cosa cavolo gli costa in termini di denaro UNA 16MB!!!!????
Con i migliaia (milioni) di pezzi che vendono!

Mah!!

Byexx...

non capisco perchè ce l'abbiate tutti con l'ht. In fondo è stata la funzione che ha levato intel dalle castagne diverse volte.

Mi chiedo spesso (e se qualcuno puo dire qualcosa lo dica) perchè Intel inserisce cache di secondo livello unificata fino 4mb (o nella maggioranza dei casi cache da 1 mb) facendola pagare una cifra!!

Ma non possono metterne una da 16mb!!???"""

Cosa cavolo gli costa in termini di denaro UNA 16MB!!!!????
Con i migliaia (milioni) di pezzi che vendono!

Mah!!

Byexx...


Hai mai visto una fotografia del die del Pentium M?
Più della metà della superfice è occupata dalla cache L2.

16MB di L2? :rotfl:
Ottimi consumi, die grande come una piastra, ed il mutuo lo fai tu per comprarlo :asd:

probabilamente con 16mb di cache ci starebbero 5 chip per wafer....e ti costerebbero 5000E l'uno

Ma non possono metterne una da 16mb!!???"""
Cosa cavolo gli costa in termini di denaro UNA 16MB!!!!????
Il fatto è che questa Cache non è mica memoria statica normale :rolleyes:

Speriamo che anche i produttori di GPU inizino a seguire la via del basso consumo. Che serve criticare i Prescott che consumano circa 150W quando le schede video odierne ne consumano 200 ? :p
http://www.hwupgrade.it/articoli/1361/consumi.png

Edit: i consumi sono riferiti ad un sistema Athlon64-FX con quella scheda, quindi i consumi della sola scheda sono inferiori, ma comunque molto alti IMHO... :p

non capisco perchè ce l'abbiate tutti con l'ht. In fondo è stata la funzione che ha levato intel dalle castagne diverse volte.
Nessuno ha attaccato HT
Tra parentesi per ora è il mio motivo più grande per cui non passo a A64

E se l'HT verrà dismesso, ben venga, preferisco un vero nucleo solo, o due veri nuclei, che non uno vero che finge di lavorare per due!


evidentemente non hai mai avuto un P4...io da (felice) possessore di A64 ed ex (felice) possessore di P4 North e Prescott con HT posso dirti che nell'utilizzo quotidiano l'HT si sente eccome a livello di "prontezza" del PC nel rispondere alle richieste....magari poi sul singolo applicativo l'A64 è superiore ma nell'uso di tutti i giorni devo dire che ho notato un leggero passo indietro col passaggio ad AMD e proprio per questo sto aspettando che i prezzi dei Dual core si abbassino in modo da sostituire il 3200+ con un X2 (e presumibilmente avere una sensazione di "prontezza" ancora superiore visto che 2 core fisici rendono meglio di 2 virtuali)

Speriamo che anche i produttori di GPU inizino a seguire la via del basso consumo. Che serve criticare i Prescott che consumano circa 150W quando le schede video odierne ne consumano oltre 200 ? :p
http://www.hwupgrade.it/articoli/1361/consumi.png
Basta semplicemente leggere gli articoli invece che parlare a vanvera.
Mi sto giusto informando ora perchè cerco una VGA basso costo e bassi consumi.
Si passa da 30W a 110W, in pratica come gli odierni processori (con pesanti oscillazioni idle/burn, pari al 50%).
I circa 220W dell'immagine (VA con cosfi pari a 1) sono chiaramente riferiti all'intero sottosistema CPU+VGA+RAM+HD+MB.
:rolleyes:

personalmente sfrutto l'HT in più occasioni, anche se a quanto ne so è stata più che altro una tecnologia introdotta per sfruttare appieno la lunga pipeline dei netburst cercando di eliminare gli svantaggi che questa avrebbe potuto portare... imho ora con la moda dei dual core e le pipeline più corte anche l'HT sparirà dalla scena... diciamo che era una soluzione temporanea in attesa dell'avvento dei dual core reali!

Cmq aspetto con ansia l'uscita del merom...

Speriamo che anche i produttori di GPU inizino a seguire la via del basso consumo. Che serve criticare i Prescott che consumano circa 150W quando le schede video odierne ne consumano oltre 200 ? :p
http://www.hwupgrade.it/articoli/1361/consumi.png

guarda che i consumi sono di tutto il sistema... se solo per cpu e gpu andassero via 350 watt servirebbe un alimentatore da lavatrice (non che siamo tanto lontani cmq...)

Basta semplicemente leggere gli articoli invece che parlare a vanvera.
Mi sto giusto informando ora perchè cerco una VGA basso costo e bassi consumi.
Si passa da 30W a 110W, in pratica come gli odierni processori (con pesanti oscillazioni idle/burn, pari al 50%).
I circa 220W dell'immagine (VA con cosfi pari a 1) sono chiaramente riferiti all'intero sottosistema CPU+VGA+RAM+HD+MB.
:rolleyes:
Lo so. Stavo editando il messaggio mentre rispondevi. ;)

guarda che i consumi sono di tutto il sistema... se solo per cpu e gpu andassero via 350 watt servirebbe un alimentatore da lavatrice (non che siamo tanto lontani cmq...)
Ripeto. Lo so. Stavo proprio editando il messaggio per specificarlo mentre mi avete risposto perché mi ero accorto che potevo essere fuorviante, se siete più veloci della luce a rispondere non ci posso fare nulla. In quasi tutti i test sui consumi si va a misurare voltaggio e amperaggio all'uscita dell'alimentatore, quindi davo un po' per scontata la cosa... :p

Ripeto. Lo so. Stavo proprio editando il messaggio per specificarlo mentre mi avete risposto perché mi ero accorto che potevo essere fuorviante, se siete più veloci della luce a rispondere non ci posso fare nulla. In quasi tutti i test sui consumi si va a misurare voltaggio e amperaggio all'uscita dell'alimentatore, quindi davo un po' per scontata la cosa... :p
Credo abbiano semplicemente misurato quanti ampere entrano DENTRO l'alimentatore. La tensione anche senza misurarla possiamo ipotizzarla costante a 230V, il calcolo è presto fatto.
In tutti i test sui consumi si fa così...
A parte xbit-labs che addirittura ha derivato un molex, misurando direttamente la corrente che entra nella scheda video.

Non sono d'accordo con l'affermazione "Il nuovo tipo di pipeline a 14 stadi risulta comunque più lungo rispetto alle pipeline a 12 stadi impiegate nei processori AMD Athlon 64; questo fattore comporta due aspetti: frequenze operative più elevate ma una minore efficienza."

L'efficenza si ha quando il numero di stadi è quello "giusto" per la frequenza di lavoro prevista.

31 stadi sono stati un errore ma ai tempi non potevano sapere che non sarebbero riusciti a salire tanto in frequenza, fossero riusciti a salire in frequenza sarebbero stati una scelta ottimale.

fossero riusciti a salire in frequenza sarebbero stati una scelta ottimale.
Chiaro...pensate che avevano previsto i 6 Ghz per il 2006 !!! :D

Quindi se non ho capito male si segue la strada di Centrino anche per soluzioni desktop?

:mbe:

Credo abbiano semplicemente misurato quanti ampere entrano DENTRO l'alimentatore. La tensione anche senza misurarla possiamo ipotizzarla costante a 230V, il calcolo è presto fatto.
In tutti i test sui consumi si fa così...
A parte xbit-labs che addirittura ha derivato un molex, misurando direttamente la corrente che entra nella scheda video.
Ok, ma non era mia intenzione fare una valutazione accuratissima del consumo di questa o quella CPU e GPU. Volevo solo segnalare il fatto che in generale nell'evoluzione delle CPU si sta andando verso un minore consumo mentre le ultime GPU nVidia e ATI consumano più dei modelli precedenti, qundi nelle GPU la tendenza è ancora quella della crescita dei consumi e si evince chiaramente dall'immagine che ho linkato. Fa eccezione solo la 7800GTX che consuma un po' meno della 6800Ultra.
Mi auguro semplicemente che la tendenza verso la riduzione dei consumi si diffonda anche ai produttori di GPU... :p

Non so se ora è più chiaro quello che intendo...

Chiaro...pensate che avevano previsto i 6 Ghz per il 2006 !!! :DPer arrivarci, ci arrivano. Solo che il calore prodotto è troppo.
http://blue.ap.teacup.com/memesama3939/timg/middle_1123515750.jpghttp://blue.ap.teacup.com/memesama3939/timg/middle_1123516628.jpg

...un certo processo tecnologico il team di ingegneri Intel DOVEVA sapere quale headroom relativamente alla massima frequenza di funzionamento ottenibile avrebbero avuto a disposizione.
Altrimenti devo pensare che abbiano progettato il Pentium 4 (già dalla prima versione di nucleo Willamette) a "compartimenti stagni".
La questione dell'avere una memoria cache unificata oppure separata istruzioni e dati risale ormai all'82385 e seguenti sistemi di memoria cache adottati da Intel.
Francamente parlando mi intrigava già all'epoca molto di più la architettura Harvard della famiglia 68000 Motorola che non quella più "tradizionale" Intel.
Grazie.

Marco71.

Ok, ma non era mia intenzione fare una valutazione accuratissima del consumo di questa o quella CPU e GPU. Volevo solo segnalare il fatto che in generale nell'evoluzione delle CPU si sta andando verso un minore consumo mentre le ultime GPU nVidia e ATI consumano più dei modelli precedenti, qundi nelle GPU la tendenza è ancora quella della crescita dei consumi e si evince chiaramente dall'immagine che ho linkato. Fa eccezione solo la 7800GTX che consuma un po' meno della 6800Ultra.
Mi auguro semplicemente che la tendenza verso la riduzione dei consumi si diffonda anche ai produttori di GPU... :p

Non so se ora è più chiaro quello che intendo...
Sì
ma il discorso è che l'ultima generazione di schede nvidia consuma MENO della rispettiva 68xx
e le schede x800 di ati consumano MENO delle precedenti 9800 top gamma
quindi sostanzialmente stiamo assistendo ad miglioramenti di prestazione tenendo sempre fissi i consumi... forse non è il massimo, ma neppure criticabile

...un certo processo tecnologico il team di ingegneri Intel DOVEVA sapere quale headroom relativamente alla massima frequenza di funzionamento ottenibile avrebbero avuto a disposizione.
Altrimenti devo pensare che abbiano progettato il Pentium 4 (già dalla prima versione di nucleo Willamette) a "compartimenti stagni".
Chi lo sa... Magari i primi esperimenti sulla tecnologia a 90 nm avevano dato risultati più positivi... O i test non avevano raggiunto dimensioni in transistor tali da permettere una stima della corrente di leakage...che poi si è rivelato essere il problema principale per tutti e non solo per Intel...

Sì
ma il discorso è che l'ultima generazione di schede nvidia consuma MENO della rispettiva 68xx
e le schede x800 di ati consumano MENO delle precedenti 9800 top gamma
quindi sostanzialmente stiamo assistendo ad miglioramenti di prestazione tenendo sempre fissi i consumi... forse non è il massimo, ma neppure criticabile
Beh, la 1800XT consuma più della X850XT, ad esempio. Certamente c'è anche un incremento di prestazioni oltre che di features disponibili (altrimenti non avrebbe nemmeno avuto senso metterle in produzione). Comunque spero che i consumi vengano ridotti più sensibilmente in futuro, anche perché la tendenza è ormai quella dei barebone e dei mediacenter, e non dei mega-big-tower con 7000 ventole. Già il fatto che la 7800go per portatili consumi 65W circa contro una ventina di Watt dei Pentium-M dovrebbe far pensare IMHO... :p
Forse dobbiano aspettare che le GPU si evolvano fino a spostare sulla CPU il collo di bottiglia (e con 2x7800GTX non siamo lontani)...

Ora che il marketing è rimasto senza frutti nel campo del Netburst, che è rimasto inchiodato ai 3,6-3,8 GHz senza essere riuscito a sfondare la soglia psicologica del 4000 (cosa che invece AMD sta facendo, senza inventare numeri di serie indecifrabili),
sono opinioni... la mia è che sia più marketing quello di AMD, che tira fuori un "4000" fittizio senza corrispondenza a grandezze fisiche di nessun tipo In ultimo, la mia convinzione che le L1 che dialogano e la L2 condivisa non mi sembrano delle genialate, sembra quasi un voler risparmiare su qualcosa...
forse non sai che il calcolo parallelo (avere più cpu o più "core" in funzione nello stesso sistema) oltre che miglioramenti prestazionali comporta problematiche non banali (sulla coerenza dei dati): le cache delle cpu devono essere sincronizzate
una volta i dati scambiati venivano fatti passare sul Front Side Bus che connetteva tutte le cpu col memory controller, ed era praticamente tutto overhead, i sistemi recenti funzionano molto meglio anche perchè hanno canali dedicati (e autonomi)
la cache L2 condivisa è stata preferita per una precisa motivazione: si pensava che avrebbe reso meglio nel complesso rispetto a due cache separate di dimensioni dimezzate, perchè avrebbe eliminato l' overhead dei dati in comune, che sarebbero stati ripetuti e quindi ridondanti
con le pipeline così corte l'Hyper Threading non sarà utilizzato...
HT, come soluzioni multithreading equivalenti implementate in altre piattaforme (nella fattispecie, POWER di IBM o SPARC di SUN) hanno solo uno scopo : aumentare la % di occupazione delle risorse interne al processore che per motivi vari un thread solo può sottosfruttare
in questo, prescindono dalla lunghezza dalla pipeline perchè tali risorse possono avere una diversa collocazione temporale/spaziale ma porre ugualmente lo stesso problema (sfruttamento < 100%)
Abbassando gli stadi di pipeline, e con il dual core, non ce n'è minimamente bisogno
per non avere "minimamente bisogno" di una logica che tenga traccia di due thread state allo stesso tempo, bisognerebbe che i core fossero tanti e ciascuno semplice, di modo che sia abbia la certezza che ogni thread sfrutti al 100% il "core" su cui gira
con una struttura composta da: decoder superscalare -> scheduler -> gruppo di 3 alu intere + 3AGU + 2 FPU tale certezza non c'è: si sa che più di quelle operazioni per clock non possono essere eseguite, ma la media per clock è comunque più bassa
be' 14 stadi di pipeline sono sicuramente peggio di 12 se si segue la "via" del Netburst......sono sicuro che con tecniche di predizione azzeccate le prestazioni globali siano migliori....ora la risposta ad AMD ke deve fare altri passi in avanti (spero)
sembra convinzione unanime che il numero di stadi di pipeline abbia influenza certa e matematica sugli effetti di un branch errato... :rolleyes:
invece si trascura che nel corso degli ultimi 10 anni il design della pipeline stessa e gli accorgimenti che in essa sono confluiti , sono evoluti parecchio...

Mi chiedo spesso (e se qualcuno puo dire qualcosa lo dica) perchè Intel inserisce cache di secondo livello unificata fino 4mb (o nella maggioranza dei casi cache da 1 mb) facendola pagare una cifra!!

Ma non possono metterne una da 16mb!!???"""

Cosa cavolo gli costa in termini di denaro UNA 16MB!!!!????
Con i migliaia (milioni) di pezzi che vendono!

Mah!!

Byexx...
perchè ovviamente la memoria cache non c'entra nulla con la normale memoria RAM.
La RAM è una memorid di tipo DRAM fondamentalmente, ovvero Dynamic RAM, in cui per mantenere memorizzato un dato è necessario effettuare dei continui refresh nella cella di memoria (non mi dilungo troppo sul lato tecnico che saturo il DB di HWUpgrade :D).
Invece le memorie cache, necessitando di prestazioni MOLTO piu' elevate, utilizzano un'altro tipo di memoria la SRAM, ovvero Static RAM....
Perchè la SRAM è + veloce?
essenzialmente perchè NON necessita di continui refresh delle celle di memorie essendo esse statiche, ovvero capaci di mantenere autonomamente il dato memorizzato.
Inoltre ci sarebbe da aggiungere la minore latenza di accesso per memorie di dimensione non troppo elevata.
Ma andiamo a vedere il meccanismo che mantiene il dato nelle celle senza bisogno di refresh...
essenzialmente nelle Dram abbiamo un transistor per ogni cella di memoria...
nelle Sram invece abbiamo ben SEI transitor per cella di memoria..
quindi mentre nelle DRAM con ogni transistor possiamo memorizzare un bit, nelle SRAM abbiamo bisogno di 6 transistor solo per memorizzare un bit...
andiamo a fare un rapido calcolo quindi:
1 Byte = 8 bit --> 48 transistor
1 KByte = 1024 Byte --> 49.152 transistor
1 Mbyte = 1024 KByte --> 50.331.648 transistor
Puoi quindi ben capire che aumentare la cache diventa MOLTO costoso in termini di transistor....
per avere una cache della grandezza che avevi ipotizato prima, ovvero 16 MByte avremo
16 Mbyte = 50.331.648 x 16 = 805.306.368
ovvero quasi IL TRIPLO dei transistor di R520 o di G70.... e SOLO per la cache
Ovviamente poi per cache di queste dimensioni le latenze di accesso saranno ovviamente piu' elevate in quanto sarà piu' complesso indirizzare direttamente le celle di memoria... e ovviamente sarà anche piu' complessa la circuiteria di interconnessione per garantire questo accesso.
Come vedi, per ancora qualche anno, cache di queste dimensioni saranno un utopia per processori rivolti al mercato CONSUMER.

sono opinioni... la mia è che sia più marketing quello di AMD, che tira fuori un "4000" fittizio senza corrispondenza a grandezze fisiche di nessun tipo

è confrontato con un ipotetico thunderbird a quella frequenza in teoria ... anke perkè se confrontato con i processori intel in tutto quello che non sia encoding video o seti@home questo PR è addirittura troppo conservativo

HT, come soluzioni multithreading equivalenti implementate in altre piattaforme (nella fattispecie, POWER di IBM o SPARC di SUN) hanno solo uno scopo : aumentare la % di occupazione delle risorse interne al processore che per motivi vari un thread solo può sottosfruttare
in questo, prescindono dalla lunghezza dalla pipeline perchè tali risorse possono avere una diversa collocazione temporale/spaziale ma porre ugualmente lo stesso problema (sfruttamento < 100%)

ma converrai con me ke è piu' efficace implementare HT in un processore con pipe lunghe in cui si ha a disposizione una "granularità" piu fine nell'accesso alle unità di esecuzione piuttosto che in un processore a pipe corte

sembra convinzione unanime che il numero di stadi di pipeline abbia influenza certa e matematica sugli effetti di un branch errato... :rolleyes:
invece si trascura che nel corso degli ultimi 10 anni il design della pipeline stessa e gli accorgimenti che in essa sono confluiti , sono evoluti parecchio...
ma a parità di tecnologia una pipe corta è ovviamente meno penalizzata di una pipe lunga...
inoltre avevo pure sentito parlare di pipe "ombra" ovvero vengono duplicati degli stadi della pipeline in modo da seguire strade diverse, e in caso di brach misprediction si otteneva comunque il risultato corretto perchè erano già stati effettuati i calcoli per entrambi i casi...
sai niente a riguardo delle arkitetture che prevedevano quest'implementazione?? io ormai non mi ricordo + un kakkio.....

è confrontato con un ipotetico thunderbird a quella frequenza in teoria ... anke perkè se confrontato con i processori intel in tutto quello che non sia encoding video o seti@home questo PR è addirittura troppo conservativoRispetto ai Pentium4, forse, non ai processori Intel in generale, visto che i Pentium-M hanno prestazioni per clock molto elevate in tutto ciò che non sia rendering. Comunque bisogna anche prendere atto che i Pentium4 rendono bene anche nel multitasking....

inoltre avevo pure sentito parlare di pipe "ombra" ovvero vengono duplicati degli stadi della pipeline in modo da seguire strade diverse, e in caso di brach misprediction si otteneva comunque il risultato corretto perchè erano già stati effettuati i calcoli per entrambi i casi...
sai niente a riguardo delle arkitetture che prevedevano quest'implementazione?? io ormai non mi ricordo + un kakkio.....

...mumble... cioè si fanno i calcoli per i due casi in parallelo e si scarta poi quello errato? Ma non è un meccanismo simile a quello della EPIC degli Itanium? O non ho capito niente di quello che hai detto...? :confused: :D

...mumble... cioè si fanno i calcoli per i due casi in parallelo e si scarta poi quello errato? Ma non è un meccanismo simile a quello della EPIC degli Itanium? O non ho capito niente di quello che hai detto...? :confused: :D
l' Explicit Pallalel Instruction Code di itanium mi risulta consista nel modo in cui il programmatore o il compilatore creano "bundle" di istruzioni facendo quindi a priori il lavoro che l' instruction scheduler di unba cpu general purpose fa a runtime
laddove ad ogni istruzione sia assegnato un predicato in un registro apposito, o una flag nell' opcode, si evita il più possibile di ricorrere ai salti condizionati... incontrata l' istruzione condizionata, la si esegue se la condizione è verificata, si passa alla successiva altrimenti
oppure la si esegue comunque in attesa della verifica condizionale, per poi annullare il risultato del calcolo in caso non fosse stato necessario eseguirla, ripristinare il vecchio valore nel registro modificato, in uno stadio successivo all' execute
ora, per fare questo ci sono vari modi, tra cui usare registri temporanei per pipeline e una scrittura differita, oppure un set completo di registri di backup oppure un set di registri temporanei
Alpha se non ricordo male usava un' implementazione del pimo sistema, Athlon64 so per certo , 16 registri "temporanei"... il P4 invece farebbe affidamento sulla superiore potenza di calcolo intero (2 alu intere a doppio ciclo) per calcolare sia l' istruzione successiva a quella attuale sia quella "al di là" di un salto (è interessante che con la cache ETC le istruzioni vengono ordinate consecutivamente anche se stanno "prima" e "dopo" i salti, grazie all' interazione diretta della cache con l' unità di branching) per poi annullarne una e prendere solo una "strada"
ma a parità di tecnologia una pipe corta è ovviamente meno penalizzata di una pipe lunga...

per essere precisi , si dovrebbero considerare gli stadi coinvolti a valle del branching: Athlon64 non è più efficiente per il generico fatto di avere "14 stadi di pipeline invece di, per dire, 20 (quelli del northwood)"
è più efficiente perchè a valle dell' intruction decoder, per arrivare alla ALU si attraversano solo due stadi (blocco schedule-execute) in due cicli di clock invece di 6 del decoder + 2 nella alu : è per quello che la penalità è minore, ed anche per via del gruppo di registri di backup che permettono a priori di non "finalizzare" modifiche al register file da parte di istruzioni che si è verificato non andavano eseguite

La tecnica non è dei registri di backup, ma sfrutta il register renaming: l'associazione tra registro fisico e registro logico è "finalizzata" solo per il ramo che effettivamente doveva essere eseguito. Credo che questo sia il modo più efficiente di farlo, anche se si sprecano unità di esecuzione... Ma l'A64 non ha l'HyperThreading...

Comunque una cosa interessante è che Intel ha dichiarato che Merom sarà compatibile con l'infrastruttura Yonah. Perchè non ha detto "sarà compatibile con l'infrastruttura del Pentium M"? ;)

x jappilas

bè io ho espresso la mia in base alle mie conoscenze, evidentemente tu ne hai di + quindi chapeau....ma sembra che concordiamo sul fatto che il numero di pipeline conta, se sono basate su un architettura "giusta" (resto dell'idea che i 20 e 30 stadi del P4 abbiano portato si numerosi vantaggi, ma anke numerosissimi svantaggi.....x intel)

Invece parlo proprio perchè un P4 Prescott HT da 3 GHz lo uso tutti i giorni a lavoro (anche in questo preciso momento)... e sarà per colpa di XP o di altre cose, o per via della mobo o comunque per un fattore di varie cose... ma certe volte questo HT lo sento più imballato del mio Thunderbird 1100 di casa (win2000 mezzo disastrato ormai)...
Ovviamente parlo a parità di quantità di RAM (512).
Sarà il chipset dell SIS magari?

Comunque una cosa interessante è che Intel ha dichiarato che Merom sarà compatibile con l'infrastruttura Yonah. Perchè non ha detto "sarà compatibile con l'infrastruttura del Pentium M"? ;)

perchè a quanto pare ci saranno dei problemi di compatibilità con i Dothan... speriamo che cmq intel mantenga le promesse e permetta ai possessori di piattaforme Yonah un upgrade a Merom, senza menate di circuiteria di alimentazione differente (come nel caso del passaggio dai northwood ai prescott su socket 478...)...

perchè a quanto pare ci saranno dei problemi di compatibilità con i Dothan... speriamo che cmq intel mantenga le promesse e permetta ai possessori di piattaforme Yonah un upgrade a Merom, senza menate di circuiteria di alimentazione differente (come nel caso del passaggio dai northwood ai prescott su socket 478...)...

Appunto... mi sa tanto di imminente cambio di socket nel passaggio a Yonah... contrariamente a quanto qualcuno tempo fa dichiarava.

io non ce la faccio ad attendere Merom, vorrà dire che mi accontenterò di Yonah ;) che comunque non sarà una rivoluzione ma sarà un'ottima CPU :O

io non ce la faccio ad attendere Merom, vorrà dire che mi accontenterò di Yonah ;) che comunque non sarà una rivoluzione ma sarà un'ottima CPU :O

già, mi sa che anche per me sarà difficile resistere!

x jappilas
bè io ho espresso la mia in base alle mie conoscenze...
non volevo essere sarcastico ad personam :O
a volte mi viene, nei confronti di quelli che vedo come preconcetti che detti una volta, circolano con valenza di "assiomi" senza che ai passaggi successivi vengano approfonditi e verificati
tipo "A ha un numero di stadi maggiore di B, implicitamente ne consegue che A è peggio": magari A si rivela effettivamente peggio di B, ma non lo è automaticamente, si deve andare a vedere come le cose sono implementate
(e non dico di aver per forza agione, anzi se mi si portano argomenti che mi smentiscono, sono contento di apprendere la versione corretta di qualcosa, l' importante è approfondire)
in qs mettiamo che si abbiano soltanto 10 stadi nel main loop (tanto la cache ETC disaccoppia dal flusso principale il decoder delle istruzioni, quindi gli ulteriori 10 stadi di pipeline che lo compongono, "scompaiono" magicamente, ma anche essendo offline andrebbero in realtà contati ;))
e quei 10 siano strutturati con lo scheduler all' inizio e la ALU in fondo : anche con meno stadi avrebbe avuto una penalità potenzialmente superiore a quella di un ipotetico processore con 14, in cui scheduler e alu siano stati più ravvicinati