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

Come distinguere le nuove revision di processore Athlon 64, costruite con processo a 0.09 micron?

Click sul link per visualizzare la notizia.

godo

Ma i vantaggi rispetto al core winchester?
è anche quello a 90nm...
Ma ora usciranno anche processori a frequenza più alta con lo stesso processo produttivo?

e io ho comprato in winchester IERIIII!!!
L'ho fatto per voi, cosi' finalmente e' uscito il venice :)

Ma quando arriva in Italia? :cry:

Ma i vantaggi rispetto al core winchester?
è anche quello a 90nm...
Ma ora usciranno anche processori a frequenza più alta con lo stesso processo produttivo?


Le ss3 ad esempio... :( mannaggia... facevano comodo! :Prrr:

In attesa direttamente di un bel dual core @2400

ma anche questi al il molti bloccato?

ma anche questi al il molti bloccato?
si, ma verso il basso...

semmai... sbloccato verso il basso :-;

c'è da augurarsi che gli store italiani lo mettano in vendita quanto prima...stavo pensando di passare da newcastle 3500 a venice ...

Il winch consuma di meno ma il venice sale più in frequenza, oltre ad avere le SSE3.

Le SSE3 al momento servono a pochino, pare ;)
Il vantaggio principale del Venice è che dovrebbe overclockarsi meglio, un po' come ThoroB vs ThoroA
BTW, pare che scaldi leggermente di più (poca roba, comunque). Implementa il dual stress liner, come gli FX-55... per quanto possa sembrare strano, potrebbe pure essere quello il motivo (l'FX55 scalda ben più del FX53)

La revision E dovrebbe avere anche il supporto alle memorie con chip su tutti e due i lati.
Per fare un esempio:
il mio pc con un Winchester non supporta 4 moduli double side, cioe' li supporta, ma solo a 333 Mhz, mentre 2 sono ok.

Credo che nella revision E abbiano sistemato anche questo problemino, qualcuno puo' confermare/smentire?

...ho appena preso un winchester...evvai !
ma sul winch non era già stata implementata la SOI ? oppure è solo una prerogativa di questo nuova revision?

infatti qualcuno conferma se il BUG con 4 banchi da 512 è risolto con il venice!!!!!! e le mem lavorano tutte e 4 a 400Mhz in dual channel! HURRY!!!!!!

E' proprio sicuro che le SSE3 non apporteranno nessun vantaggio a questi Athlon 64?
Magari con la codifica Divx dove molti software gradiscono le SSE3 i tempi scenderanno! Se non ricordo male sulle varie operazioni di codifica AMD pagava dazio a INTEL !

BTW, pare che scaldi leggermente di più (poca roba, comunque). Implementa il dual stress liner, come gli FX-55... per quanto possa sembrare strano, potrebbe pure essere quello il motivo (l'FX55 scalda ben più del FX53)Esatto, per cui la news è un po' incorretta a parlare di SOI quando in realtà si tratta del DSL.

Sei Zhelgadis da it.comp.hardware.*? ;)

Magari con la codifica Divx dove molti software gradiscono le SSE3 i tempi scenderanno! Se non ricordo male sulle varie operazioni di codifica AMD pagava dazio a INTEL !Le SSE3 serviranno, ma sarà poca roba e non certo sufficiente a colmare il gap con i Pentium 4. Ci vuole il dual core! ;)

Si infatti sul winchester è già stato usato il processo SOI, anzi per essere precisi SSDOI (ovvero processo mix tra SOI e strained silicon ideato da AMD e IBM) acronimo di strained silicon directly on insulator.
http://www.compoundsemiconductor.net/articles/news/7/9/10/1
http://domino.research.ibm.com/comm/bios.nsf/pages/cmos-perf.html

Sul Venice (512K) e sul SanDiego (1MB) c'è un nuvo processo, ne ha parlato leoneazzurro in un'altro post, che si chiama DSL (dual stres liner)

Mentre lo strained silicon migliora la performance dei pMOS e poco quella degli nMOS, il DSL migliora la performance di commutazione di tutti e due.
http://www.reed-electronics.com/semiconductor/article/CA490112?pubdate=1%2F1%2F2005&industryid=3032

Oltre a questo c'è sempre il SOI per abbattere i consumi delle correnti di leak, come nei vecchi barton mobile.

maxart ma che put*****e vai dicendo??

Le SSE3 serviranno, ma sarà poca roba e non certo sufficiente a colmare il gap con i Pentium 4. Ci vuole il dual core!

!?!?!?!?
A me non risulta che siano gli A64 a dover rincorrere i pentium4!

maxart ma che put*****e vai dicendo??



!?!?!?!?
A me non risulta che siano gli A64 a dover rincorrere i pentium4!


Credo si riferisse alla codifica, dove gli intel sono più veloci e molti programmi utilizzano le sse3

Si ma ormai le differenza marcate che c'erano una volta tra p4 e barton non ci sono più, inoltre coi dual core amd passerà avanti anche con l'encoding :)

i software a 64 bit.....

poi si parlera'
con i 64 bit nativi gli AMD dovrebbero andare veramente bene.....

Per il software a 64 bit:

L'EM64T non va così bene come l'AMD64, perchè il P4 ha 2 ALU a 16 bit che funzionano al doppio della frequenza della CPU: si possono fare 4 operazioni a 16 bit, due a 32 e due mezze a 64 bit (o forse una???) per ciclo di clock. Tra le operazioni sono comprese quelle di calcolo dell' Effective Address. L' A64 ha 3 ALU specializzate (e dedicate) per gli Effective address, 3 ALU generiche che, credo, siano full 64 bit e un moltiplicatore intero ed un divisore intero. Il P4 fino al northwood faceva le moltiplicazioni intere convertendole in floating point e di nuovo in interi (!!!), non ho notizie per la divisione. Finalmente il Prescott ha un moltiplicatore per gli interi (ancora non ho notizie per il divisore).

Ciao,
Bjt2.

Credo si riferisse alla codifica, dove gli intel sono più veloci e molti programmi utilizzano le sse3Del resto, stavamo parlando di quello, no?

L'EMT64 non va così bene come l'x86-64Si dovrebbe dire EM64T, e se con x86-64 intendi il set implementato da AMD, ora si chiamano AMD64. La nomenclatura x86-64 è usata sia per AMD64 che EM64T, mi pare.

Il P4 fino al northwood faceva le moltiplicazioni intere convertendole in floating point e di nuovo in interi (!!!), non ho notizie per la divisione. Finalmente il Prescott ha un moltiplicatore per gli interi (ancora non ho notizie per il divisore).Uhm, mi pare strano. La moltiplicazione sarebbe stata parecchio lenta, allora.

semmai... sbloccato verso il basso :-;
:ops:
letto male...

...[cut]...

Si dovrebbe dire EM64T, e se con x86-64 intendi il set implementato da AMD, ora si chiamano AMD64. La nomenclatura x86-64 è usata sia per AMD64 che EM64T, mi pare.



Sistemato... grazie :D


Uhm, mi pare strano. La moltiplicazione sarebbe stata parecchio lenta, allora.

Non più di tanto... aumenta un po' la latenza, ma considerando che è già alta e che il clock del P4 è stratosferico, non è che si perde più di tanto rispetto all'A64...

maxart ma che put*****e vai dicendo??


credo si riferisse al MultyT e alla codifica ed affini (il solito campo dove i P4 sono ankora qlkosa sopra)

per il resto il Venice ha anke l'MCH migliorato oltre per la comp per le prestazioni
visto che mediamente va qlkosa in + di un Winch o NewC a pari freq

ma quella A del Vcore?? che significa??? 1.35? 1.3?

BYEZZZZZZZZZZZZ

Del resto, stavamo parlando di quello, no?


Si infatti, sono daccordo con te pur avendo un amd64 inquanto quel tipo di operatività non mi interessa ;)

quando avremo dualcore e 64bit implementati decentemente nei software ne riparleremo, ma ora che intel in quel campo sia un tantinello avanti mi sembra chiaro, avendo girato in questi 2 giorni il web in lungo e in largo dovendo consigliare un pc ad un amico :p

bene :D
però io non cambio ancora ;)
aspetto il dual core e faccio il grande salto :D da P3 1000 a dual core

Scusate, ma come si fa a capire che revisione e' la cpu, quando la si ordina online? Se non si compra in un negozio piccolo ed esperto, ordinando nei grandi store col cavolo che ti scrivono la revision....

Originariamente inviato da bjt2
L' A64 ha 3 ALU specializzate (e dedicate) per gli Effective address, 3 ALU generiche che, credo, siano full 64 bit e un moltiplicatore intero ed un divisore intero.

Confermo, questo aspetto è rimasto invariato nei K8 rispetto ai K7: 3 ALU e 3 AGU (address generating unit, AMD le chiama così), con pipeline separate. Il moltiplicatore dovrebbe essere stato ottimizzato: i k7 mi pare impiegassero 4 cicli di clock per una moltiplicazione intera a 32 bit, gli A64 3 cicli con dati a 32 bit, 4 per interi a 64 bit (se non ricordo male). I nortwood si appoggiavano alla FPU "vera e propria", oppure utilizzavano in qualche modo l'unità SSEx?

Non lo so ;)

L'EM64T non va così bene come l'AMD64, perchè il P4 ha 2 ALU a 16 bit che funzionano al doppio della frequenza della CPU: si possono fare 4 operazioni a 16 bit, due a 32 e due mezze a 64 bit (o forse una???) per ciclo di clock.
Sicuro che le ALU siano a 16 bit? A me risulta che siano a 32 bit, e che per le operazioni a 64 bit vengano usate due "istruzioni" a 32 bit per portarle a termine.

I nortwood si appoggiavano alla FPU "vera e propria", oppure utilizzavano in qualche modo l'unità SSEx?
E' uguale: FPU e SSE/2/3 utilizzano la medesima "sezione di calcolo in virgola mobile".

Ciao,

Scusa, finalmente ho trovato il link:

dal sito di INTEL,

http://www.intel.com/technology/itj/q12001/articles/art_2.htm

pagina 5, verso la metà...

Ciao.

Ciao,

Scusa, finalmente ho trovato il link:

dal sito di INTEL,

http://www.intel.com/technology/itj/q12001/articles/art_2.htm

pagina 5, verso la metà...

Ciao.
Ti riferisci a questo schema ?
http://www.intel.com/technology/itj/q12001/images/art_2_fig7.gif

In tal caso quello è lo schema interno di ogni ALU veloce e non di entrambe... I primi 16 bit vengono prodotti in un ciclo di clock (dell'ALU), mentre i secondi 16 nel ciclo successivo...
Considerando che l'ALU viaggia ad una frequenza pari al doppio di quella del processore può essere terminata una istruzioni a 32 bit per ogni ciclo di clock (della CPU) per ogni ALU, sempre che l'istruzione sia fra quelle che vengono instradate sulle porte veloci...

Ti ringrazio, l'articolo è veramente molto, molto :) interessante.

Però da quel che ho capito il processamento delle operazioni "16 bit alla volta" riguarda la latenza (che è di 1,5 cicli di clock: due per le somme parziali a 16 bit, e una per la generazione dei flag), ma non mi sembra influire sul throughput, cioè su quante operazioni (a 32 bit, che sono ciò che interessano) è in grado di processare un'ALU "semplice".

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, può processare fino a 3 addizioni a 64 bit per ciclo di clock. 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) è possibile fare una addizione a 64 bit per ciclo di clock. Inoltre su internet ho letto che la velocità del decodificatore del P4 è di 3 micro ops a ciclo, 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).

L'articolo è interessante, ma è di parte... ;)

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.

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.

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...

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...

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...

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

Grazie.

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. :(

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. :)

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...

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/Prescott_90_nm_die_text_1600x1200.jpg
http://www.chip-architect.com/news/2003_04_20_Looking_at_Intels_Prescott_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...

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... ;)

Ci siamo tolti un altro sassolino dalla scarpa... :p

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

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