Intel svela alcuni dettagli di Merom

[jappilas]

Originariamente inviato da Cecco BS

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

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

ma a parità di tecnologia una pipe corta è ovviamente meno penalizzata di una pipe lunga...

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

[bjt2]

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

[leoneazzurro]

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

[serpico84]

x jappilas

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

[ronthalas]

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

[Cecco BS]

Originariamente inviato da leoneazzurro

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

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

[leoneazzurro]

Originariamente inviato da Cecco BS

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

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

[sirus]

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

[Cecco BS]

Originariamente inviato da sirus

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

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

[jappilas]

Originariamente inviato da serpico84

x jappilas
bè io ho espresso la mia in base alle mie conoscenze...

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