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

Per la prossima generazione di processori Pentium D a 0,065 micron Intel non introdurrà il supporto alla tecnologia HyperThreading

Click sul link per visualizzare la notizia.

Senza roadmap alla mano... il che vuol dire che l'HT dual processor ci sarà sugli Extreme e sugli Xeon... si spera almeno.
E ai Celeron D cosa succederà? Saranno i vecchi P4 da 512K di L2 monocore e senza HT... o qualcosa di più performante magari anche con 1MB di cache e l'FSB a 800?

io non ho ben capito... presler da quanto sembra è un pentium D con i due core al posto che in un unico pezzo in due - suppongo per ridurre di molto gli scarti: se hai due core assieme e uno è difettoso, butti via pure quello buono. il core, dalle foto che ho visto, è ancora quello di un prescott... e sarebbe un nuovo processore questo? è semplicemente uno smithfield a 0.065 nm, il che alla fin fine è ancora il solito pentium 4 che sarebbe più che ora di far andare in pensione. senza nulla togliere eh, ma ormai i concetti che ha dietro sono vecchi e bacucchi.

Devono ancora uscire i dual core a 90 nm che si parla già dei 65 nm: è come per l'uscita del Prescott, se ne è parlato tanto ed alla fine è uscito con + di un anno di ritardo. Con tutti i problemi riscontrati nel passaggio da 130 nm a 90 nm, mi sa che i problemi aumenteranno in via esponenziale per quest'altro cambiamento.

Il passaggio da 90nm a 65nm potrebbe portare ad intel dei benefici in termini di dissipazione termica, così come il passaggio da 130 a 90 li ha portati ad AMD!
Speriamo in bene...

Intel deve sperare vivamente di non ritrovarsi i problemi di dissipazione e di varia natura che ha avuto nel passaggio da 130 a 90 nm, altrimenti accumulerebbe ritardi su ritardi e stavolta non se la cavera' facilmente...

Faccio un po' il troll.
Diciamo che molte di queste discussioni si potrebbero facilmente evitare semplicemente prendendo un bel Athlon64 3500+, che è il procio più potente che abbia mai provato in vita mia (e ne ho provati tanti e di tutti i tipi..)

Certo che una delle feature più interessanti dei Pentium dual core era il fatto che associando l'HT si potevano vedere fino a 4 core logici su una stessa macchina (va bene che se non supportati dal software non te ne fai comunque niente, però...). Senza il supporto all'HT mi sembra una bella segata a questi processori!

(comunque non capirò mai, almeno a livello di buon senso, il fatto di tagliare le gambe ai processori o più in generale a dei buoni prodotti! ... a meno che nn sia un modo come un altro di proporti dei processori venuti fuori meno bene rispetto agli altri, che non funzionano in certe condizioni, ma che comunque in condizioni più rilassate vanno più che bene (evitando così di cestinare dei prodotti comunque fruibili e che genererebbero comunque un guadagno o comunque potrebbero contenere delle perdite).)

Ciauz!

rieccoci col trollerellamento...sai qual'è la migliore cosa secondo me?? evitare commenti di questo tipo, che al max sono un male per i database del forum di hwupgrade. e prendetevi tutti un bel k6 III+ con la gentoo!

scusate la domanda da ignorante: allora dual core + ht vuol dire che windows rileva 4 cpu giusto? ma allora che win ci si deve mettere uno che si prende il p4 extreme? fra l'altro mipare che questa sia anche la cpu indicata x i giocatori incalliti no? grazie

Certo che una delle feature più interessanti dei Pentium dual core era il fatto che associando l'HT si potevano vedere fino a 4 core logici su una stessa macchina (va bene che se non supportati dal software non te ne fai comunque niente, però...). Senza il supporto all'HT mi sembra una bella segata a questi processori!
Secondo me fanno bene, invece.
Già in una CPU dual core ci sono i due core che si devono contendere l'accesso alla memoria: con l'HT ci sarebbero 4 thread a farlo, il che potrebbe anche provocare serii problemi di perdita di prestazioni del sistema...

Dott. Ciddiiiii :) ... guarda che il P4 EE ce l'ha 4 core (2 fisici + 2 logici), ma c'hanno pure castrato il bus a 800 invece di lasciarlo a 1066 -_-
Bella per Intel eh ? Manco regalati (ok ok regalati si, ma il senso l'avete capito ;-)

ripeto: ma che win bisogna usare x vedere le 4 cpu?

Win 2003 :P ?

La concorrenza ha postato un'immagine ...
http://www.tomshw.it/guides/cpu/20050405/images/task_dual_ht.gif
Adesso non so se e' Win XP o il 2003 pero'.

Dott. Ciddiiiii :) ... guarda che il P4 EE ce l'ha 4 core (2 fisici + 2 logici), ma c'hanno pure castrato il bus a 800 invece di lasciarlo a 1066 -_-
Infatti non la vedo come una bella mossa... Mah.
Comunque vedremo nei test che faranno come si comporteranno...

Sempre la concorrenza ha detto che con l'HT le prestazioni peggiorano LOL come volevasi dimostrare ...

grazie infinite!
scusate la mia ignoranza, ma sto extreme ed sarebbe x giocatori no? (oltre che x lavoro da professionisti) ma allora si puo giocare anche col win2003? se no se xp nn lo vede è sprecato a meno che il nuovo xp64 nn abbia risolto i problemi.
vi sto chiedendo tutte ste cose perchè sto seriamente pensando di prendermi sto dual core in abbinata a uno sli nvidia

scusate la domanda da ignorante: allora dual core + ht vuol dire che windows rileva 4 cpu giusto? ma allora che win ci si deve mettere uno che si prende il p4 extreme? fra l'altro mipare che questa sia anche la cpu indicata x i giocatori incalliti no? grazie

Il miglior procio per i Giochi è l'Athlon FX55 brucia in tutti i Test e giochi esistenti il P4EE anche l'ultima versione quella con EMT64 e bus a 1066 ;) se non mi credi vai su Google e fai una ricerca!

Secondo me fanno bene, invece.
Già in una CPU dual core ci sono i due core che si devono contendere l'accesso alla memoria: con l'HT ci sarebbero 4 thread a farlo, il che potrebbe anche provocare serii problemi di perdita di prestazioni del sistema...

infatti su qlk benk ricordo che l'EE era sotto al D classico
ma credo sia solo un qlk baco a livello soft....
IMHO cmq la differenza da EE a D liscio inizia ad essere troppo poca per giustificare un Delta€ cos' elevato solo per HT e FSB 1066

BYEZZZZZZZZZZZZZ

P.S.x killer....
è ovvio che chi prende queste CPU dual core le utilizzerà magari MARGINALMENTE per i gioki ma principalmente per applicativi che sfruttano la doppia CPU

Il miglior procio per i Giochi è l'Athlon FX55 brucia in tutti i Test e giochi esistenti il P4EE anche l'ultima versione quella con EMT64 e bus a 1066 ;) se non mi credi vai su Google e fai una ricerca!


ce credo ce credo!
ho anche io un dual amd 2200mp! poi ho anche un dual p2-300 e un dual p3-500!

comunque la mia domanda resta identica: anche con athlon fx dual core che uscirà si vedranno 4 cpu

Athlon64 dual core sara' due core fisici e basta. Niente HT - niente 2 core logici in piu'. AMD non ha mai sviluppato una tecnologia simile ad HT, anche volendo metterla non avrebbero potuto per via del numero di pipeline.

infatti su qlk benk ricordo che l'EE era sotto al D classico
ma credo sia solo un qlk baco a livello soft....
IMHO cmq la differenza da EE a D liscio inizia ad essere troppo poca per giustificare un Delta€ cos' elevato solo per HT e FSB 1066

BYEZZZZZZZZZZZZZ

P.S.x killer....
è ovvio che chi prende queste CPU dual core le utilizzerà magari MARGINALMENTE per i gioki ma principalmente per applicativi che sfruttano la doppia CPU


Sono perfettamente d'accordo con te! io rispondevo alla domanda se il P4 dualcore fosse il miglior procio per giochi! oggi e credo per un altro annetto o forse + i giochi non gioveranno del DualCore difatti AMD proporrà l'FX ancora SingleCore che come si sa è il miglioprocio per i Gamers ;)

Athlon64 dual core sara' due core fisici e basta. Niente HT - niente 2 core logici in piu'. AMD non ha mai sviluppato una tecnologia simile ad HT, anche volendo metterla non avrebbero potuto per via del numero di pipeline.

Scusa, perchè AMD non potrebbe mettere una soluzione simile all'HT di intel?

Perché l'HT sfrutta proprio il fatto che in una CPU con un numero elevato di stadi, è facile che la pipeline vada in stallo. Quando ciò si verifica l'esecuzione (e le risorse non impegnate) passa al secondo thread, che può continuare ad andare avanti.

Invece gli Athlon / 64 hanno una pipeline più corta, quindi più efficiente e che molto più raramente va in stallo, per cui si avvantangerebbe ben poco dell'HT, a fronte di un aumento della complessità del processore.

Non è proprio vero: il Power4/PPC970 (che ha 16 stadi, uno meno del massimo del K8 che sono 17) ha una feature che si chiama super-threading, ma fa la stessa cosa che fa il P4 garantendo tipicamente qualcosina in prestazioni in più nel multi threading.
http://www.answers.com/main/ntquery;jsessionid=3njeikumoudj8?method=4&dsid=2222&dekey=Simultaneous+multithreading&gwp=8&curtab=2222_1&sbid=lc02a

Il Power5 idem.

Non è proprio vero: il Power4/PPC970 (che ha 16 stadi, uno meno del massimo del K8 che sono 17)
Sì, ma 16 è il MINIMO numero di stadi per Power4/PPC (per la maggior parte delle istruzioni intere), mentre se non erro arriva fino a 27 stadi.
ha una feature che si chiama super-threading, ma fa la stessa cosa che fa il P4 garantendo tipicamente qualcosina in prestazioni in più nel multi threading.
http://www.answers.com/main/ntquery;jsessionid=3njeikumoudj8?method=4&dsid=2222&dekey=Simultaneous+multithreading&gwp=8&curtab=2222_1&sbid=lc02a

Il Power5 idem.
No, è stata introdotta a partire dal Power5: Power4/PPC970 non hanno alcun "simultaneous multithreading".

Sì, ma 16 è il MINIMO numero di stadi per Power4/PPC (per la maggior parte delle istruzioni intere), mentre se non erro arriva fino a 27 stadi.
Arriva a 21 nel floating point, e cque non è nemmeno da considerare il floating point perchè gli stage che interessano l'HT sono in genere quelli prima (e a volte dopo) l'esecuzione, mentre gli stage in più sul floating point sono i genere tutti interni al blocco di exec delle istruzioni.
In ogni caso sarebbe un raffronto 16 stage del Power4 e 30 e passa del P4 negli interi.

Se vuoi ti linko anche un parere di ars thecnica:
IBM's POWER5 uses hyperthreading, and it certainly doesn't have the outrageous 31-stage pipeline length of Prescott. In fact, the POWER5's 16-stage pipeline isn't much longer than the Pentium M's speculated pipeline length of 12 to 14 stages. I say this only to illustrate the point that there's nothing in the lower number of pipeline stages that somehow magically makes the Pentium M a poor candidate for hyperthreading.

http://arstechnica.com/articles/paedia/cpu/prescott.ars/1

Il K8 ha 12 stadi negli interi, l'aggiunta di un eventuale 'HT' aumenterebbe qualche stage e arriverebbe al livello dei PPC IBM.

No, è stata introdotta a partire dal Power5: Power4/PPC970 non hanno alcun "simultaneous multithreading".
Si ma dimentichi che power5 ha gli stessi stage del power4 (forse ci sono piccole variazioni, ma il succo è lo stesso).

Cque il superthreading del power4 non è flessibile come l'HT intel, ma almeno nel prefetch puo' riorganizzare le istruzioni di più thread creando così un multi threading su singolo core.
l'HMT del power5 invece dovrebbe essere equiparabile all'HT intel.

Arriva a 21 nel floating point, e cque non è nemmeno da considerare il floating point perchè gli stage che interessano l'HT sono in genere quelli prima (e a volte dopo) l'esecuzione, mentre gli stage in più sul floating point sono i genere tutti interni al blocco di exec delle istruzioni.
In ogni caso sarebbe un raffronto 16 stage del Power4 e 30 e passa del P4 negli interi.
Sì, ma si parlava di Athlon (non di P4): su questi processori non avrebbe senso implementare una forma di HT perché si guadagnerebbe pochissimo dal punto di vista prestazionale, a fronte di una maggior complessità del chip.
Se vuoi ti linko anche un parere di ars thecnica:
IBM's POWER5 uses hyperthreading, and it certainly doesn't have the outrageous 31-stage pipeline length of Prescott. In fact, the POWER5's 16-stage pipeline isn't much longer than the Pentium M's speculated pipeline length of 12 to 14 stages. I say this only to illustrate the point that there's nothing in the lower number of pipeline stages that somehow magically makes the Pentium M a poor candidate for hyperthreading.

http://arstechnica.com/articles/paedia/cpu/prescott.ars/1
Letto, ma il PPC parte da 16 stadi per le operazioni intere più semplici, e va tranquillamente a salire per quelle più complicate: il Pentium-M è intrinsecamente più efficiente con la sua pipeline più corta, e non sono d'accordo sul fatto che ciò non dice nulla sul fatto che non andrebbe bene per l'HT.
Il K8 ha 12 stadi negli interi, l'aggiunta di un eventuale 'HT' aumenterebbe qualche stage e arriverebbe al livello dei PPC IBM.
Non credo proprio. Innanzitutto quando Intel ha introdotto l'HT l'ha fatto sul P4 Northwood, che era ed è rimasto a 20 stadi di pipeline. Poi K8 e PPC hanno due architetture e un'ISA completamente diverse: il primo è orientato all'efficienza (e la compattezza del codice x86 lo facilita in tal senso), il secondo no.
Si ma dimentichi che power5 ha gli stessi stage del power4 (forse ci sono piccole variazioni, ma il succo è lo stesso).
Già, e hanno anche una forma di HT: quindi non è stato necessario alcuno stadio in più.
Cque il superthreading del power4 non è flessibile come l'HT intel, ma almeno nel prefetch puo' riorganizzare le istruzioni di più thread creando così un multi threading su singolo core.
No, questa è la politica di out-of-order execution implementata nei Power4 e 5: non ha nulla a che vedere col SMT.
l'HMT del power5 invece dovrebbe essere equiparabile all'HT intel.
Lo è. ;)

No caro la tua affermazione è stata:
Perché l'HT sfrutta proprio il fatto che in una CPU con un numero elevato di stadi, è facile che la pipeline vada in stallo. Quando ciò si verifica l'esecuzione (e le risorse non impegnate) passa al secondo thread, che può continuare ad andare avanti.
Sbalgiato.
L'HT al massimo aumenta gli stadi (anche se non necessariamente), non c'è bisogno di avere tanti stadi per implementarlo efficentemente. Una imul o le istruzioni FP impiegano tanti cicli anche su un K8, non solo sul P4. A quel punto puoi sfruttare le parti della cpu inutilizzate per far andare in esecuzione altro codice, mascherando i registri di segmento, data e instruction pointer.

Invece gli Athlon / 64 hanno una pipeline più corta, quindi più efficiente e che molto più raramente va in stallo, per cui si avvantangerebbe ben poco dell'HT, a fronte di un aumento della complessità del processore.
Questo non vuol dire che non puoi inifilare 2 stadi in più nel fetch/decode e metterci un HT.

Letto, ma il PPC parte da 16 stadi per le operazioni intere più semplici, e va tranquillamente a salire per quelle più complicate: il Pentium-M è intrinsecamente più efficiente con la sua pipeline più corta, e non sono d'accordo sul fatto che ciò non dice nulla sul fatto che non andrebbe bene per l'HT.
Via via sale?! O quello schema dice palle, oppure il PPC ha 16stadi per gli interi e 21 per le FP/altivec, morta lì :)
Non è una cosa a spanne!

Il pentium-M ha il suo punto debole proprio nel multithreading, e un HT potrebbe compensare, ma il problema fondamentale è che per una CPU che deve girare al 90% di suo tempo a 500-700MHz (magari con un 50% di throttling) chissenefrega di consumare di più implementando l'HT, lo tieni così com'è e lasci andare, tanto al massimo ti fai un dual core e quando vuoi lavorare in parallelo ne accendi due.

Sbalgiato.
L'HT al massimo aumenta gli stadi (anche se non necessariamente), non c'è bisogno di avere tanti stadi per implementarlo efficentemente. Una imul o le istruzioni FP impiegano tanti cicli anche su un K8, non solo sul P4. A quel punto puoi sfruttare le parti della cpu inutilizzate per far andare in esecuzione altro codice, mascherando i registri di segmento, data e instruction pointer.

il giorno che ti toglierai il vizio di dire "sbagli" giusto per fare quello che ne sa (in effetti altre strade non ne hai) sarà un gran giorno per i forum che frequenti.

se la pipeline è corta, riscontrerà molti meno problemi di stalli, quindi sarà tendenzialmente piena, e quindi una tecnologia come all'hyperthreading (che è risaputo che è una pezza al culo che s'è inventata intel per ovviare al numero di stadi elevato) non serve a nulla (anzi, magari peggiora perfino le cose, come capita in alcuni casi con l'hyperthreading). poi certo, se a mano metti insieme una serie di istruzioni pensate apposta puoi ottenere benefici anche su cpu con pipeline più corte, il problema è che nel complesso il costo non supera i benefici.

però capisco eh, amd e la stessa intel con i pentium m non capiscono un cazzo, dovremmo segnalarti come consulente così insegni loro come si fa una cpu...

Via via sale?! O quello schema dice palle, oppure il PPC ha 16stadi per gli interi e 21 per le FP/altivec, morta lì :)
Non è una cosa a spanne!

arrivano fino a 23, almeno a quanto dice apple:

http://developer.apple.com/technotes/tn/tn2087.html

per questo per quanto riguarda il ppc970 sono usciti non so quanti rumors che avevano come oggetto una "tecnologia analoga all'hyperthreading di intel" che ibm "starebbe sviluppando per il g5"...

scusa caro, a proposito... mi dai qualche link dove posso trovare qualche informazione sull'implementazione del super threading nel ppc970?

Il pentium-M ha il suo punto debole proprio nel multithreading, e un HT potrebbe compensare, ma il problema fondamentale è che per una CPU che deve girare al 90% di suo tempo a 500-700MHz (magari con un 50% di throttling) chissenefrega di consumare di più implementando l'HT, lo tieni così com'è e lasci andare, tanto al massimo ti fai un dual core e quando vuoi lavorare in parallelo ne accendi due.

tutto da dimostrare anche il vantaggio in termini di efficienza. o pensi che l'hyperthreading non abbia costi da questo punto di vista?

No caro la tua affermazione è stata:

Sbalgiato.
L'HT al massimo aumenta gli stadi (anche se non necessariamente), non c'è bisogno di avere tanti stadi per implementarlo efficentemente. Una imul o le istruzioni FP impiegano tanti cicli anche su un K8, non solo sul P4. A quel punto puoi sfruttare le parti della cpu inutilizzate per far andare in esecuzione altro codice, mascherando i registri di segmento, data e instruction pointer.
Senti, "carino", se non conosci neppure la differenza fra latenza e throughput di un'unità di elaborazione, ti consiglio di tornare nuovamente a frequentare qualche corso di architettura degli elaboratori o calcolatori elettronici.
Prova a dare ALMENO un'occhiata ai manuali di AMD e guarda come funziona il moltiplicatore e la sezioen FPU che hai citato. Così magari arriverai a capire perché la pipeline rimane quasi sempre piena anche in presenza di istruzioni come quella che hai citato... :rolleyes:
Poi dai un'occhiata anche all'architettura NetBurst che il P4 ha introdotto, e capirai perché Intel ha ben pensato di implementare l'HT con le ultime versioni di Northwood.

Infine, rifletti su una cosa: come mai né AMD (per gli Athlon e successori) né Motorola (per i G4 e successori) hanno pensato di seguire Intel e implementare una tecnologia simile all'HT.
Eppure AMD, ad esempio, non perde occasione per seguirne le orme (vedi implementazione delle SSE/2/3, e la tecnologia di virtualizzazione).
Se l'HT portasse dei benefici concreti, perfino Intel l'avrebbe implementata sui Pentium-M: STRANAMENTE non l'ha ancora fatto.
Questo non vuol dire che non puoi inifilare 2 stadi in più nel fetch/decode e metterci un HT.
Certo, e poi che te ne fai? Perderesti un po' di efficienza a causa della maggior lunghezza, ma guadagneresti ben poco con l'HT.

Tecnologie come l'HT appaiono su architetture con un elevato numero di stadi di pipeline (es: P3 a 10 stadi, P4 a 20 e ora addirittura 31; G4 a 7 stadi, G5 ad almeno 16). Stranamente.
Via via sale?! O quello schema dice palle, oppure il PPC ha 16stadi per gli interi e 21 per le FP/altivec, morta lì :)
Non è una cosa a spanne!
Infatti, fatti una cultura: http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/A1387A29AC1C2AE087256C5200611780
Il pentium-M ha il suo punto debole proprio nel multithreading, e un HT potrebbe compensare,
No. Non è così, e te l'ho già spiegato: l'HT su un processore con una pipeline corta NON E' CONVENIENTE dal punto di vista prestazionale.
ma il problema fondamentale è che per una CPU che deve girare al 90% di suo tempo a 500-700MHz (magari con un 50% di throttling) chissenefrega di consumare di più implementando l'HT, lo tieni così com'è e lasci andare, tanto al massimo ti fai un dual core e quando vuoi lavorare in parallelo ne accendi due.
Quando giochi o lanci altre applicazioni pesanti, sta tranquillo che il processore non lavorare a frequenze così basse. D'altra parte anche i miei Athlon64 stanno la maggior parte del tempo a girarsi i pollici, ma quando serve la loro potenza, li "metto sotto".

arrivano fino a 23, almeno a quanto dice apple:

http://developer.apple.com/technotes/tn/tn2087.html

per questo per quanto riguarda il ppc970 sono usciti non so quanti rumors che avevano come oggetto una "tecnologia analoga all'hyperthreading di intel" che ibm "starebbe sviluppando per il g5"...
??? cioè ma ti rendi conto che stai parlando di una cpu differente ???

scusa caro, a proposito... mi dai qualche link dove posso trovare qualche informazione sull'implementazione del super threading nel ppc970?
Si, qua (http://www.google.com/).

Vedendo l'arrivo del tuo "amico" Fx preferisco laciarvi con le vostre idee, altrimenti questo thread diventa la solita fiera delle parole scritte a caso rimangiate e ritrattate (che già è diventato così)
Dopotutto siete gli unici che riescono a dare torto a siti con le palle come xbitlabs, arstechnica o anandtech.

a) mi potresti illustrare le differenze tra il ppc970 e il g5?
b) chissà com'è ma sul super threading e ppc970 non riesco a trovare niente su google, non è che cerchi tu e ci posti un bel link?
c) oh, per lo meno stavolta dopo averle sparate grosse hai la dignità di non andare avanti... cmq io andrei a un qualche corso d'umiltà, non hai nemmeno l'umiltà di rileggere le discussioni e verificare se ti ricordi bene o, come sembra da quanto dici accusando il prossimo di ciò che fai tu (e figurarsi se non era colpa dell'altro), ricordi molto male

a) ti arrangi e te le cerchi, il topic parlava di HT e successori del P4.
b) perchè non sai cercare probabilmente http://www.google.com/search?hl=en&safe=off&q=super-threading+power4&spell=1

a) immaginavo
b) quale parte di "ppc970" non hai capito?

Io direi che basterebbe dare un'occhiata a ciò che ha da dire Jon "hannibal" Stokes al riguardo:


http://arstechnica.com/articles/paedia/cpu/prescott.ars

Ovviamente ciò che è valido per il P-M è valido anche per gli A64.

Ma certo leoneazzurro, è uno dei primi articoli che ho postato, il succo è che certa gente un po' ingenuamente pensa all'HT come un modo ad ovviare ai problemi del P4 (gli stalli e le latenze nella pipe), mentre in realtà puo' essere usato non tanto per riempire la pipe in lunghezza, ma piuttosto in ampiezza, tipo sfruttando piu' unità di esecuzione contemporaneamente.

Pero' quando si vuol far finta di non sentire ti passa la voglia pure di discutere :(

povero cucciolo :cry:


che peccato, che peccato che si stesse parlando di athlon 64 e di pentium 4 e non di power5... altrimenti quello che dicevi avrebbe avuto un altro senso... per lo meno, uno =)

comunque bella questa tecnica, che hai poc'anzi applicato al ppc970... si sta parlando di A, tu dici X applicato ad A, ti si risponde che X non vale per A, e alla fine concludi che "eh, visto che lo dicevo io che X vale per B?" :D

facciamo l'esempio:

il Power4/PPC970 (che ha 16 stadi, uno meno del massimo del K8 che sono 17) ha una feature che si chiama super-threading

scusa caro, a proposito... mi dai qualche link dove posso trovare qualche informazione sull'implementazione del super threading nel ppc970?

Si, qua (http://www.google.com/).

b) chissà com'è ma sul super threading e ppc970 non riesco a trovare niente su google, non è che cerchi tu e ci posti un bel link?

b) perchè non sai cercare probabilmente http://www.google.com/search?hl=en&safe=off&q=super-threading+power4&spell=1

b) quale parte di "ppc970" non hai capito?

:muro:

cioè, ma tu muori a dire: "scusate ho detto una cazzata?"... dai, su... abbassare le orecchie pls

Ma certo leoneazzurro, è uno dei primi articoli che ho postato, il succo è che certa gente un po' ingenuamente pensa all'HT come un modo ad ovviare ai problemi del P4 (gli stalli e le latenze nella pipe), mentre in realtà puo' essere usato non tanto per riempire la pipe in lunghezza, ma piuttosto in ampiezza, tipo sfruttando piu' unità di esecuzione contemporaneamente.

Pero' quando si vuol far finta di non sentire ti passa la voglia pure di discutere :(


Il fatto è che le unità di esecuzione vengono mantenute alimentate proprio se non ci sono stalli e latenze nelle pipeline (ossia se non ci sono le "pipeline bubbles"). Nel caso del P4, questo problema è particolarmente grave perchè le pipeline sono così profonde e quindi HT serve per sfruttare al meglio le risorse disponibili, e quindi anche per mascherare questi problemi. In un processore con le pipe corte ed un numero di unità di esecuzione paragonabile al P4 questo problema è meno avvertibile, perchè in generale le pipe vengono mantenute completamente piene più spesso.
Adesso non ricordo dove, ma ho letto che il vantaggio prestazionale dell'HT in un processore tipo Pentium M o Athlon era quantificabile nel caso migliore al 5% circa, mentre nel caso dei P4 intorno al 25-30%.
Chiaro che a quel punto evidentemente si è preferito non perdere tempo e risorse nel progettare qualcosa di simile per questi processori (soprattutto AMD che non ha lo stesso budget di Intel).
E' possibile tuttavia che la notizia di qualche giorno fa che dava HT attivato con i dual core possa anche poter significare che AMD abbia implementato non tanto HT, quanto qualche forma di superthreading. Ovvio che è solo una mia supposizione.

Vedendo l'arrivo del tuo "amico" Fx preferisco laciarvi con le vostre idee, altrimenti questo thread diventa la solita fiera delle parole scritte a caso rimangiate e ritrattate (che già è diventato così)
Questo è il tuo sport preferito, non il mio. Infatti ti guardi bene dal fornire risposte a delle precise domande che ti sono state fatte... :mc:
Dopotutto siete gli unici che riescono a dare torto a siti con le palle come xbitlabs, arstechnica o anandtech.
Qui l'unico che dovrebbe usare un po' la testa sei tu, a meno che non ti piaccia calarti pari pari tutto quello che dicono siti anche autorevoli, senza nemmeno un briciolo di spirito critico... :rolleyes:

Ma certo leoneazzurro, è uno dei primi articoli che ho postato, il succo è che certa gente un po' ingenuamente
Evita di mascherare la tua mancanza di argomenti passando alle offese, perché non ci fai una bella figura... :rolleyes:
pensa all'HT come un modo ad ovviare ai problemi del P4 (gli stalli e le latenze nella pipe),
Mi fai vedere dove l'avremmo scritto, cortesemente? :mc:
mentre in realtà puo' essere usato non tanto per riempire la pipe in lunghezza,
Non vedo come si potrebbe...
ma piuttosto in ampiezza, tipo sfruttando piu' unità di esecuzione contemporaneamente.
Lapalissiano.
Pero' quando si vuol far finta di non sentire ti passa la voglia pure di discutere :(
T'ha già risposto anche leoneazzurro. Invece di arrampicarti sugli specchi fatti un po' di cultura e soprattutto usa la testa, senza subire passivamente tutto ciò che ti viene propinato...

Il fatto è che le unità di esecuzione vengono mantenute alimentate proprio se non ci sono stalli e latenze nelle pipeline (ossia se non ci sono le "pipeline bubbles"). Nel caso del P4, questo problema è particolarmente grave perchè le pipeline sono così profonde e quindi HT serve per sfruttare al meglio le risorse disponibili, e quindi anche per mascherare questi problemi. In un processore con le pipe corte ed un numero di unità di esecuzione paragonabile al P4 questo problema è meno avvertibile, perchè in generale le pipe vengono mantenute completamente piene più spesso.
Adesso non ricordo dove, ma ho letto che il vantaggio prestazionale dell'HT in un processore tipo Pentium M o Athlon era quantificabile nel caso migliore al 5% circa, mentre nel caso dei P4 intorno al 25-30%.
Chiaro che a quel punto evidentemente si è preferito non perdere tempo e risorse nel progettare qualcosa di simile per questi processori (soprattutto AMD che non ha lo stesso budget di Intel).
E' possibile tuttavia che la notizia di qualche giorno fa che dava HT attivato con i dual core possa anche poter significare che AMD abbia implementato non tanto HT, quanto qualche forma di superthreading. Ovvio che è solo una mia supposizione.

Guarda che l'articolo di Ars dice tutto l'opposto di quello che hai appena affermato.

Dall'articolo:
One question that the preceding discussion might raise for the casual reader is this:if the POWER5's pipeline is roughly half the length of the Prescott's, why does it need hyperthreading?

The answer is that the POWER5 is extremely wide, (wide non vuol dire LUNGA, ma LARGA) pipeline stalls translate not into tons of unused clock cycles but tons of unused execution hardware. Or, here's another way of phrasing it: in the event of a pipeline stall, Prescott has a few execution units sitting idle over a large number of clock cycles; the POWER5 has a large number of execution units sitting idle over a few clock cycles. Either way you slice it, that's wasted resources.

Quindi a parte il fatto che cidimauro e Fx sentendosi alle strette come sempre hanno portato il discorso da "sul K8 l'hyperthreading non lo si puo' mettere" a un più plausibile "sul K8 l'HT non è conveniente metterlo", questo non esula dal fatto che aggiungere l'SMT sul P-M o sul K8 potrebbe aumentare a gratis le prestazioni, come affermato dall'articolo di Jon "hannibal" Stokes

Non mi sembra che l'articolo dica esattamente l'opposto di quello che ho affermato. Esempio:

Because we got obsessed with MHz as a marketing number and made Prescott's pipeline so ridiculously long, Prescott benefits much more from a latency-hiding technique like hyperthreading than a saner design like the Pentium M.

che era anche in grassetto. Quindi HT è anche una tecnica per nascondere le latenze e diminuire le pipeline bubbles.

Poi io non ho parlato affatto di Power 5, quando parlo di "processore con pipe corte e numero di unità di esecuzione grossomodo equivalente al P4" sto parlando ovviamente di Athlon 64 e Pentium M. Tra l'altro se le pipe dei Power 5 sono circa la metà di quelle del Prescott, quelle di Athlon e P-M sono circa un terzo. Ed il numero di unità di esecuzione è inferiore (il Power 5 ha 8 unità di esecuzione: Now, the POWER5 can fetch two groups per cycle, for a total of 10 instructions per cycle (two groups of five instructions each). However, it cannot decode and dispatch a total of 10 instructions per cycle. This would, of course, be pointless, since it only has 8 execution units anyway )
come riportato in http://arstechnica.com/articles/paedia/cpu/mpf-2003.ars
Quindi le architetture Power 5 e Athlon 64-Pentium M non sono comparabili.


E' ovvio che si possa sfruttare HT anche su Athlon e P-M, e non ho mai affermato il contrario, invece ho affermato che è possibile e che probabilmente non è conveniente farlo. Anche perchè HT non è "gratis" ma costa transistor per essere implementato.

Quindi non vedo perchè aggredirmi mettendomi in bocca parole che non ho mai detto.

aggredirti??? scusami ma se hai interpretato così non era mia intenzione, figurati se aggredisco l'unico user con cui posso parlare di queste cose.

L'articolo parla dei due punti di vista, il punto di vista intel che dice "per il pentium-M non vale la pena mettere l'HT" sottolineato qua:

So what the Intel rep was really saying was this: Because we got obsessed with MHz as a marketing number and made Prescott's pipeline so ridiculously long, Prescott benefits much more from a latency-hiding technique like hyperthreading than a saner design like the Pentium M.

Che è quello che hai spiegato tu e sono perfettamente d'accordo, ovvero che il prescott usa l'HT per riempire la pipe in lunghezza (ovvero eliminale le "bubbles")

e il punto di vista suo secondo me più corretto:
I say this only to illustrate the point that there's nothing in the lower number of pipeline stages that somehow magically makes the Pentium M a poor candidate for hyperthreading.

Che tradotto significa: "il fatto che il pentiu-M abbia una pipeline corta non lo fa diventare magicamente un cattivo candidato per l'hyperthreading", il che è corretto IMHO, perchè il pentium-M non ha certo una pipe completamente lineare come quella di un 486, ma ha varie unità di esecuzione parallele come dle resto il K8.


E' ovvio che si possa sfruttare HT anche su Athlon e P-M, e non ho mai affermato il contrario, invece ho affermato che è possibile e che probabilmente non è conveniente farlo. Anche perchè HT non è "gratis" ma costa transistor per essere implementato.
Su questo possiamo discuterne tranquillamente, se vuoi in PM, visto ceh andrebbe offtopic.

aggredirti??? scusami ma se hai interpretato così non era mia intenzione, figurati se aggredisco l'unico user con cui posso parlare di queste cose.

L'articolo parla dei due punti di vista, il punto di vista intel che dice "per il pentium-M non vale la pena mettere l'HT" sottolineato qua:

So what the Intel rep was really saying was this: Because we got obsessed with MHz as a marketing number and made Prescott's pipeline so ridiculously long, Prescott benefits much more from a latency-hiding technique like hyperthreading than a saner design like the Pentium M.

Che è quello che hai spiegato tu e sono perfettamente d'accordo, ovvero che il prescott usa l'HT per riempire la pipe in lunghezza (ovvero eliminale le "bubbles")

e il punto di vista suo secondo me più corretto:
I say this only to illustrate the point that there's nothing in the lower number of pipeline stages that somehow magically makes the Pentium M a poor candidate for hyperthreading.

Che tradotto significa: "il fatto che il pentiu-M abbia una pipeline corta non lo fa diventare magicamente un cattivo candidato per l'hyperthreading", il che è corretto IMHO, perchè il pentium-M non ha certo una pipe completamente lineare come quella di un 486, ma ha varie unità di esecuzione parallele come dle resto il K8.


Su questo possiamo discuterne tranquillamente, se vuoi in PM, visto ceh andrebbe offtopic.


Ma infatti non ho posto l'accento solo sulla lunghezza delle pipe, ma anche sul numero di unità di esecuzione (che non è elevato negli A64 o P-M come nel Power5). Come ho detto, HT può essere tranquillamente implementato su A64 e P-M. Poichè però i benefici prestazionali sarebbero limitati a fronte di un aumento del numero di transistors, evidentemente si sceglie di non farlo e di andare direttamente al dual core.

Questo perchè nell'HT il numero di unità di esecuzione è sempre quello, e quindi se già (come succede negli A64 e P-M) il grado di riempimento dello stadio di esecuzione è alto, non si riesce a salire molto in prestazioni.
Nel caso di p4 (dove il grado di riempimento è minore a causa degli stalli, cache miss, branch misprediction ecc. in combinazione con pipeline molto lunghe) e Power 5 (dove il grado di riempimento invece è minore perchè ci sono molte unità di esecuzione parallele, troppe forse per un thread solo) l'HT può dare un deciso boost prestazionale, e quindi è molto conveniente implementarlo. Quindi nessuna discrepanza, IMHO, con l'articolo in questione.

Ok ora ci capiamo. sul fatto che sia poco conveniente l'HT su pentium-M e K8 sono d'accordo, dipende infatti dal costo in transistor.

Sul fatto che non si possa mettere è tutta un'altra storia, visto che l'SMT è indipendente dal tipo di core della cpu.

Sì, ma si parlava di Athlon (non di P4): su questi processori non avrebbe senso implementare una forma di HT perché si guadagnerebbe pochissimo dal punto di vista prestazionale, a fronte di una maggior complessità del chip.

2 pagine fa

beh se è per questo...

Perché l'HT sfrutta proprio il fatto che in una CPU con un numero elevato di stadi, è facile che la pipeline vada in stallo.
** fesseria **
vedi articolo postato da me e leoneazzurro

Invece gli Athlon / 64 hanno una pipeline più corta, quindi più efficiente e che molto più raramente va in stallo, per cui si avvantangerebbe ben poco dell'HT, a fronte di un aumento della complessità del processore.
** fesseria **
la pipe corta non comporta nulla (vedi power5 e vedi articolo di arstechnica) perchè l'SMT puo' essere usato anche per riempire la pipe in larghezza e non solo in profondità.

A rigor di ragionamento tutte le considerazioni fatte da cidimauro (perchè te in realtà più che cambiare discorso non hai fatto) sono sempre in relazione al costo che ha implementare l'HT, su cui per ora nessuno ha detto nulla, perchè se non ha costi proibitivi anche un solo 5% in più di prestazioni farebbero gola anche a un K8, soprattutto nei bench e non si esclude di vedere accoppiato un SMT assieme ai prossimi core K9 abbinato alle tecnologie di virtualizzazione (pacifica, clone della vanderpool di intel)
Quindi prima di cimentarti in argomenti nei quali non sai dove andare a parare per favore, evita di flammare inutilmente.

Il discorso del costo non è solo da mettersi in relazione al mero numero di transistor, ma anche ai tempi ed ai costi necessari alla riprogettazione del core per riuscire ad implementare questa feature. Infatti è ovvio che la logica necessaria non può essere aggiunta gratuitamente "on the fly" su di una architettura già esistente e non pensata per l'SMT. Probabilmente anche questi fattori, uniti all'incremento prestazionale non trascendentale, hanno portato al "salto" della tecnologia SMT su A64 e P-M per passare direttamente al dual core.

Comunque, la probabilità che una pipeline vada in stallo dipende da molte variabili: cache miss rate, branch misprediction rate, latenze varie, (ecc. ecc. ). Però nel caso di pipeline lunghe gli effetti sono molto più devastanti che non nel caso di pipeline corte: svuotare la pipeline e riempirla di nuovo è ovviamente più oneroso in termini di cicli di clock.
Poi (ipotesi mia) se amplio molto la "instruction window" mantenendo inalterati gli altri parametri, credo che vi potrebbe essere una maggiore probabilità che, in un dato momento, io abbia una delle istruzioni in questa "instruction window" in stallo, con gli effetti deleteri di cui sopra.

** fesseria **
vedi articolo postato da me e leoneazzurro

domande:
a) perchè stalla la pipeline?
b) a che punto stalla?

** fesseria **
la pipe corta non comporta nulla (vedi power5 e vedi articolo di arstechnica) perchè l'SMT puo' essere usato anche per riempire la pipe in larghezza e non solo in profondità.

ohhhh esatto, peccato che

- e sarà la 10° volta che lo ripeto -

non si stesse parlando del power5, ma di athlon 64 e pentium m, dove in "larghezza" (mamma mia che termine orribile) c'è abbastanza un cazzo da riempire. discorso diverso è in una cpu vasta come il power5. ma DATO CHE NON SI STAVA PARLANDO DEL POWER5, siamo tutti d'accordo che un HT su pentium m e athlon 64 è poco conveniente, amd e intel compresi. l'hai detto pure tu poco sopra.

certo che se il tuo giochetto è riportare solo mezza frase per tirare merda addosso, si allora cidimauro ha detto una fesseria: se togli la frase dal contesto è una fesseria.

peccato che il contesto c'era... e perchè lo togli? per questo motivo: :mc:

A rigor di ragionamento tutte le considerazioni fatte da cidimauro (perchè te in realtà più che cambiare discorso non hai fatto) sono sempre in relazione al costo che ha implementare l'HT, su cui per ora nessuno ha detto nulla, perchè se non ha costi proibitivi anche un solo 5% in più di prestazioni farebbero gola anche a un K8, soprattutto nei bench e non si esclude di vedere accoppiato un SMT assieme ai prossimi core K9 abbinato alle tecnologie di virtualizzazione (pacifica, clone della vanderpool di intel)

fa così gola che non è stato implementato. fine del ragionamento. il punto è che anche l'HT raggiunge il 25/30% solo IN ALCUNE condizioni, tant'è che in molti bench lo si disabilita... giusto per ricordarti

- come avevo già detto -

che l'hyperthreading non porta solo benefici. o invece mi vuoi dire che un pentium 4 con l'HT abilitato va sempre ALMENO COME un pentium 4 con l'HT disabilitato?

(ovviamente sarà una di quelle risposte che glisserai o alle quali girerai attorno per non rispondere)

(e se rispondi, tra 3 post verrai fuori a dire che eri tu che avevi detto che l'HT non sempre è vantaggioso :D )

Quindi prima di cimentarti in argomenti nei quali non sai dove andare a parare per favore, evita di flammare inutilmente.

tu dovresti preoccuparti un po' più del tuo orticello e un po' meno di dire cosa devono fare gli altri

comunque sei fantastico... quando vieni a dire al prossimo che non capisce niente dopo aver collezionato una bella collanina di figure di merda sei veramente fantastico... fai qualche page-up ogni tanto, ti servirebbe, ma fallo però... lo faccio perfino io!

Fx sinceramente ma non ti senti un po' ignorato a fare tutte delle domande inutili su un discorso che è chiaro e limpido come il mare della costa azzurra?

Tutte le risposte a questo topic sono scritte nell'articolo di ArsTechnica, che non è quello che dico io è semplicemente quello che pensa una persona che lavora per uno dei siti di riferimento sull'Hardware e che io ho semplicemente citato qua (http://www.hwupgrade.it/forum/showpost.php?p=8207260&postcount=45). Quindi leggilo e non divagare inutilmente. Se non capisci l'inglese fatti tradurre da qualcuno l'articolo e via... non ho voglia di mettermi a discutere con te che tendi sempre a girare il discorso su argomenti non pertinenti.

tutto previsto. certo che anche tu... va bene esser prevedibile, però per andare avanti lo stesso nonostante ti si abbia già anticipato vuol dire esser proprio de coccio

(ovviamente sarà una di quelle risposte che glisserai o alle quali girerai attorno per non rispondere)

tu dovresti preoccuparti un po' più del tuo orticello e un po' meno di dire cosa devono fare gli altri

oh chissà com'è, tutti i post che ho fatto in cui ti faccio DOMANDE PUNTUALI E PRECISE non mi trovo mai una risposta che non sia (sintetizzo): "non capisci niente", "non ti serve saperlo", "è già stato scritto ma visto che non capisci niente non l'hai colto" :muro:

sei fortissimo, vai avanti così

Quindi a parte il fatto che cidimauro e Fx sentendosi alle strette come sempre hanno portato il discorso da "sul K8 l'hyperthreading non lo si puo' mettere" a un più plausibile "sul K8 l'HT non è conveniente metterlo",
Non mettermi in bocca parole che non ho detto. :rolleyes:

Tu hai detto questo: Scusa, perchè AMD non potrebbe mettere una soluzione simile all'HT di intel?
E io ho risposto questo: Perché l'HT sfrutta proprio il fatto che in una CPU con un numero elevato di stadi, è facile che la pipeline vada in stallo. Quando ciò si verifica l'esecuzione (e le risorse non impegnate) passa al secondo thread, che può continuare ad andare avanti.

Invece gli Athlon / 64 hanno una pipeline più corta, quindi più efficiente e che molto più raramente va in stallo, per cui si avvantangerebbe ben poco dell'HT, a fronte di un aumento della complessità del processore.
Se hai voglia di raccontar balle, fallo pure, ma NON TI PERMETTERE DI SPACCIARE PER MIE LE TUE MASTURBAZIONI MENTALI. Chiaro?
questo non esula dal fatto che aggiungere l'SMT sul P-M o sul K8 potrebbe aumentare a gratis le prestazioni, come affermato dall'articolo di Jon "hannibal" Stokes
E chi l'hai mai negato questo? Non ho mai detto che è impossibile mettere l'HT sugli Athlon e i Pentium-M: semplicemente che non è conveniente farlo, come puoi leggere.

Ma il problema è che con te la cultura in materia e l'italiano sono un optional... :rolleyes:

Non so se ci sei o ci fai. Se ci sei, amen: la natura è stata ingenerosa. Se ci fai, stai diventando rivoltante coi tuoi squallidi tentativi di manipolazione delle parole degli altri...

beh se è per questo...

** fesseria **
vedi articolo postato da me e leoneazzurro
Fesseria cosa? Quel che ho scritto è verissimo.
** fesseria **
la pipe corta non comporta nulla (vedi power5 e vedi articolo di arstechnica) perchè l'SMT puo' essere usato anche per riempire la pipe in larghezza e non solo in profondità.
Idem come sopra, e t'ha risposto anche leoneazzurro. Inoltre l'ho specificato chiaramente: GLI ATHLON / 64 (in quella frase che hai malamente estrapolato) e i Pentium-M (nella mia prima risposta).
A rigor di ragionamento tutte le considerazioni fatte da cidimauro (perchè te in realtà più che cambiare discorso non hai fatto)
Finora è stato ampiamente dimostrato che il manipolatore delle informazioni sei proprio tu.
sono sempre in relazione al costo che ha implementare l'HT, su cui per ora nessuno ha detto nulla,
Secondo te gli ingegneri di AMD sono così stupidi da non aver pensato e simulato l'HT sugli Athlon64? Avranno fatto i loro conti, no?
perchè se non ha costi proibitivi anche un solo 5% in più di prestazioni farebbero gola anche a un K8,
Vedi sopra: sempre che di 5% si tratti...
soprattutto nei bench e non si esclude di vedere accoppiato un SMT assieme ai prossimi core K9 abbinato alle tecnologie di virtualizzazione (pacifica, clone della vanderpool di intel)
Mai visto in nessuna roadmap di AMD.
Quindi prima di cimentarti in argomenti nei quali non sai dove andare a parare per favore, evita di flammare inutilmente.
:rotfl: Ma senti chi parla: non sai nemmeno com'è implementato il "northbridge" dei processori dual core di AMD e ti lasci andare a sparate sui P4 dual core che non hanno né testa né piedi... :mc:

Fx sinceramente ma non ti senti un po' ignorato a fare tutte delle domande inutili su un discorso che è chiaro e limpido come il mare della costa azzurra?
Per tutti gli altri sì: sei l'unico che non fa che commettere strafalcioni ricordando male o riportando pezzi di un discorso tralasciando tutto il resto... :mc:
Tutte le risposte a questo topic sono scritte nell'articolo di ArsTechnica, che non è quello che dico io è semplicemente quello che pensa una persona che lavora per uno dei siti di riferimento sull'Hardware e che io ho semplicemente citato qua (http://www.hwupgrade.it/forum/showpost.php?p=8207260&postcount=45). Quindi leggilo e non divagare inutilmente. Se non capisci l'inglese fatti tradurre da qualcuno l'articolo e via... non ho voglia di mettermi a discutere con te che tendi sempre a girare il discorso su argomenti non pertinenti.
Leggilo anche tu: nelle sue considerazioni generali il buon "Hannibal" ha dimenticato che l'HT è stato implementato la prima volta sui Northwood, che di stadi di pipeline ne avevano 20. Decisamente meno rispetto ai 31 del Prescott, che era al centro della sua discussione. Secondo te questo cosa vuol dire?

Non è proprio vero: il Power4/PPC970 (che ha 16 stadi, uno meno del massimo del K8 che sono 17) ha una feature che si chiama super-threading, ma fa la stessa cosa che fa il P4 garantendo tipicamente qualcosina in prestazioni in più nel multi threading.
http://www.answers.com/main/ntquery;jsessionid=3njeikumoudj8?method=4&dsid=2222&dekey=Simultaneous+multithreading&gwp=8&curtab=2222_1&sbid=lc02a

Il Power5 idem.
Dimenticavo il "famoso" "super-threading" dei Power4/PPC970: stiamo ancora aspettando documentazione da parte tua su questa panzana che hai scritto... :asd:

cidimauro scrivi e ripeti con me: "oggi ho imparato una cosa nuova: l'hyperthreading non serve solo a riempire gli stalli delle pipe disastrosamente lunghe del P4, ma anche a sfruttare varie unità di esecuzione inutilizzate nelle architetture dove gli stalli sono pochi"

:asd:

ossignur... il fatto che l'HT o equivalente serva:
- a riempire meglio le pipeline laddove c'è un processore con le pipeline lunghe
- a sfruttare meglio le unità elaborative del processore laddove c'è un processore molto vasto

mi sembra fosse CHIARISSSIMO, peccato che fosse ALTRETTANTO CHIARO che si stesse parlando di ATHLON 64 e PENTIUM M, quindi ogni parola spesa sul secondo aspetto - che hai tirato fuori solo per svicolare e glissare - è OFF-TOPIC.

cmq fantastico, cdimauro, hai imparato qualcosa di nuovo... tu? :muro:

ossignur... il fatto che l'HT o equivalente serva:
- a riempire meglio le pipeline laddove c'è un processore con le pipeline lunghe
- a sfruttare meglio le unità elaborative del processore laddove c'è un processore molto vasto
http://dreadnought.ngi.it/smiles/certo.gif ceeeeerto http://dreadnought.ngi.it/smiles/certo.gif

infatti cidimauro nella sua prima risposta ha subito considerato la seconda alternativa iniziando a parlare diretto come un missile :O degli stalli della pipe lunga dle prescott che durano molti clock e si è completamente dimenticato che l'HT viene usato anche sulle pipe (corte), dove gli stalli durano pochi clock, :)
Arrampicandosi poi sul fatto che il power5 ha 23 stadi o 21 o quanti ne vuoi, che non ha importanza, ma quel che conta è che ha molte unità di esecuzione.

Mi manca lo smile :sisi:

infatti cidimauro nella sua prima risposta ha subito considerato la seconda alternativa iniziando a parlare diretto come un missile :O

santi numi, parlare con un mulo sarebbe più proficuo

A: la delta integrale aveva una coppia esagerata
dread: ma se oggi ci sono macchine con cilindrata inferiore che hanno più coppia
A: se ci sono si contano sulla punta delle dita
dread: nono, ce ne sono a pacchi
A: fammi un esempio
dread: la focus turbodiesel
A: ma si stava parlando della delta integrale A BENZINA, ci credo che per i diesel il discorso sia diverso
dread: eh di qui eh di là io ho studiato io le so tutte non capisci un cazzo con te non ci parlo
fx: ciccio, si stava parlando di benzina... che c'entra il diesel? lo sappiamo tutti che i diesel hanno una coppia esagerata
dread: ceeeeeerto, tant'è che nel suo primo post A non l'ha nemmeno considerato il diesel

:muro: :muro: :muro: :muro: :muro: :muro: :muro: :muro: :muro: :muro: :muro:

se non cogli il punto, dread, PREOCCUPATI

:doh: :mbe:
ma che sono ste storie????

BYEZZZZZZZZZZZZ

Cominciamo a mettere la questione in chiaro e a darci un taglio una volta per tutte.

IN PRINCIPIO

Tutto è partito da questa frase:
Scusa, perchè AMD non potrebbe mettere una soluzione simile all'HT di intel?
e dalla mia risposta:
Perché l'HT sfrutta proprio il fatto che in una CPU con un numero elevato di stadi, è facile che la pipeline vada in stallo. Quando ciò si verifica l'esecuzione (e le risorse non impegnate) passa al secondo thread, che può continuare ad andare avanti.

Invece gli Athlon / 64 hanno una pipeline più corta, quindi più efficiente e che molto più raramente va in stallo, per cui si avvantangerebbe ben poco dell'HT, a fronte di un aumento della complessità del processore.

LE BASI DELLA DISCUSSIONE

Quindi:

1) il contesto della discussione era l'applicabilità o meno di una tecnologia simile all'HT a un certo processore (esistente);
2) è pacifico (l'ha detto anche leoneazzurro e mi sembra che tutti eravamo d'accordo) che un'architettura con una pipeline più lunga è più penalizzata di una pipeline più corta nei momenti di stallo;
3) l'HT si avvantaggia degli stalli (è per questo che è stata pensata: sfruttare gli stalli per migliorare l'uso delle risorse che, altrimenti, rimarrebbero inutilizzate);
4) le cause degli stalli possono essere diverse: branch misprediction, dipendenza dei risultati, attesa di un dato dalla memoria, mancanza di unità d'esecuzione disponibile, ecc.
5) un processore con pipeline corta generalmente punta sull'efficienza / IPC anziché sulla frequenza di lavoro, per cui le sue risorse (unità di esecuzione, predittore di salti, cache, ecc.) sono "calibrate" per far sì che la pipeline rimanga quasi sempre "piena", e per eseguire quante più istruzioni possibili per ciclo di clock;
6) un processore con pipeline lunga generalmente punta sulla frequenza di lavoro raggiungibile e non sull'efficienza / IPC; quindi le sue risorse sono calibrate per raggiungere questi obiettivi; però non si possono fare miracoli (ad esempio non esiste il predittore di salti perfetto e la memoria è la stessa usata nei processori con pipeline più corta), per cui eseguono meno istruzioni per ciclo di clock (si cerca di compensare con la maggior frequenza, ovviamente) e si verificano più stalli nella pipeline;

Questa è (grossolanamente) la base su cui ci si confronta: penso che tutti dovrebbero essere d'accordo.

LE QUESTIONI SOLLEVATE

Passiamo alle questioni sollevate.

1) Quest'affermazione: "Power4/PPC970 (che ha 16 stadi, uno meno del massimo del K8 che sono 17)" è completamente priva di senso. Se si devono fare dei confronti sugli stadi di pipeline dei processori, li si deve fare PARLANDO DELLE STESSE COSE, e sempre tenendo bene in mente che si sta anche parlando di architetture con ISA COMPLETAMENTE DIVERSO (cosa che, a quanto pare, sfugge facilmente).
Quindi se stiamo parlando della PIPELINE INTERA, si devono prendere i 12 stadi del K8 con i 16 del Power4/PPC970, coi 20 stadi del P4 Willamette/Northwoord e i 31 del P4 Prescott.

2) Dai dati di cui sopra, si evince che:
a) rispetto al K8, il Power4/PPC970 ha il 33% di stadi di pipeline in più;
b) rispetto al K8, il P4 Northwood ha il 66% di stadi di pipeline in più;
c) rispetto al K8, il P4 Prescott ha il 158% di stadi di pipeline in più;
d) rispetto al Power4/PPC970, il P4 Northwood ha il 25% di stadi di pipeline in più;
e) rispetto al Power4/PPC970, il P4 Prescott ha il 93% di stadi di pipeline in più.

3) I dati di cui sopra fanno capire perché un'architettura come quella dei K8 è DECISAMENTE MENO PENALIZZATA dagli stalli delle pipeline rispetto a quella del P4 (qualunque esso sia). Questo per rispondere alla domanda iniziale ("perchè AMD non potrebbe mettere una soluzione simile all'HT di intel?"), stante all'attuale implementazione di K8, e dei vari P4.
Anche il confronto con il Power4/PPC970 gioca a favore dei K8, pur se in misura minore rispetto ai P4.
Non solo: il confronto fra K8 e P4 non è certo lo stesso che fra Power4/PPC970 e P4. Stiamo parlando di 66% e 158% stadi di pipeline in più, contro 25% e 93%.

4) "Hannibal" ha incentrato il suo discorso su Power5 e P4 (nel link che è stato postato), ma facendo sempre riferimento al Prescott e mai al Northwood, che pure ha implementato per la prima volta l'HT.
Questo è un dettaglio molto importante, perché il Northwood ha MOLTI MENO stadi di pipeline rispetto al Prescott (20 contro 31), ma implementa comunque l'HT appunto.
Tra l'altro Willamette e Northwood HT hanno gli stessi stadi di pipeline (20): Intel non ne ha aggiunto NESSUNO con l'HT. Lo stesso ha fatto IBM passando dal Power4 al Power5. Quindi

5) Northwood e Power4/PPC970 sono abbastanza simili, e questo anche per ammissione di "Hannibal": lui stesso quando ha fatto l'articolo sul PPC970 ha analizzato il "lavoro utile" svolto dai vari stadi di pipeline di entrambi i processori, e ha scritto chiaramente ciò, evidenziando come gli stadi di pipeline aggiuntivi del P4 servano esclusivamente per far arrivare i segnali in tutte le parti del chip, quindi per permettere al P4 di salire maggiormente in frequenza (come si è verificato, infatti).

Riporto qui di seguito link e pezzi dell'articolo in questione.

http://arstechnica.com/articles/paedia/cpu/ppc970.ars/2
"On a final note, I should point out one reason that the 970's pipeline is a little shorter than the P4's: the 970's pipeline lacks the "drive" stages, which the P4 inserts in order to allow signals to propagate across the chip. Inserting whole pipeline stages just to account for wire delay is necessary only if you plan to push a design to insanely high clock speeds. The PowerPC 970's GHz rating, then, will top out at a much lower number than will the P4's."

6) Sempre "Hannibal" fa notare che il PPC970 (e quindi il Power4: d'ora in poi mi riferirò indistintamente all'uno e all'altro), a causa della lunghezza delle pipeline, è maggiormente soggetto a stalli nella pipeline (rispetto al G4, che ha delle pipeline molto più corte). Sempre dal link di cui sopra (parlando della quantità di cache L1, e misura minore della L2):
"The table above shows that the 970 packs a larger instruction cache than the G4e. This is because the 970's pipeline is roughly twice the length of the G4e's, which means that like the P4 the 970 pays a much higher performance penalty when its pipeline stalls due to a miss in the I-cache. (You might recall the animated pipeline diagram from my first P4 vs. G4e article; it shows how a pipeline bubble wastes more resources in a long pipeline than it does in a short one. Check out the page that it's on for more on pipeline depth and cache miss penalties.) In short, the 970's 64KB I-cache is intended to keep pipeline bubbles out of the chip's pipeline."

7) Da tutto ciò si deduce che il PPC970 è meno efficiente del suo predecessore (che ha le pipeline molto più corte) sul campo degli interi. Infatti egli stesso aggiunge alla fine di quel link:
"When you combine the 970's 32KB d-cache with its sizable 512KB L2, its 900MHz DDR frontside bus and its support for up to 8 data prefetch streams, then you can see that this chip was made for floating-point- and SIMD-intensive media applications. It should go almost without saying that this chip will perform better on Altivec (or "VMX") code than the G4e just based on these features alone."

Sia ben chiaro: "Hannibal" non dice QUI esplicitamente che il PPC970 è meno efficiente sugli interi a causa della pipeline lunga. Questa è una mia deduzione, in base a quanto scritto prima e a quello che scriverò dopo. E' importante, però, sottolineare come, dal suo punto di vista, il PPC970 sia un processore orientato a questo tipo di calcoli, che notoriamente sono DECISAMENTE MENO SOGGETTI A STALLI NELLA PIPELINE.

8) Che il PPC970 sia meno efficiente sugli interi lo si deduce ANCHE da questi link: http://arstechnica.com/articles/paedia/cpu/ppc970.ars/4 e http://arstechnica.com/articles/paedia/cpu/ppc970.ars/5, che v'invito a leggere. In particolare riporto una parte che sintetizza ciò di cui si parli nei suddetti:
"The 970's big tradeoff is that it needs less logic to support its long pipeline and extremely wide execution core, but in return it has to give up a measure of granularity, flexibility, and control over the dispatch and issuing of its instructions. Depending on the makeup of the instruction stream and how the IOPs end up being arranged, the 970 could possibly end up with quite a few groups that are either mostly empty, partially empty, or stalled waiting for execution resources.

So while the 970 may be theoretically able to accommodate a whopping 200 instructions in varying stages of fetch, decode, execution and completion, the reality is probably that under most circumstances a decent number of its valuable execution slots will be empty on any given cycle due to dispatch, scheduling, and completion limitations. The 970 makes up for this with the fact that it just has so many available slots that it can afford to waste some on group-related pipeline bubbles."

9) Da tutto ciò risulta evidente che per "Hannibal" tra P4 e PPC970 (e quindi Power4) ci siano molte affinità. Le affinità che ci interessano sono, chiaramente, quelle che sono sfruttabili da una tecnologia come l'HT.
A tal proposito è bene sottolineare che Intel ha dichiarato che la tecnologia HT utilizza il 5% del die del processore (se non erro è la stessa percentuale di core usata da AMD per estendere a 64 bit l'architettura degli Athlon): una piccola percentuale, quindi, anche se significativa (non è certo della cache L2 che stiamo parlando, ma di logica di controllo).
D'altra parte l'obiettivo è quello di utilizzare meglio le risorse già disponibili, cercando di non complicare eccessivamente il core.

10) Al contrario di Intel, quando IBM ha progettato il successore del Power4, il Power5, gli obiettivi da raggiungere erano ben diversi: http://arstechnica.com/articles/paedia/cpu/POWER5.ars
"General design goals

According to Pattnaik, there are three goals that the POWER5 team focused on: performance, flexibility, and reliability. There has been a lot written in publicly-available sources about the first two, so I didn't ask for any elaboration on them. POWER5's benchmark scores speak for themselves, and on the flexibility front IBM has been touting POWER5's advanced virtualiziation technology and other enterprise-level features"

IBM ha, quindi, introdotto una tecnologia simile all'HT nel Power5, ma con una differenza sostanziale rispetto a Intel: occupa ben il 24% del core! E' evidente che non si tratta semplicemente di voler utilizzare meglio le risorse disponibili, ma di realizzare qualcosa che va decisamente oltre.
Infatti, oltre all'SMT, Power5 introduce molte migliorie al Power4: http://arstechnica.com/articles/paedia/cpu/POWER5.ars/3 (e pagine seguenti)

"one of IBM's goals in designing the POWER5 was to have all of the optmiziations for POWER4 carry over to the new design. This means that, for better or for worse, instruction latencies (including mispredict latencies and load-use latencies for the L1) must stay the same. Thus IBM has focused on doing other useful work in those delay slots, instead of on eliminating them entirely.
[...]
the POWER5 cache hierarchy has been signficantly overhauled from POWER4+, and it's now very carefully designed and aggressively tuned to work in conjunction with two physical cores and four simultaneously executing threads. In fact a lot of the system's performance advantage over POWER4 and over the competition can be attributed to the design of the cache hierarchy (e.g., increased cache size, increased associativity, on-die L3 support, taking the L3 off the main memory bus)
[...]
POWER5 "lite": a workstation-class POWER5?
...a POWER5 "lite" wouldn't have the same cache heirarchy as POWER5, and as I mentioned above this memory heirarchy accounts for a large part of POWER5's performance. So the POWER5 derivative's performance – especially in SMT mode – would be significantly constrained by the redesigned cache heirarchy and reduced memory bandwidth."

In definitiva, il massiccio potenziamento del Power5 ha un obiettivo ben preciso: "He also made it clear that he is and has been focused on POWER5 servers only".

CONCLUSIONI

1) All'origine della discussione c'era l'applicabilità o meno di una tecnologia come l'HT a un processore ESISTENTE.
2) E' evidente che è conveniente farlo, ma con architetture con pipeline lunghe.
3) E' evidente che architetture con pipeline corte beneficeranno poco o niente dall'uso dell'HT, a fronte di un aumento della complessità del chip; inoltre è bene ricordare che l'HT non produce soltanto aumenti prestazionali, ma spesso anche perdite a causa dei conflitti di attribuzione delle risorse.
4) E' chiaro che sarebbe da stupidi progettare un processore con un eccessivo numero di risorse disponibili (unità di esecuzione, numero e quantità delle varie cache, stack dei registri di rename, code di esecuzione, ecc. ecc.) a fronte degli OBIETTIVI CHE CI SI E' PREPOSTI: molte risorse risulterebbero SPRECATE la maggior parte del tempo, e le risorse COSTANO (silicio e transistor non li regala nessuno).
5) E' chiaro che è possibile progettare un processore con pipeline corte e molte risorse disponibili da dare in pasto a più thread: nessuno lo vieta, ma di certo NON ci troveremmo di fronte a un "semplice" tentativo di utilizzare meglio le risorse GIA' DISPONIBILI, che è ciò che poi è stato fatto con l'HT finora.
6) Power5 non è solamente un Power4 a cui hanno aggiunto l'SMT e aumentato un po' la cache; indubbiamente trae le sue origini dal suo predecessore, ma è stato NOTEVOLMENTE POTENZIATO per raggiungere gli obiettivi che IBM s'era posta: performance estremamente elevate, flessibilità (tanti dettagli dell'SMT si possono controllare tramite il s.o.) e affidabilità.
7) Oltre a tutto ciò, è bene considerare che Power e x86 sono architetture con ISA completamente diverse, per cui il codice che eseguono è diverso ed è soggetto a limitazioni diverse: le 5 istruzioni per ciclo di clock dei Power4/5/PPC970 possono impressionare, ma si tratta di istruzioni (RISC) che hanno poco a che spartire con quelle (CISC) degli x86, non possono essere istruzioni qualunque (anche gli x86 hanno limitazioni simili, ma meno rigide) e occupano molto più spazio (in 32 byte, che è lo spazio occupato da 8 istruzioni PowerPC, possono essere presenti fino a 32 istruzioni x86).

Per il momento è tutto: passo la palla agli altri. ;)

P.S. Scusate la lunghezza del messaggio, ma mi piace essere molto preciso. :D

E' inutile che scrivi papiri se:

Sbagli le basi...

3) l'HT si avvantaggia degli stalli (è per questo che è stata pensata: sfruttare gli stalli per migliorare l'uso delle risorse che, altrimenti, rimarrebbero inutilizzate);
Non è affatto così, l'SMT non ha bisogno di stalli per funzionare, almeno non concettualmente e non con un esecuzione OoO.

2) è pacifico (l'ha detto anche leoneazzurro e mi sembra che tutti eravamo d'accordo) che un'architettura con una pipeline più lunga è più penalizzata di una pipeline più corta nei momenti di stallo;
Non è vero, esempio già introdotto: il Power5, ha un pipe corta, ma quando stalla è penalizzato anche più di un P4 in termini di potenza assoluta non utilizzata.

...perchè di conseguenza trai conclusioni errate.

E' inutile che scrivi papiri se:
E' inutile che li leggi, se poi non riesci a digerirli: poi ti fa male la pancia...
Sbagli le basi...
Non credo proprio.
Non è affatto così, l'SMT non ha bisogno di stalli per funzionare, almeno non concettualmente e non con un esecuzione OoO.
Vedi sopra: se leggi delle cose senza acquisirne conoscenze, rischi di non capirne il significato. Ecco qua un po' di sano copia & incolla:

1) il contesto della discussione era l'applicabilità o meno di una tecnologia simile all'HT a un certo processore (esistente);
3) l'HT si avvantaggia degli stalli (è per questo che è stata pensata: sfruttare gli stalli per migliorare l'uso delle risorse che, altrimenti, rimarrebbero inutilizzate);

1) All'origine della discussione c'era l'applicabilità o meno di una tecnologia come l'HT a un processore ESISTENTE.
2) E' evidente che è conveniente farlo, ma con architetture con pipeline lunghe.
3) E' evidente che architetture con pipeline corte beneficeranno poco o niente dall'uso dell'HT, a fronte di un aumento della complessità del chip; inoltre è bene ricordare che l'HT non produce soltanto aumenti prestazionali, ma spesso anche perdite a causa dei conflitti di attribuzione delle risorse.
4) E' chiaro che sarebbe da stupidi progettare un processore con un eccessivo numero di risorse disponibili (unità di esecuzione, numero e quantità delle varie cache, stack dei registri di rename, code di esecuzione, ecc. ecc.) a fronte degli OBIETTIVI CHE CI SI E' PREPOSTI: molte risorse risulterebbero SPRECATE la maggior parte del tempo, e le risorse COSTANO (silicio e transistor non li regala nessuno).
5) E' chiaro che è possibile progettare un processore con pipeline corte e molte risorse disponibili da dare in pasto a più thread: nessuno lo vieta, ma di certo NON ci troveremmo di fronte a un "semplice" tentativo di utilizzare meglio le risorse GIA' DISPONIBILI, che è ciò che poi è stato fatto con l'HT finora.

Quest'ultima, in particolare, risponde direttamente alla questione da te sollevata.
Non è vero, esempio già introdotto: il Power5, ha un pipe corta, ma quando stalla è penalizzato anche più di un P4 in termini di potenza assoluta non utilizzata.
Come sopra. In particolare:

1) Power4, PPC970 e Power5 hanno la stessa lunghezza delle pipeline (il PPC970 qualcuno in più per l'Altivec);
2) la loro pipeline è "lunga"; ecco un altro po' di sano copia & incolla di ciò dice un certo "Hannibal" che dovresti conoscere bene:

"On a final note, I should point out one reason that the 970's pipeline is a little shorter than the P4's"

the 970's pipeline is roughly twice the length of the G4e's, which means that like the P4 the 970 pays a much higher performance penalty when its pipeline stalls due to a miss in the I-cache.

a pipeline bubble wastes more resources in a long pipeline than it does in a short one."

Quindi, come vedi, la pipeline di Power5, esattamente come quella di Power4 e (quasi) come del PPC970, è considerata "lunga".
...perchè di conseguenza trai conclusioni errate.
Vedi sopra: mi sembra che qui l'unico che lo fa con constanza sei proprio tu...

Interessante, evidenzi degli articoli solo quello che ti fa comodo :)

Questo dove lo lasci?
The answer is that the POWER5 is extremely wide, (wide non vuol dire LUNGA, ma LARGA) pipeline stalls translate not into tons of unused clock cycles but tons of unused execution hardware. Or, here's another way of phrasing it: in the event of a pipeline stall, Prescott has a few execution units sitting idle over a large number of clock cycles; the POWER5 has a large number of execution units sitting idle over a few clock cycles. Either way you slice it, that's wasted resources.

E questo?
IBM's POWER5 uses hyperthreading, and it certainly doesn't have the outrageous 31-stage pipeline length of Prescott. In fact, the POWER5's 16-stage pipeline isn't much longer than the Pentium M's speculated pipeline length of 12 to 14 stages. I say this only to illustrate the point that there's nothing in the lower number of pipeline stages that somehow magically makes the Pentium M a poor candidate for hyperthreading.
OH tu guarda ha detto tutto l'opposto di quello che hai appena evidenziato :)

Stai continuando per la tua strada non considerando che molto di quello che hai detto è privo di apertura mentale, sei fissato sulla tua conoscenza dell'HT nel P4 e non sai dove andare a parare quando si parla del concetto generale di SMT.

Leggiti un po' di articoli sull'SMT e vedrai che anche pipe corte tipo 8-9 stadi, se ben progettate possono tranquillamente integrarlo, migliorando gli IPC da 0.5-0.7 come il P4 in condizioni normali a valori più vicini a 0.9-1.0

Quindi niente vieta di integrare una soluzione SMT ben più funzionale dell'HT in cpu come Athlon 64 o Pentium-M e di trarne vantaggi anche non minimi -come del resto ha affermato stokes nel suo articolo- che pero' tu hai evidentemente glissato per evitare di contraddirti da solo :)

Leggiti un po' di articoli sull'SMT e vedrai che anche pipe corte tipo 8-9 stadi, se ben progettate possono tranquillamente integrarlo, migliorando gli IPC da 0.5-0.7 come il P4 in condizioni normali a valori più vicini a 0.9-1.0

si, spariamo numeri a caso... per cortesia, mi dici un processore da 8-9 stadi OoO che con l'hyperthreading, il super threading o tecnologia equivalente passa da un IPC di 0.5 a 1.0? (un incremento del 100%, minchia, nemmeno un dual core fa tanto... ma anche fosse da 0.5 a 0.9)

si, non ho voglia di andare a leggere "un po' di articoli sull'SMT", dimmelo tu dai


ps: complimenti anche a chi progetta una cpu con un botto di unità di calcolo, 8-9 stadi di pipeline e un IPC di 0.5

Fx non ci siamo intesi, il P4 ha ipc attorno a 0.5-0.7.

Come ho già detto nell'altro thread, a meno di non usare le unita SSE non penso che una cpu x86possa superare 1 di IPC, l'IPC è un dato che tra il teorico e il pratico è completamente differente.
Io sono convinto che in alcuni bench qualche modello di P4 riesce ad avere anche IPC minore di 0.5

Poi non è che ci vuole molto, un P3-T a parità di frequenza del vecchio P4 andava di più in quasi tutti i bench, ci sarà un motivo no?
E il pentium3 come avrebbe fatto ad avere ipc maggiore di 1 se ha la pipeline che fa una istruzione alla volta?

Con una pipeline unica non puoi avere un IPC maggiore di 1 ammesso che gli stadi non avanzino ogni mezzo ciclo di clock oppure due per volta. Il fatto che il p4 ha il rapid execution engine mica vuol dire che puo' avere IPC=2.

E nemmeno il fatto di avere 4-5-10-20 unità di esecuzione puo' migliorare l'IPC, almeno non fino a che la pipeline è unica ed avanza un ciclo per clock, al massimo le varie unità di exec riempiono gli stalli che si creano per alcune istruzioni, ma fino ad un certo punto, perchè quando carichi le istruzioni dalla ram o dall'HD perchè la cache sta finendo, butti via palate di cicli senza eseguire nulla.

Interessante, evidenzi degli articoli solo quello che ti fa comodo :)
Guarda che io non ho niente da nascondere: porta pure tutto il materiale che vuoi, non c'è problema... ;)
Questo dove lo lasci?
The answer is that the POWER5 is extremely wide, (wide non vuol dire LUNGA, ma LARGA) pipeline stalls translate not into tons of unused clock cycles but tons of unused execution hardware. Or, here's another way of phrasing it: in the event of a pipeline stall, Prescott has a few execution units sitting idle over a large number of clock cycles; the POWER5 has a large number of execution units sitting idle over a few clock cycles. Either way you slice it, that's wasted resources.
Chi ha mai negato che il Power5 avesse molte unità di esecuzione? Nessuno, mi pare. Ciò non toglie che, come ti ho già mostrato nel precedente messaggio, "Hannibal" stesso considera la pipeline di Power4/PPC970/Power5 LUNGA: è scritto chiaramente, nero su bianco. E scrive anche che è simile a quella del P4 (Northwood, per inciso).
E questo?
IBM's POWER5 uses hyperthreading, and it certainly doesn't have the outrageous 31-stage pipeline length of Prescott. In fact, the POWER5's 16-stage pipeline isn't much longer than the Pentium M's speculated pipeline length of 12 to 14 stages. I say this only to illustrate the point that there's nothing in the lower number of pipeline stages that somehow magically makes the Pentium M a poor candidate for hyperthreading.
OH tu guarda ha detto tutto l'opposto di quello che hai appena evidenziato :)
No, è il contesto che è diverso, e ne avevo già parlato prima:

4) "Hannibal" ha incentrato il suo discorso su Power5 e P4 (nel link che è stato postato), ma facendo sempre riferimento al Prescott e mai al Northwood, che pure ha implementato per la prima volta l'HT.
Questo è un dettaglio molto importante, perché il Northwood ha MOLTI MENO stadi di pipeline rispetto al Prescott (20 contro 31), ma implementa comunque l'HT appunto.

Come vedi tutto quadra perfettamente. ;)
Stai continuando per la tua strada non considerando che molto di quello che hai detto è privo di apertura mentale,
Finora è l'esatto contrario: sei tu quello che si ostina a non voler capire. Se non arrivi a capire neppure una cosa banale come quella che esistono DUE P4, il Northwood e il Prescott, che implementano ENTRAMBI l'HT, ma il primo ha 20 stadi (ed è quindi simile al Power5, come scrive "Hannibal"), e il secondo ben 31 (e per forza di cose, a confronto col Power5, la sua pipeline viene definita "lunga"), c'è qualcosa che non va in te...
sei fissato sulla tua conoscenza dell'HT nel P4 e non sai dove andare a parare quando si parla del concetto generale di SMT.
Bene, allora visto che hai la scienza infusa, non ti sarà difficile spiegarmelo tu, facendo sempre riferimento al CONTESTO DELLA DISCUSSIONE, ovviamente.
Leggiti un po' di articoli sull'SMT e vedrai che anche pipe corte tipo 8-9 stadi, se ben progettate possono tranquillamente integrarlo, migliorando gli IPC da 0.5-0.7 come il P4 in condizioni normali a valori più vicini a 0.9-1.0

Quindi niente vieta di integrare una soluzione SMT ben più funzionale dell'HT in cpu come Athlon 64 o Pentium-M e di trarne vantaggi anche non minimi -come del resto ha affermato stokes nel suo articolo- che pero' tu hai evidentemente glissato per evitare di contraddirti da solo :)
Veramente sei tu che leggi i papiri, ma a quanto pare non li digerisci proprio:

1) All'origine della discussione c'era l'applicabilità o meno di una tecnologia come l'HT a un processore ESISTENTE.
3) E' evidente che architetture con pipeline corte beneficeranno poco o niente dall'uso dell'HT, a fronte di un aumento della complessità del chip; inoltre è bene ricordare che l'HT non produce soltanto aumenti prestazionali, ma spesso anche perdite a causa dei conflitti di attribuzione delle risorse.
4) E' chiaro che sarebbe da stupidi progettare un processore con un eccessivo numero di risorse disponibili (unità di esecuzione, numero e quantità delle varie cache, stack dei registri di rename, code di esecuzione, ecc. ecc.) a fronte degli OBIETTIVI CHE CI SI E' PREPOSTI: molte risorse risulterebbero SPRECATE la maggior parte del tempo, e le risorse COSTANO (silicio e transistor non li regala nessuno).
5) E' chiaro che è possibile progettare un processore con pipeline corte e molte risorse disponibili da dare in pasto a più thread: nessuno lo vieta, ma di certo NON ci troveremmo di fronte a un "semplice" tentativo di utilizzare meglio le risorse GIA' DISPONIBILI, che è ciò che poi è stato fatto con l'HT finora.

Quest'ultimo punto, in particolare, risponde esattamente a quello che hai scritto tu. Soltanto che tu ti ostini a ignorare i rimanenti punti che ho elencato nuovamente.
La discussione su cu cosa verteva? L'hai già dimenticato, o stai facendo lo gnorri? Rileggeti per benino il "papiro", o tutto il thread se vuoi, e magari riesci a riprendere il filo della discussione...

Come ho già detto nell'altro thread, a meno di non usare le unita SSE non penso che una cpu x86possa superare 1 di IPC, l'IPC è un dato che tra il teorico e il pratico è completamente differente.
Mi spieghi come farebbe il P4 ad avere un IPC > 1 usando le SSE?
Con una pipeline unica
Cosa intendi con ciò?

cidimauro, prima fai il ganzo e ti cimenti in risposte da programmatore di codice assembler x86 e poi non sai come funzionano le SSE?

quindi tutto quello che posti te lo inventi?

Fx non ci siamo intesi, il P4 ha ipc attorno a 0.5-0.7.

Come ho già detto nell'altro thread, a meno di non usare le unita SSE non penso che una cpu x86possa superare 1 di IPC, l'IPC è un dato che tra il teorico e il pratico è completamente differente.
Io sono convinto che in alcuni bench qualche modello di P4 riesce ad avere anche IPC minore di 0.5

Poi non è che ci vuole molto, un P3-T a parità di frequenza del vecchio P4 andava di più in quasi tutti i bench, ci sarà un motivo no?
E il pentium3 come avrebbe fatto ad avere ipc maggiore di 1 se ha la pipeline che fa una istruzione alla volta?

Con una pipeline unica non puoi avere un IPC maggiore di 1 ammesso che gli stadi non avanzino ogni mezzo ciclo di clock oppure due per volta. Il fatto che il p4 ha il rapid execution engine mica vuol dire che puo' avere IPC=2.

E nemmeno il fatto di avere 4-5-10-20 unità di esecuzione puo' migliorare l'IPC, almeno non fino a che la pipeline è unica ed avanza un ciclo per clock, al massimo le varie unità di exec riempiono gli stalli che si creano per alcune istruzioni, ma fino ad un certo punto, perchè quando carichi le istruzioni dalla ram o dall'HD perchè la cache sta finendo, butti via palate di cicli senza eseguire nulla.

bene la teoria, ma in pratica qualsiasi cpu moderna può eseguire, senza HT nè un cazzo, più istruzioni per ciclo di clock. tra l'altro ti basterebbe prendere un pentium m o un athlon 64, fai la proporzione in hz, e poi moltiplichi l'IPC del pentium 4 per quello che esce, e scoprirai che va anche oltre l'1 in diversi casi... dando per buono un IPC di 0.5 / 0.7, che detto così vuol dire nulla: l'IPC lo devi anche contestualizzare a qualche tipo di operazioni, a fare una cosa una cpu può avere un IPC basso ma a farne un'altra uno alto

a questo si aggiunge un'altra cosetta... domanda: secondo te nelle pipeline ci finiscono le istruzioni x86, in un x86 moderno? =) e le microistruzioni RISC quando vengono impiegate? vengono tradotte dopo la pipeline?

Superare 1.0 di IPC con una CPU come il P4 o un A64 con un programma generico è impossibile. Neanche il Pentium-M con le micro op fusion supera IPC 1.

Altrimenti se sarebbe così semplice aumentare l'IPC aggiungendo stadi di esecuzione che senso avrebbero i dual core?

anzitutto "se fosse"

quindi, stiamo parlando del nulla... l'IPC a far che? l'IPC con che "I" considerate? le "I" x86 o le "I" micro-ops? in entrambi i casi il limite degli x86 è superiore a un'istruzione per ciclo di clock, mi sembra risaputo, no?

IPC intendo instructions per clock, così ci mettiamo d'accordo.

Ma non capisco come possa andare oltre 1 su ad esempio un P4 ma se vuoi puoi anche prendere l'esempio dell'athlon 64.

santi numi, parlare con un mulo sarebbe più proficuo

A: la delta integrale aveva una coppia esagerata
dread: ma se oggi ci sono macchine con cilindrata inferiore che hanno più coppia

avranno più coppia (quali auto con cilindrata inferiore poi?), ma le prendono sicuramente e di brutto dalla Delta :asd: :cool:
scusate l'OT ma la regina è intoccabile :O

LOL :)
grande la delta cque

Fx io dico: ok che con una architettura superscalare puoi come limite massimo suoerare IPC 1, il problema è che in tutti i test che trovo ingiro gli IPC di un p4, di uno xeon o di un K8 vanno da 0.2 a 0.95, e nel caso di uso delle SSE non si supera il 3, considerando pero' che una istruzione SIMD viene applicata su 2/4/8 dati alla volta e contano come più istruzioni parallele eseguite nello stesso momento.

Anche perchè per misurare l'IPC devi iniziare a considerare tutte le code, la banda tra tutte le sezioni del sistema (ram, L2, L1, FSB) le latenze espresse in cicli di clock e tanto altro.

A regime i valori di IPC, soprattutto in ambiente serve sono ridicoli, roba da 0.5 per uno Xeon 64. Ora frugo un po' su google, ma tempo fa non avevo trovato molto.

IPC intendo instructions per clock, così ci mettiamo d'accordo.

Ma non capisco come possa andare oltre 1 su ad esempio un P4 ma se vuoi puoi anche prendere l'esempio dell'athlon 64.

dread, benissimo, sono istruzioni per ciclo di clock, ma non siamo ancora d'accordo perchè c'è da capire QUALI istruzioni per ciclo di clock. istruzioni x86? micro istruzioni RISC? e poi: CHE TIPO di istruzioni? degli XCHG? MOV da memoria a registro? MUL da memoria? XOR? NOP?

per quanto riguarda il limite, ciccio, fai tanto il sapientone e poi mi caschi sulle basi? oppure la sai troppo lunga e pensi che solo con l'hyperthreading un core possa fare più di un'istruzione per ciclo di clock?

E' DALLA NOTTE DEI TEMPI CHE GLI X86 HANNO SFONDATO IL LIMITE DI UN'ISTRUZIONE PER CICLO DI CLOCK, LO SANNO ANCHE I SASSI...

toh, guarda lo schema degli AMD64 così forse capisci come fa... cmq tanto per dirti, i K6 già decodificavano 2 istruzioni per ciclo di clock, i K7 e i P2 erano già a 3.

http://www.chip-architect.net/news/Opteron_MPF_12.jpg

ti consiglio inoltre di leggere un po', ti consiglio due link (ah, se vuoi il tiny url lo trovi su www.google.com)

http://www.dinoxpc.com/Tests/PROCESSORI/P432EE/pag3.asp (qua dice che per l'athlon xp il limite è 9 ma probabilmente intendono istruzioni risc, anche se in teoria che io sappia è 6)

http://arstechnica.com/articles/paedia/cpu/amd-hammer-1.ars/2

http://www.cpuid.org/K8/index.php


dread, ora... perchè non provi ad abbassare le orecchie e ad ammettere tranquillamente che a) non è che sai tutto te b) gli altri non è che sono tutti scemi? sai, quaggiù con noi comuni mortali non è poi così male, se dici "non lo so" nessuno ti prende per il culo, anzi, se il prossimo lo sa ti dice com'è, in tranquillità... se invece intervieni solo quando ti sembra di vedere una svista per bacchettare sai, devi essere molto preciso, e devi saperle veramente tutte, altrimenti se ti si prende in castagna poi... non ne esci bene.

fai il primo passo: dì "non lo sapevo". vedrai che non succede niente.

avranno più coppia (quali auto con cilindrata inferiore poi?), ma le prendono sicuramente e di brutto dalla Delta :asd: :cool:
scusate l'OT ma la regina è intoccabile :O

mica l'ho citata a caso :D

Mi sa che ancora non ci capiamo, innanzitutto l'IPC va considerato in base a mix di istruzioni, o melgio ancora in base al tipo di lavoro che sta eseguendo la CPU, quindi le devi considerare tutte, dal MOV, alle operazioni intere SUB, ADD MUL, alle operazioni sui bit XOR OR NOT, a quelle floating point FMUL FSIN FCOS...

Poi puoi considerare l'IPC con un mix di sole operazioni intere o di sole operazioni FP, per valutare le prestazioni di un sistema e di una CPU nelle sue differenti unità interne.

Come "istruzione" intendo ad esempio una semplice
ADD 5,
ma non a livello di esecuzione nel core ma come trhoughput della CPU stessa.

L'IPC si riferisce alle prestazioni di una CPU nell'ottica di un sistema, quindi al throughput considerando la teoria delle code e le catene di markov. Per questo che con cidimauro nel thread del P4 ero restio a discuterne, perchè sull'IPC si intende sempre tutto e l'opposto di tutto, a seconda se guardi l'aspetto della programmazione, dell'architettura o delle prestazioni.

E' DALLA NOTTE DEI TEMPI CHE GLI X86 HANNO SFONDATO IL LIMITE DI UN'ISTRUZIONE PER CICLO DI CLOCK, LO SANNO ANCHE I SASSI...

Ah vero, infatti se cerchi IPC x86 su google trovi un miliaio di articoli che ti dicono che i P4 e i K8 hanno sfondato la barriera di 1 istruzione per ciclo di clock! ma dai!

scusa ora probabilmente non ci siamo intesi, ma io mi riferisco a test come questi:

Articolo un po' vecchiotto (ipotizzava ancora che uno xeon arrivasse a 5GHz lol) sulla CPU sun
http://www.aceshardware.com/read.jsp?id=65000296
A server with a single 1.3GHz Niagara and IPCs of 0.7-0.8 per core gives 7.28-8.32 billion instructions per second (BIPS). Late in 2005 with large L3 caches and system improvements, a [b]5GHz Xeon might have typical IPCs of 0.4-0.5, which gives 4-5 BIPS. That's still well below Niagara. 2-way Opterons would likely be close though.

Aceshardware fa da una vita test su cpu/server e prestazioni, non sono certo i primi pirla che passano.

Questo link invece è proprio nel nostro caso:
http://www.aceshardware.com/read_news.jsp?id=75000414

e qui trovi il PDF a cui si riferisce
http://tesla.hpl.hp.com/caecw03/chen.pdf

IPC medi in questo caso? 0.6 0.5
Con un minimo di 0.15 che con quel tipo di istruzioni non me lo sarei mai aspettato.


toh, guarda lo schema degli AMD64 così forse capisci come fa... cmq tanto per dirti, i K6 già decodificavano 2 istruzioni per ciclo di clock, i K7 e i P2 erano già a 3.
Un conto è decodificare più istruzioni per clock, (la media del K6-III ho appena letto sempre in un articolo su ace's era 1.7, e del K7 è 2,8) un'altro è riuscire ad eseguirle tutte, avere la banda per eseguirle tutte, e non avere tutti i cache miss che ti creano latenze, e un'altro conto ancora è avere il mix di istruzioni perfetto per riuscire ad infilarlo in tutte le unità di esecuzione.

Lo schema che hai postato non vuol dire niente se guardi al throughput della CPU, se è misurato che con un mix di istruzioni ben pesato il numero di istruzioni che un K7 può decodificare per ciclo di clock è 2,8 vuol dire che al massimo ma proprio come limite teorico il suo IPC sarà 2,8. Il collo di bottiglia è quello, la sezione di fetch/decode della pipe.

http://www.dinoxpc.com/Tests/PROCESSORI/P432EE/pag3.asp (qua dice che per l'athlon xp il limite è 9 ma probabilmente intendono istruzioni risc, anche se in teoria che io sappia è 6)
Secondo me l'IPC non è affatto questo.
Quando mai potresti trovare 9 istruzioni che in uno stesso momento sono attive in un K7 e possono essere inflate ognuna in ogni unità di esecuzione di quelle che vedi.[/quote]

cioè intendiamoci, se prendi in considerazione solo 6 istruzioni isolate potresti avere questo risultato, ma consideando un flusso continuo di istruzioni all'interno della CPU non è possibile.


http://arstechnica.com/articles/paedia/cpu/amd-hammer-1.ars/2

http://www.cpuid.org/K8/index.php
idem qua, stesso discorso che sopra.


dread, ora... perchè non provi ad abbassare le orecchie e ad ammettere tranquillamente che a) non è che sai tutto te b) gli altri non è che sono tutti scemi? sai, quaggiù con noi comuni mortali non è poi così male, se dici "non lo so" nessuno ti prende per il culo, anzi, se il prossimo lo sa ti dice com'è, in tranquillità... se invece intervieni solo quando ti sembra di vedere una svista per bacchettare sai, devi essere molto preciso, e devi saperle veramente tutte, altrimenti se ti si prende in castagna poi... non ne esci bene.

fai il primo passo: dì "non lo sapevo". vedrai che non succede niente.
Ma perchè devi scadere nel "io so di più e tu no"? Piantala per favore, nessuno qua fa a gara a chi sa di più. Ma ti pare che vengo qua a discutere di cose di cui non so nulla :rolleyes: userei il mio tempo in modo migliore non credi?

Se sollevo il dubbio è perchè ho trovato una fonte che me lo ha fatto venir fuori, altrimenti non avrei nemmeno postato no?

Sei pensi che intervengo per "bacchettare" sei proprio sulla strada sbagliata, posto su questo forum da tanti anni, e ho postato anche su altri, ho scritto pure articoli tecnici e non mi interessa di bacchettare la gente (certo con qualche user un po' sprovveduto che mi ha insultato qualche volta ci vado giù pesante, un po' come tu e cidimauro con i fantici appel dle thread dle cell :asd: ), semplicemente se vedo una cosa su cui non sono d'accordo lo dico. E' sbagliato?

all'ultima parte ti rispondo in pm

poi esordisco con una battuta... se 2 post fa non avessi detto a cdimauro che non sa quotare il tuo litigio con le tag sarebbe passato inosservato, ma così capita proprio a fagiolo :ciapet:


per il discorso IPC: sul fatto che l'IPC venga considerato su un uso "tipico" lo so benissimo, però è proprio questo che mi lascia perplesso. se non definisci univocamente il "mix" di cui parli, sai solo che il valore che hai è tra l'IPC minimo e l'IPC massimo per quella cpu, quindi è troppo aleatorio per poter trarre delle conclusioni univoche. se mi contestualizzano l'IPC che so ai vari benchmark che compongono il cpu2000 della SPEC, inizi ad avere delle indicazioni per poter interpretare correttamente il numeretto che te ne esce, se non sai:
a) che istruzioni sono state usate
b) come sono state usate
c) in che ambito sono state usate

addirittura uno stesso algoritmo su una stessa macchina ti può dare due IPC ben diversi se le istruzioni vengono ottimizzate, in particolar modo se vengono ottimizzate specificatamente per il processore che stai utilizzando.

insomma, ci sono troppi fattori, parlare di IPC in termini assoluti e non relativi ripeto è troppo aleatorio. ciò che invece è quello e quello non cambia è l'intervallo: l'IPC minimo e l'IPC massimo quelli sono e quelli rimangono.

qui faccio riferimento al secondo punto del tuo post.

il fatto che una cpu possa decodificare più istruzioni per ciclo di clock non vuol dire certamente che possa eseguirle in un ciclo di clock, certamente: vuol dire, come hai giustamente osservato, che il suo IPC massimo è quello lì. se un AMD64 ha la possibilità di decodificare 3 istruzioni per ciclo di clock, ed è strutturata sotto - come lo è - per poterle elaborare (ovviamente nelle condizioni migliori, posso ipotizzare ad esempio tre XOR su tre registri diversi - lo xor è un modo veloce per azzerare il registro... "XOR EAX, EAX", ad es.) contemporaneamente, il suo IPC massimo sarà 3. questo intendo quando dico che teoricamente l'IPC di un x86 va oltre a 1. poi nell'uso "tipico" non entro nel merito perchè la definizione di uso tipico è un po' troppo vaga, posso dirti solamente che negli anni l'IPC non ha subito grossi stravolgimenti. ed è per questo che si è sempre lavorato sugli hz, e ora che gli hz sono finiti si sta lavorando sul parallelismo: lavorare sull'IPC per ottenere lo stesso risultato è estremamente più difficile.

per quanto riguarda il terzo paragrafo del tuo post (non ho voglia di quotare :D ) riguardo all'athlon xp non si stava parlando dell'IPC medio ma di quello massimo; piuttosto lo spunto interessante che davo era il confronto IPC massimo considerando le istruzioni x86 e IPC massimo considerando le micro istruzioni RISC. considerando queste ultime, si ha un limite di 6 o addirittura di 9 (anche se devo capire perchè :D ), poi senz'altro conta quanto sia "praticabile" perchè ovviamente non contano i picchi ma le medie, però è senz'altro un dato interessante.

aspe che metto a posto, ma il problema di quotare bene non sono le tag :D

Sono d'accordo con il resto, appunto l'IPC dipende da molte cose

Sul dubbio di 9 istruzioni indicate da dinoxpc per l'athlon non sono convinto nemmeno io, più che altro (ipotizzo) mi sa che ha contato in quante parti si dirama pipe nella sezione execute (3AGU + 3ALU + Fmul + Fadd + Fmisc)
E da lì salta fuori il 9, ma non mi pare corretto come ragionamento.

Tra l'altro mi viene un altro dubbio, è normale che mentre la Fadd è attiva possono funzionare anche la Fmul o la Fmisc? Mi sembra un po' strano, pero' senza guardare su eventuali paper/datasheet non saprei andare più avanti di una ipotesi.

http://arstechnica.com/articles/paedia/cpu/pipelining-2.ars/5

Tnx leoneazzurro, mi mancava quella fila di articoli.

cidimauro, prima fai il ganzo e ti cimenti in risposte da programmatore di codice assembler x86 e poi non sai come funzionano le SSE?
Io so bene cosa sono e come funzionano le SSE, e lo stesso vale per l'IPC. Tu, invece, mi sai che hai le idee un po' troppo confuse.
quindi tutto quello che posti te lo inventi?
Non sai dire altro per nascondere la tua ignoranza in materia? :mc:

Superare 1.0 di IPC con una CPU come il P4 o un A64 con un programma generico è impossibile. Neanche il Pentium-M con le micro op fusion supera IPC 1.
Mi fai vedere dove sta scritto? Generalmente, invece, si riesce a superare la singola istruzione eseguita per ciclo di clock. Prova a disassemblare un programma, e ad analizzare le dipendenze fra le istruzioni, il working set, e quando e come i salti condizionali vengono eseguiti o scartati, così magari ti farai un'idea di come lavora un processore "in the real world"...
Altrimenti se sarebbe così semplice aumentare l'IPC aggiungendo stadi di esecuzione che senso avrebbero i dual core?
Cosa intendi con ciò?

Fx io dico: ok che con una architettura superscalare puoi come limite massimo suoerare IPC 1, il problema è che in tutti i test che trovo ingiro gli IPC di un p4, di uno xeon o di un K8 vanno da 0.2 a 0.95, e nel caso di uso delle SSE non si supera il 3, considerando pero' che una istruzione SIMD viene applicata su 2/4/8 dati alla volta e contano come più istruzioni parallele eseguite nello stesso momento.
Considerato che per IPC s'intende "Instruction Per Cycle" e per SIMD "Single Instruction Multiple Data", direi che hai riportato un'informazione che definire inesatta significa volerti fare un complimento...
Anche perchè per misurare l'IPC devi iniziare a considerare tutte le code, la banda tra tutte le sezioni del sistema (ram, L2, L1, FSB) le latenze espresse in cicli di clock e tanto altro.
Quindi si capisce che l'IPC di un processore non è un'informazione misurabile.

Mi sa che ancora non ci capiamo, innanzitutto l'IPC va considerato in base a mix di istruzioni, o melgio ancora in base al tipo di lavoro che sta eseguendo la CPU, quindi le devi considerare tutte, dal MOV, alle operazioni intere SUB, ADD MUL, alle operazioni sui bit XOR OR NOT, a quelle floating point FMUL FSIN FCOS...

Poi puoi considerare l'IPC con un mix di sole operazioni intere o di sole operazioni FP, per valutare le prestazioni di un sistema e di una CPU nelle sue differenti unità interne.
Vedi sopra: in ogni caso non potresti misurare l'IPC.
Come "istruzione" intendo ad esempio una semplice
ADD 5,
Quando imparerai quanto meno i fondamenti dell'architettura x86 e la sintassi delle più semplici e comuni istruzioni? :rolleyes:
ma non a livello di esecuzione nel core ma come trhoughput della CPU stessa.
Non basterebbe.
L'IPC si riferisce alle prestazioni di una CPU nell'ottica di un sistema, quindi al throughput considerando la teoria delle code e le catene di markov.
Cioé? Spiegati meglio.
Per questo che con cidimauro nel thread del P4 ero restio a discuterne, perchè sull'IPC si intende sempre tutto e l'opposto di tutto, a seconda se guardi l'aspetto della programmazione, dell'architettura o delle prestazioni.
Appunto. Allora capisci bene che cercare di misurare l'IPC è una cosa priva di senso, e ancora peggio fornire numeri...
Ah vero, infatti se cerchi IPC x86 su google trovi un miliaio di articoli che ti dicono che i P4 e i K8 hanno sfondato la barriera di 1 istruzione per ciclo di clock! ma dai!
Beh, è proprio così invece. Ovviamente andando a prendere del codice reale. Poi è chiaro che posso costruirti a tavolino un codice che fa scendere l'IPC a valori infimi.
scusa ora probabilmente non ci siamo intesi, ma io mi riferisco a test come questi:

Articolo un po' vecchiotto (ipotizzava ancora che uno xeon arrivasse a 5GHz lol) sulla CPU sun
http://www.aceshardware.com/read.jsp?id=65000296
A server with a single 1.3GHz Niagara and IPCs of 0.7-0.8 per core gives 7.28-8.32 billion instructions per second (BIPS). Late in 2005 with large L3 caches and system improvements, a [b]5GHz Xeon might have typical IPCs of 0.4-0.5, which gives 4-5 BIPS. That's still well below Niagara. 2-way Opterons would likely be close though.

Aceshardware fa da una vita test su cpu/server e prestazioni, non sono certo i primi pirla che passano.
No, ma se non specificano le applicazioni usate per misurare l'IPC, quel che dicono sarà ampiamente criticabile, a prescindere dalla loro fama. In quell'articolo si parla di server, ma in ogni caso non ho visto nessun riferimento alle applicazioni usate (si parla genericamente di HTML, Gzip, ecc.).
Questo link invece è proprio nel nostro caso:
http://www.aceshardware.com/read_news.jsp?id=75000414

e qui trovi il PDF a cui si riferisce
http://tesla.hpl.hp.com/caecw03/chen.pdf

IPC medi in questo caso? 0.6 0.5
Con un minimo di 0.15 che con quel tipo di istruzioni non me lo sarei mai aspettato.
Ecco, qui già il contesto è ben definitio, per cui ha un senso parlare di IPC.
Ma perchè devi scadere nel "io so di più e tu no"? Piantala per favore, nessuno qua fa a gara a chi sa di più. Ma ti pare che vengo qua a discutere di cose di cui non so nulla :rolleyes: userei il mio tempo in modo migliore non credi?
Direi di sì, invece: hai dimostrato di conoscere veramente poco e male l'ISA degli x86...
semplicemente se vedo una cosa su cui non sono d'accordo lo dico. E' sbagliato?
E' sbagliato insistere quando l'evidenza dei fatti ti dà ampiamente torto. E' sbagliato mettere alla gente parole in bocca che non hanno mai detto.
Un po' di maturità da parte tua nell'affrontare una discussione non guasterebbe certo.

Quanto a IPC minimo e massimo: quest'ultimo si può calcolare facilmente, mentre per il primo si può dire solamente che è strettamente > 0.