Athlon 64 Venice in commercio

[cdimauro]

Originariamente inviato da bjt2

Avete ragione: non avevo pensato che ci fosse anche l'altra ALU...

Io mi riferivo alle prestazioni a 64 bit: l'A64 con 3 ALU che spero siano full 64 bit,

Da quel che ne so, dovrebbero esserlo.

può processare fino a 3 addizioni a 64 bit per ciclo di clock.

Anche di più, grazie alle tre AGU...

Bene che vada, se la slow ALU è full 64 bit (e non credo, visto che il progetto originario del P4 non prevedeva il supporto a 64 bit)

Infatti non mi risulta che lo sia.

è possibile fare una addizione a 64 bit per ciclo di clock.

Dovrebbero essere due per ciclo di clock: ogni ALU può processare fino 4 istruzioni aritmetiche "semplici" a 64. Il P4 EM64T dovrebbe utilizzare le due porte di ogni ALU per effettuare un'operazione a 64 bit.
La situazione peggiora con le operazioni più complicate, affidata all'altra ALU, che presentano dei tempi di esecuzione peggiori (gli shift, ad esempio, sono nettamente più lenti rispetto all'AMD64).

Inoltre su internet ho letto che la velocità del decodificatore del P4 è di 3 micro ops a ciclo,

Dovrebbe essere di 4 micro-ops per ciclo col Prescott, se la memoria non m'inganna.

quindi anche avendo la possibilità teorica di eseguire 5 addizioni (4 a 16 e una a 32/64 bit posto che la slow ALU faccia anche le addizioni) per ciclo, ciò non può avvenire continuamente. La velocità di decodifica in micro ops (anzi, macro ops) dell'A64 è di 6 micro ops per ciclo di clock, dove ogni macro op può indicare fino a 2 operazioni elementari (per esempio leggere da memoria ed aggiungere ad EAX).

Esattamente. Infatti l'A64 nei 64 bit è decisamente più efficiente dei P4 anche per questo motivo.

[bjt2]

Per le AGU dell'A64 concordo, ma mi riferivo ad addizioni "utili", perchè il P4 ha le AGU direttamente attaccate alle unità di load e store (quindi sono 2 AGU). Non so se è meglio così, oppure è meglio calcolare gli effettive address prima (ad un rate di max 3 per clock) ed accodare le istruzioni nelle code dei load e store. Dalla teoria delle code qualcosa mi dice che è meglio questa ultima soluzione

Quindi anche la slow ALU del P4 è "double-pumped"?

Le "fast" alu possono processare 2 istruzioni a 16 bit per clock o una a 32 bit.

Per quelle a 64 bit non so proprio: usare le 2 ALU in parallelo come hai detto tu è la soluzione più semplice, ma non la più veloce.

Se si usasse una sola ALU non si avrebbero constraint di sincronizzazione (se una ALU è occupata, l'istruzione a 64 bit deve attendere) e l'altra ALU rimane libera (una istruzione a 16/32 bit deve attendere il completamento di quella a 64 bit), ma si guadagna qualche ciclo in latenza.

[cdimauro]

Originariamente inviato da bjt2

Per le AGU dell'A64 concordo, ma mi riferivo ad addizioni "utili",

Sì, avevo intuito. Solo che per un programmatore sono molto utili anche quelle "offerte" dall'AGU.

perchè il P4 ha le AGU direttamente attaccate alle unità di load e store (quindi sono 2 AGU).

Non funzionano come le AGU di P3 e Athlon, però: ad esempio una MOV EAX,[EBX + EDX * 4 + 12345678] viene scomposta in microistruzioni. Intel, infatti, nel suo manuale delle ottimizzazioni per P4 sconsiglia l'uso di queste forme d'indirizzamento; lo shift, ad esempio, viene "smistato" all'ALU "complessa", con le conseguenze che puoi immaginare...

Non so se è meglio così, oppure è meglio calcolare gli effettive address prima (ad un rate di max 3 per clock) ed accodare le istruzioni nelle code dei load e store. Dalla teoria delle code qualcosa mi dice che è meglio questa ultima soluzione

Idem.

Quindi anche la slow ALU del P4 è "double-pumped"?

Non mi sembra.

Le "fast" alu possono processare 2 istruzioni a 16 bit per clock o una a 32 bit.

Da quel link che hai postato non sembrerebbe così: si riferisce più che altro a come viene portata a termine un'operazione, non al throughput dell'ALU (e quindi al numero di porte / istruzioni).
Per lo meno questa è la mia impressione.

Per quelle a 64 bit non so proprio: usare le 2 ALU in parallelo come hai detto tu è la soluzione più semplice, ma non la più veloce.

Già, ma è quella che hanno adottato.

Se si usasse una sola ALU non si avrebbero constraint di sincronizzazione (se una ALU è occupata, l'istruzione a 64 bit deve attendere) e l'altra ALU rimane libera (una istruzione a 16/32 bit deve attendere il completamento di quella a 64 bit), ma si guadagna qualche ciclo in latenza.

Penso che sia così, infatti. Comunque mancano dei dettagli per toglierci tutti i dubbi...

[bjt2]

Immaginavo che le AGU del P4 fossero più semplici... Ecco perchè l'A64 è un piccolo "mostro" sulle applicazioni da ufficio: quel codice è strapieno di quei modi di indirizzamento...

[bjt2]

Per quanto riguarda le addizioni a 32 bit hai ragione: quello sembra un design pipelined con latenza 1,5 cicli di clock e output di 2 istruzioni per ciclo. Ci si può chiedere perchè non abbiano fatto lo stesso per le istruzioni a 64 bit, con 2,5 cicli di latenza e stesso output rate...

[overjet]

Scusatemi ma allora in definitiva questi venice e sandiego quando escono nella nostra Madre Patria ?!? I prezzi ?!?

Grazie.

[cdimauro]

Originariamente inviato da bjt2

Immaginavo che le AGU del P4 fossero più semplici... Ecco perchè l'A64 è un piccolo "mostro" sulle applicazioni da ufficio: quel codice è strapieno di quei modi di indirizzamento...

Infatti le modalità d'indirizzamento "complesse" sono da sempre state usate estensivamente dai programmatori per aggirare, quando possibile, le limitazioni dell'ISA x86.
Soltanto che, se leggi il manuale delle ottimizzazioni per il P4, buona parte dei "trucchetti" che fino a P3 e Athlon venivano usati per migliorare le prestazioni del codice (e renderlo anche più compatto), sono altamente sconsigliate.

[cdimauro]

Originariamente inviato da bjt2

Per quanto riguarda le addizioni a 32 bit hai ragione: quello sembra un design pipelined con latenza 1,5 cicli di clock e output di 2 istruzioni per ciclo. Ci si può chiedere perchè non abbiano fatto lo stesso per le istruzioni a 64 bit, con 2,5 cicli di latenza e stesso output rate...

Perché molto probabilmente avrebbero dovuto ridisegnare le due ALU veloci, aggiungendo altri due sommatori con carry a 16 bit alla "catena", volendo mantenere inalterato il loro throughput. IMHO, chiaramente.

[bjt2]

Giusto!

L'unico modo per non dover aggiungere altri due sommatori è poter accedere separatamente (da micro op) ai 32 bit bassi ed alti di un registro a 64 bit e generare due micro ops per calcolare le due metà, avendo il vantaggio di poter decidere se usare due ALU in parallelo o usare in sequenza una sola ALU...

[cionci]

Sembra che entrambe le ALU double pumped del Prescott siano state estese a 64 bit... Almeno secondo questa immagine: http://www.chip-architect.net/news/P..._1600x1200.jpg
http://www.chip-architect.com/news/2...ott_part2.html
Second integer core for 64 bit processing (not for multithreading)

It is as good as sure that the second 32 bit core is exclusively used for 64 bit processing, and in a way similar to the good old bit slices. There was the 4-bit AMD 2901 that could be used to build 16, 32 or 64 bit processors. The fact that makes it possible is because the core's is limited mainly to additive and logic functions. A 64 bit staggered addition will take a total of four 1/2 cycles but you can start two of them back to back on 1/2 cycle intervals. The latency to access the cache also does not need to be increased because of the extension to 64 (48) bit addresses. The higher part of the address is only used several cycles later to check the address tags with the TLB entries and not to access the data cache itself. What will increase with one cycle is the latency from an ALU instruction to a normal speed integer instructions. This delay will increase from 2 to 3 cycles. One extra pipeline stage is needed as well, resulting in a minor increase in the branch miss prediction penalty.



The reason that we can be so sure that the second core is not used to boost the 32 bit Hyper threading capabilities is the scheduler. This unit is by far the biggest entity on the Pentium 4 die. It is larger then all the Floating Point, MMX and SSE hardware together. It is not only big but it also consist mostly out of very timing critical optimized macro cells laid out by hand. It takes a lot of time and effort to change the scheduler. We've looked to it in detail and concluded that it has mainly remained unchanged on Prescott's die. This means that the maximum uOp throughput remains six per cycle using the same dispatch ports as the Pentium 4.
In pratica hanno aggiunto due ALU modulari per calcoalre i 32 bit più alti...pena una latenza più alta per le istruzioni a 64 bit...

[bjt2]

Quindi le istruzioni a 64 bit sono pipelined a 16 bit ma solo su una delle due fast ALU... un solo thread alla volta... bene...

[cdimauro]

Ci siamo tolti un altro sassolino dalla scarpa...

[bjt2]

Vedo che anche tu reputi l'architettura e l'implementazione dell'A64 "leggermente" migliore di quella del P4...

[cdimauro]

Generalmente sì, fatta eccezione per alcuni campi applicativi (SETI sicuramente, mentre per compressione video e 3D in alcuni casi).