Athlon64 vs Pentium4...

[joesabba]

uhm ma gli interi a 64 bit sono numeri astronomici... forse ne trarranno vantaggio solo applicazioni per i calcoli della fisica...

[maiks900]

Originally posted by "gigggi"

joe ti rammendo che rivoglio il mio c1!!! quando lo strapiantiamo? c'è luna nuova?

OT Vengo anch'io
/OT

[cionci]

Originally posted by "joesabba"

uhm ma gli interi a 64 bit sono numeri astronomici... forse ne trarranno vantaggio solo applicazioni per i calcoli della fisica...

Prinicipalmente database e programmi di criptazione/decriptazione...

[joesabba]

non molto... beh meglio ke niente

[gigggi]

ragazzi se andiamo a vedere in dettaglio a che cosa deve ricorrere una povera cpu per poter far uscire un risultato da una pipeline scopriremo che TUTTO il codice odierno è scritto da schifo!! e non mi dite che una ricompilazione risolverebbe tutto!! il fatto stesso che le cpu di oggi (ma anche qualcuna di ieri!!) abbiano al proprio interno una unità di branch prediction significa che devono "prevedere" il codice che entrerà nella cpu dopo quello in esecuzione......ma vi rendete conto?




R.I.S.C. rulez! solo con codice scritto ad hoc si avrà un certo miglioramento ed un taglio con tutti i bug software del passato! ma a voi xp sempra un s.o. stabile e senza bachi? ma vi ricordate win nt 4.0?

[gigggi]

dimenticanza!! mamma ms che ha già annuciato il supporto al codice a 64 bit è stata anche quella che ha sviluppato il codice a 32 bit da far funziare sui pentium 1 .........chi ha orecchie per intendere intenda.......il suddetto codice si chiamava win 95 (una bomba!!) e win 98 (veramente eccezionale e molto stabile !! ricordo a tutti che erano e sono software a 32 come diceva mamma ms infatti dopo insistenti richieste anche in casa ms hanno ammesso (dopo averne venduto trilioni di copie però...) che in realtà erano per circa l'85% scritti a 16 bit.....in parole povere il buon vecchio dos utilizzato in dpmi quando funziava a 32 bit!!

[cionci]

Originally posted by "gigggi"

il fatto stesso che le cpu di oggi (ma anche qualcuna di ieri!!) abbiano al proprio interno una unità di branch prediction significa che devono "prevedere" il codice che entrerà nella cpu dopo quello in esecuzione......ma vi rendete conto?

Cerchiamo di non fare fanta-informatica... Non ti fai una grande pubblicità con queste affermazioni scorrette L'unità di branch prediction non serve assolutamente a prevedere il codice che entrerà nella CPU Anche con il codice scritto meglio al mondo la CPU ha bisogno dell'unità di branch prediction...

Alcune istruzioni del linguaggio macchina sono istruzioni di salto condizionato... L'istruzione dopo il salto può essere quella successiva al salto o quella a cui si riferisce il salto (in caso di verifica della condizione)...quindi l'istruzione (e quelle successive) che deve essere caricata in pipeline dipende dalla condizione che si può determinare solo dopo la fase di esecuzione dell'istruzione di salto...

In questo modo la pipeline si arresterebbe fino alla determinazione della condizione di salto....

L'unità di branch prediciton secondo un particolare algoritmo decide (predizione) quale dei due rami (branch) di esecuzione caricare in pipeline...

Al momento della fase di esecuzione dell'istruzione di salto...se la predizione ha scelto bene abbiamo guadagnato una marea di cicli di esecuzione...se la predizione è errata (misprediction) viene fatto un flush della pipeline (si svuata la pipeline) e si ricomincia caricando l'istruzione giusta in pipeline (per produrre il primo risultato ci vogliano tanti cicli di clock quanti sono gli stadi delal pipeline)...
E' da notare che in caso di misprediction il risultato è lo stesso che si avrebbe in assenza di branch prediction...

Originally posted by "gigggi"

R.I.S.C. rulez!

Tra un x86 di oggi ed un RISC c'è molta poca differenza...e sta tutta nell'unità di decodifica... Sia P4 che Athlon traformano le istruzioni CISC in istruzioni a lunghezza fissa...caratteristica determinante delle ISA RISC...

Originally posted by "gigggi"

ma a voi xp sempra un s.o. stabile e senza bachi? ma vi ricordate win nt 4.0?

Win XP non molto e in questi giorni ne ho avuta la conferma... 3 registri di sistema partiti in una settimana su 3 macchine diverse...
Comunque Windows 2000 è ottimo....

[gigggi]

alura..........POTA: branch prediction unit ovvero unità di predizione di salto incondizionato...ovvero il processore elabora e ad un certo punto si ritrova a dover scaricare la pipeline perchè gli serve un "risultato" che nel codice eseguito viene dopo a quello che stava elaborando......nel caso del p4 la pipeline è di 20 stadi se non ricordo male......quindi pensate ai cicli di clock persi per fare ciò......considerate poi che questo avviene normalmente milioni di volte....se non miliardi....

CISC ovvero complex instruction set computing.......il codice macchina ha una serie incredibile di istruzioni molto complesse che la cpu (quelle di oggi...) deve decodificare ridurre in istruzioni più semplici (ovvero le cosiddette simil-risc ma che non centrano nulla con le vere risc!!) dopodichè la cpu assegna un "numero" ad ogni porzione di codice generato e le invia alle varie sezioni di elaborazione.....a seconda che siano istruzioni floating point...sse....sse2...mmx....per interi ect. ect. poi vengono effettivamente elaborate ed alla fine viene "ricomposto" il risultato in uscita ed inviato alla ram.....mentre decompila o scompone e ricompone la signola istruzione non avviene una vera e propria elaborazione utile ai fini del programma in esecuzione ma è solo una perdita di tempo e cicli di clock........se poi intervengono dei "salti" allora siamo a posto......e questo è il modo di lavorare delle cpu odierne...

POTA GNARI......RISC reduced instruction set computing ovvero un sistema di elaborazione con un set di istruzioni ridotte all'osso non ci sono branch prediction perchè il codice è praticamente scritto in base alla cpu su cui dovrà rullare non ci sono salti incondizionati non ci sono decompilazioni e ricompilazioni e nel caso di cpu con molte pipeline (praticamente tutte ormai...) siamo tranquilli che ogni pipeline darà il suo bel risultato in uscita ad ogni ciclo di clock!! solo recentemente poi sono state incluse nelle cpu le unità di floating poin in quanto prima venivano eseguite solo operazioni per interi.......non pensiate che le cpu risc per il fatto che sono più semplici siano meno potenti! sono sempre state dei mostri è solo che in ambito pc il cisc ha sempre dominato!! e questo è il vero risc...
io mi spiego sempre in parole chiare e semplici così può capire chiunque...se volete documentarvi in merito ci sono diversi articoli (sempre che siano online...) sù lithium

ecco a voi la fantainformatica!! ciao a tutti

dimenticavo se il codice macchina è scritto apposta per una cpu la stesse deve avere una unità di branch prediction?????? ma che dici!!
io ovviamente mi stavo spiegando in modo semplice....la branch prediction allora che cosa fà nella cpu?
ti faccio un esempio.....pota......le cpu pentium 1 integravano un primo abbozzo di unità di branch....mentre il power pc 604 non l'aveva...il pentium aveva 2 pipeline mentre il power 4.....il pentium aveva il suo daffare con i salti mentre il power dava i suoi bei 4 risultati per ciclo di clock immancabilmente.....qual'è l'architettura più efficente?

[Athlon]

Confermi quanto detto da cionci , la presenza di una pipeline implica la presenza di una branch prediction unit.

Questo e' dovuto al fatto che la pipeline introduce una latenza di esecuzione e nel caso di salti condizionati la condizione non sempre e' disponibile al momento dell' istruzione di JUMP.

Ovviamente si puo' cercare di ottimizzare il codice inserendo delle istruzioni tra il calcolo della condizione e l'esecuzione del salto

codice non ottimizzato

z=a+b
x=c+d
y=e+f
If x>y then

codice ottimizzato


x=c+d
y=e+f
z=a+b
If x>y then

in pratica si mettono delle istruzioni di riempimento tra il calcolo della condizione e l'esecuzione del salto

[Betha23]

Originally posted by "Athlon"

Confermi quanto detto da cionci , la presenza di una pipeline implica la presenza di una branch prediction unit.

Questo e' dovuto al fatto che la pipeline introduce una latenza di esecuzione e nel caso di salti condizionati la condizione non sempre e' disponibile al momento dell' istruzione di JUMP.

Ovviamente si puo' cercare di ottimizzare il codice inserendo delle istruzioni tra il calcolo della condizione e l'esecuzione del salto

codice non ottimizzato

z=a+b
x=c+d
y=e+f
If x>y then

codice ottimizzato


x=c+d
y=e+f
z=a+b
If x>y then

in pratica si mettono delle istruzioni di riempimento tra il calcolo della condizione e l'esecuzione del salto

Mi dispiace contraddirti Athlon, non sono espertissimo per quanto riguarda la computazione dei processori odierni, ma sulla "storia informatica" qualcosa ricordo. La PRIMA branch prediction mai esistita è stata integrata sul Pentium1 (o P5). La prima struttura a pipeline risale al 386 che aveva un unica pipeline a 4 stadi. Successivamente allungata nel 486 (5 stadi). Il Pentium aveva una pipeline completa (5 stati) e una integrativa (stiamo sempre parlando di ALU), in pratica la seconda non poteva eseguire determinate operazioni.

Sulla BPU (Branch Prediction Unit) posso dire solo quello che io ho sempre saputo. Nasce con il P5, consiste in dei registri dove vengono annotati i salti effettuati dal codice, la BPU prima di mandare in esecuzione il codice controlla questi registri, se trova un probabile salto agisce di conseguenza, la BPU è utile soprattutto per parallelizzare i calcoli su più pipeline.

X Cionci: "L'unità di branch prediciton secondo un particolare algoritmo decide (predizione) quale dei due rami (branch) di esecuzione caricare in pipeline... " okkio, hai fatto un errore madornale, un processore NON DECIDE MAI NULLA! Sembra una cretinata ma è un punto fondamentale per capire come "pensa" un procesore.

[checo]

cazzo mi ero perso sto 3d!

cmq a grandi linne la penso come cionci

la bpu serve se hai una cpu con un pipe, in ogni caso

se poi il codice è straottimizzato l'utilità della bpu vine meno, ma un codice perfetto non c'è quindi è vero che la bpu verrà usata meno su codice ottimizzato, ma verrà usato.

i vantaggi dell a64 dove stanno

controller ddr400 single channel integrato

non so se sia come un dual su chipset ma non è molto lontano( vedremo le differenze opteron a64)

cambiare controlle vuol dire cambiare socket? non lo so

cmq resta il fatto che qualora sia necessario si puà sempre disabilitatare il controller integrato e usare il controller su chipest (se il chipset lo ha)

penso che quando uscirà la ddr 533 ad esempio esisteranno chipset con un dual ddr 533 ad esempio, certo si perde un vantaggio(latenza) ma non si deve cambiare cpu.

altro vantaggio in ordine sse2

bus a 800mhz

poi ottimizzazioni del core
poi l2 duplicata
infine i 54bit, che sono quelli che porteranno un minore apporto di prestazioni per me vuoi perchè il loro utilizzo è limitato, vuoi per il programmatori.

cmq a parità di frequenza un a64 ed un xp sono ben distanti e questo fa ben sperare

[Betha23]

Originally posted by "checo"


cmq a parità di frequenza un a64 ed un xp sono ben distanti e questo fa ben sperare

Vorrei sperare! L'hammer è un Athlon rivisitato....... un po come fu il Pentium2 per il PentiumPro ........... beh forse un po di più!

[cionci]

Originally posted by "Betha23"


X Cionci: "L'unità di branch prediciton secondo un particolare algoritmo decide (predizione) quale dei due rami (branch) di esecuzione caricare in pipeline... " okkio, hai fatto un errore madornale, un processore NON DECIDE MAI NULLA! Sembra una cretinata ma è un punto fondamentale per capire come "pensa" un procesore.

E' l'algoritmo che decide

[cionci]

Originally posted by "checo"

se poi il codice è straottimizzato l'utilità della bpu vine meno, ma un codice perfetto non c'è quindi è vero che la bpu verrà usata meno su codice ottimizzato, ma verrà usato.

No...in ogni caso anche nel caso di cidice perfetto ogni volta che c'è un salto condizionato entra in esecuzione la BPU...

Pensa ad un for:

for(i=0; i<10; i++)
{
 ...
}

Portato in assembler:

            movl $0, i
inFor:
            cmpl i, $10
            je fineFor
            .... #esecuzione del corpo del for
            incl i
            jmp iniFor
fineFor:

La bpu probabilmente per 10 volte dopo la jump condizionata (salta se i è uguale a 10) caricherà il corpo del for...e di conseguenza non si avrà uno stallo della pipeline e non verrà sprecato nemmeno un ciclo di clock...
All'undicesima volta per coerenza con le volte precedenti continuerà ad operare nel solito modo e caricherà il corpo del for in pipeline... Questa volta però ha sbagliato e si avrà uno stallo della pipeline...di conseguenza un flush e lo spreco di tot cicli di clock (solitamente n-1 o n-2 rispetto al numero di stadi della pipeline visto che l'esecuzione delle jump condizionate potrebbe venire anticipata in attesa della fine dell'istruzione precedente)...

Quindi il codice perfetto sarebbe quello in cui non ci sono salti condizionati... Cosa alquanto improbabile...

Originally posted by "checo"

cambiare controlle vuol dire cambiare socket? non lo so

Non è detto... Un solo aumento di frequenza non comporterà un cambiamente del socket...
Un cambio del tipo di memorie potrebbe portarlo... Non so se questo avverrà anche per le DDR-II...
[/quote]

[Betha23]

Originally posted by "cionci"


E' l'algoritmo che decide

Ma ti piace proprio tanto la parola "decide" ??

Ok fraternizzare con la macchina ma attribuirgli capacità umanoidi...........

[cionci]

Originally posted by "gigggi"

alura..........POTA: branch prediction unit ovvero unità di predizione di salto incondizionato...ovvero il processore elabora e ad un certo punto si ritrova a dover scaricare la pipeline perchè gli serve un "risultato" che nel codice eseguito viene dopo a quello che stava elaborando......

Direi che non è proprio così...

Originally posted by "gigggi"


CISC ovvero complex instruction set computing.......il codice macchina ha una serie incredibile di istruzioni molto complesse che la cpu (quelle di oggi...) deve decodificare ridurre in istruzioni più semplici (ovvero le cosiddette simil-risc ma che non centrano nulla con le vere risc!!) dopodichè la cpu assegna un "numero" ad ogni porzione di codice generato e le invia alle varie sezioni di elaborazione.....a seconda che siano istruzioni floating point...sse....sse2...mmx....per interi ect. ect. poi vengono effettivamente elaborate ed alla fine viene "ricomposto" il risultato in uscita ed inviato alla ram.....mentre decompila o scompone e ricompone la signola istruzione non avviene una vera e propria elaborazione utile ai fini del programma in esecuzione ma è solo una perdita di tempo e cicli di clock........

Attualmente le CPU x86 hanno tutte le caratteristiche storiche delle CPU RISC... Istruzioni interne a lunghezza fissa...out-of-order execution...ed altre che ora non mi vengono in mente...
L'unità di decodifica occupa circa il 30% della superficie necessaria per le unità di esecuzione... Chiaramente la trasformazione da istruzioni a lunghezza variabile a istruzioni a lunghezza fissa è uno spreco di clicli di clock, ma in ogni caso l'unità di decodifica occupa fra 1 e 4 stage della pipeline di conseguenza lo spreco effettivo si ha solamente nel caso di stallo della pipeline mentre a regime non si sente visto che comunque queste operazioni vengono svolte in parallelo alle altre della pipeline...

Non capistoc osa tu intenda per "ricomporre" il risultato...

Originally posted by "gigggi"


POTA GNARI......RISC reduced instruction set computing ovvero un sistema di elaborazione con un set di istruzioni ridotte all'osso non ci sono branch prediction perchè il codice è praticamente scritto in base alla cpu su cui dovrà rullare non ci sono salti incondizionati non ci sono decompilazioni e ricompilazioni e nel caso di cpu con molte pipeline (praticamente tutte ormai...) siamo tranquilli che ogni pipeline darà il suo bel risultato in uscita ad ogni ciclo di clock!!

Qui confermi la mia tesi... I salti condizionati ci saranno sempre... I MIPS (soricamente il RISC per eccellenza) hanno i salti condizionati...
Esisteno alternative alla BPU...ma comportano comunque una perdita di cicli di clock...

Originally posted by "gigggi"


non pensiate che le cpu risc per il fatto che sono più semplici siano meno potenti! sono sempre state dei mostri è solo che in ambito pc il cisc ha sempre dominato!! e questo è il vero risc...

Ti dico soltanto che AMD con i K6 affermava escplicitamente nella documentazione che traduceva le istruzioni x86 in istruzioni RISC

Originally posted by "gigggi"


io mi spiego sempre in parole chiare e semplici così può capire chiunque...se volete documentarvi in merito ci sono diversi articoli (sempre che siano online...) sù lithium

Infatti non si capiva...

Originally posted by "gigggi"


ecco a voi la fantainformatica!! ciao a tutti

Io non ti volevo offendere...è che quando uno si espone in questa maniera su un forum pubblico deve essere sicuro di quello che dice... Sia quello che hai detto prima che quello che hai detto ora sulla branch prediction unit è errato...

Originally posted by "gigggi"

dimenticavo se il codice macchina è scritto apposta per una cpu la stesse deve avere una unità di branch prediction?????? ma che dici!!

Dico così e l'ho dimostrato poco sopra...

Originally posted by "gigggi"

io ovviamente mi stavo spiegando in modo semplice....la branch prediction allora che cosa fà nella cpu?

L'ho scritto nel mio primo post...

Originally posted by "gigggi"

ti faccio un esempio.....pota......le cpu pentium 1 integravano un primo abbozzo di unità di branch....mentre il power pc 604 non l'aveva...il pentium aveva 2 pipeline mentre il power 4.....il pentium aveva il suo daffare con i salti mentre il power dava i suoi bei 4 risultati per ciclo di clock immancabilmente.....qual'è l'architettura più efficente?

Sul fatto che il Power PC 604 non abbia una branch prediction unit o meno non lo so e di conseguenza non lo posso negare...e come ho già detto ci sono metodi alternativi alla branch prediction unit... Quindi anche il Power PC 604 aveva il suo bel da fare con i salti...

Anzi ho trovato ora che il Power PC 604 ha una branch prediction unit...ed è stato il primo Power PC ad averla... Quindi mi sa che hais celto amle il modello

http://www.mactech.com/articles/develop/issue_20/20balance.html

http://www.mackido.com/Hardware/G2.html

http://www.csse.monash.edu.au/~davida/teaching/cse3304/Web/Chapter8/

[cionci]

Originally posted by "Betha23"

Ma ti piace proprio tanto la parola "decide" ??

Ok fraternizzare con la macchina ma attribuirgli capacità umanoidi...........

Il "decidere" non implica un'intelligenza, ma semplicemente "prendere una delle possibili soluzioni ad un problema", in questo caso, secondo un algoritmo

[checo]

quello che dicevo io la branche serve sempre, serve meno se il codice è ottimizzato, ma serve

[cionci]

Originally posted by "checo"

quello che dicevo io la branche serve sempre, serve meno se il codice è ottimizzato, ma serve

Ah...ok

[joesabba]

Originally posted by "gigggi"



CISC ovvero complex instruction set computing.......il codice macchina ha una serie incredibile di istruzioni molto complesse che la cpu (quelle di oggi...) deve decodificare ridurre in istruzioni più semplici (ovvero le cosiddette simil-risc ma che non centrano nulla con le vere risc!!) dopodichè la cpu assegna un "numero" ad ogni porzione di codice generato e le invia alle varie sezioni di elaborazione.....a seconda che siano istruzioni floating point...sse....sse2...mmx....per interi ect. ect. poi vengono effettivamente elaborate ed alla fine viene "ricomposto" il risultato in uscita ed inviato alla ram.....mentre decompila o scompone e ricompone la signola istruzione non avviene una vera e propria elaborazione utile ai fini del programma in esecuzione ma è solo una perdita di tempo e cicli di clock........se poi intervengono dei "salti" allora siamo a posto......e questo è il modo di lavorare delle cpu odierne...

Questo punto è importante direi... è una perdita di tempo enorme utilizzare la cpu per tradurre al volo istruzioni in istruzioni più semplici.
Il postulato del risc è proprio quello di avere poche istruzioni assembler, esattamente il contrario delle cpu x86... quindi pure-risc rulez!

la branch prediction cmq sarà sempre un algoritmo utile nel calcolo parallelo