Pipeline più lunghe per Intel Prescott

[PiccioKing]

me ne ha parlato un professore si sistemi operativi e architettura degli elaboratori all'università... :-)

[Mazzulatore]

Guardate.
Sono solo voci chiare e precise, ovviamente, ma che confermano i miei sospetti.

[cdimauro]

Originariamente inviato da Mazzulatore
Se consideri la complessità delle SSE2 non è una cifra sconsiderata (più cisc che mai!!). Però se consideri che se le istruzioni non sono accoppiabili (caso più frequente di una predizione di salto errata) le pipeline si svuotano con tot clock di ritardo per la successiva istruzione che rientra in parallelo (e qua puzza di Hyper threading come rattoppo).
Faccio questa ipotesi (ed attendo una tua risposta in merito) perchè non mi sembra possibile che un processore a così alta frequenza sia così solo per colpa dei salti non previsti (come sento dire in giro) che si riducono, in sostanza, alle uscite dai cicli.

E invece la "piaga" principale dei processori attuali è proprio l'esecuzione delle istruzioni di salto, che rappresentano circa il 10% del totale, che creano stalli nella pipeline. Stalli che provocano problemi non indifferenti, e che cache più ampie e unità di branch prediction possono soltanto "mitigare". Tra l'altro l'efficienza di queste ultime si assesta sempre nell'ordine del 94-96%: mai visto, finora, unità che diano rese migliori. Aumentare la loro resa di un punto percentuale non porta certo un giovamento tale da sopperire all'aumento del 50% degli stadi di pipeline, IMHO.
In questo modo si verifica un "appiattimento" delle prestazioni del processore, che si avvantaggerà sempre più sul lato SIMD (che è meno affetto ai problemi di salto), mentre perderà abbastanza sul versante del codice "classico".
Altra cosa, è chiaro che un'architettura a pipeline lunghe avvantaggia la tecnologia HyperThreading: poiché un thread andrà più facilmente in stallo, l'altro se ne potrà avvantaggiare, "soffiandogli" le risorse e continuando ad eseguire il suo codice.
I problemi, però, sono tre:
1) Il codice dev'essere scritto appositamente per avvantaggiarsi del SMP, e non è cosa semplice.
2) Non tutti gli algoritmi sono parallelizzabili.
3) Le latenze di ogni thread aumentano sensibilmente, anche se il throughtput è maggiore.
Quest'ultimo punto può andare più che bene per chi fa del lavoro "offline", ossia lo lancia e aspetta che finisca: aspetterà un po' di più (latenza), ma alla fine si troverà con più lavoro svolto (due task a termine anziché uno). E' una filosofia che si sposa bene con i server (infatti altre case, come Sun, si stanno spostando in questa direzione), ma non so quanto possa andare bene per un uso "casalingo", dove l'utente è abituato ad avere "tutto e subito".
Le 30 pipeline del Prescott non sono "ufficiali", ma se dovessero diventarlo, per quanto mi riguarda allontanerebbero ancora di più i P4 dall'uso che faccio del computer (compilatori, database, emulatori. Specialmente per quest'ultimi la "botta" sarà notevole).
Ciao

[The3DProgrammer]

secondo me invece è amd che sta cxcxndo fuori un po , vedo l'athlon 64 che assomiglia sempre piu al p4 intel decide cache piu grande e amd gli va dietro intel decide bus piu ampio e amd gli va dietro intel decide + mhz e amd la rincorre non senza vedere che queste sono ottimizzazioni che vanno di piu su architettura net brust e che non ripagano lo stesso tanto nell'architettura amd

1) il P4 ha 2 pipeline funzionanti al doppio della frequenza di clock della CPU, l'Athlon64 ha 3 pipeline alla stessa frequenza della CPU

2) La pipeline del P4 ha 20 stadi, quella dell'A64 mi pare 12 (o 15, nn ricordo)

3) L'A64 ha il controller della memoria integrato nel core, il P4 si affida a controller esterni

4) L'a64 utilizza il bus Hypertransport, il P4 l'AGTL+

5) il p4 utilizza la trace cache al posto della + standard cache dati dell'A64. L'A64 ha una cache istruzioni di 64 kbyte, il p4 di 8k.

6) L'FPU x87 del p4 è sicuramente + semplice e meno performante di quella dell'Athlon64, ma il P4 sopperisce a questo deficit con le SSE2.


Ora, vorrei capire dove hai visto queste somiglianze tra p4 e A64...forse nel package?

[The3DProgrammer]

secondo me invece è amd che sta cxcxndo fuori un po , vedo l'athlon 64 che assomiglia sempre piu al p4 intel decide cache piu grande e amd gli va dietro intel decide bus piu ampio e amd gli va dietro intel decide + mhz e amd la rincorre non senza vedere che queste sono ottimizzazioni che vanno di piu su architettura net brust e che non ripagano lo stesso tanto nell'architettura amd

1) il P4 ha 2 pipeline funzionanti al doppio della frequenza di clock della CPU, l'Athlon64 ha 3 pipeline alla stessa frequenza della CPU

2) La pipeline del P4 ha 20 stadi, quella dell'A64 mi pare 12 (o 15, nn ricordo)

3) L'A64 ha il controller della memoria integrato nel core, il P4 si affida a controller esterni

4) L'a64 utilizza il bus Hypertransport, il P4 l'AGTL+

5) il p4 utilizza la trace cache al posto della + standard cache dati dell'A64. L'A64 ha una cache istruzioni di 64 kbyte, il p4 di 8k.

6) L'FPU x87 del p4 è sicuramente + semplice e meno performante di quella dell'Athlon64, ma il P4 sopperisce a questo deficit con le SSE2.


Ora, vorrei capire dove hai visto queste somiglianze tra p4 e A64...forse nel package?