Az elvileg lehetséges 4 körüli IPC elég problémás. Dícséretes, hogy erre törekszenek, de a gyakorlatban integer oldalon az átlag kettő már nagyon-nagyon jó. És ez adott program esetében - magán programon kívül - nem annyira a VE-k számán, hanem inkább az elágazásbecslésen, az OOO cuccokon meg az efféléken múlik.

Lebegőpontos oldalra nincsenek pontosnak vehető információim. Bár a mérés elvileg kivitelezhető, jelenleg nincs rá időm.

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Az én tapasztalataim is azt mutatják hogy a 1,5-2 feletti IPC érték eléréséhez már bűvésznek kell lenni ( K8 ). De próbaképp írok valami rutin, kifejezetten az IPC maximum értékének kiméréséhez.

Azt hiszem, így már értem, hogy képzelted. Azt hittem, hogy mondjuk az egyszem FADD 4 számolóegységébe akarsz 4 scalarSSE/FPU utasítást bepasszírozni egy órajel alatt alkalomadtán.

Az AMD ütemezői K7 óta (K7 óta biztosan) egyidejűleg összesen 9 micro-op indíthatnak egy órajel alatt párhuzamosan, 3-3 a három darab ALU-ban és a velük ábrázolásszinten valamiért szoros kapcsolatban lévő AGU-ban, 1-1-1 az FADD, az FMUL és az az FSTORE (azaz FMISC) egységekben.

Az FPU-egységei is komplexek, talán a K7 dokumentációjában van kifejtve legrészletesebben:

- FADD: (FP add/MMX ALU/3DNow!): The first of the three pipes is generally known as the adder pipe (FADD), and it contains 3DNow! add, MMX ALU/shifter, and floating-point add execution units.
- FMUL: (FP mul/MMX ALU/MMX Mul/3DNow!): The second pipe is known as the multiplier (FMUL). It contains a 3DNow!/MMX multiplier/reciprocal unit, an MMX ALU and a floating-point multiplier/divider/square root unit.
- FSTORE: The third pipe is known as the floating-point load/store (FSTORE), which handles floating-point constant
loads (FLDZ, FLDPI, etc.), stores, FILDs, as well as many OP primitives used in VectorPath sequences. (Itt még az OP elnevezéssel illeték a micro-op-okat, csak hogy az Intel nomenklatúrájától különbözzenek, és így ebben az időben az SSE1 még 3DNow! Professional néven futott.)

Egyébként amikor megérkeztek az első hírek a K8L megduplázott FPU-járól, akkor én is azt hittem, hogy több exetucion unit-ot megdupláznak.

Ha rajtam múlna, hogy merre fejlődjön tovább az x86, akkor a következők felé vinném el:
- a kiindulási alap egy K-family alapú micro-architecture (persze lehetőleg K10 a 128 bites FPU miatt, csak az még nem kézzelfogható most). A macro-op megközelítés maradna, sokkal hatékonyabb, mint az Intel-féle micro-op szemlélet (fusion-nal együtt), és a közös INT/FP pipe-ok se szimpatikusak.
- a decoder-ek »mögé« tennél egy Intel-féle nagyméretű trace cache-hez hasonló macro-op cache-t tennék, levenné a L1-ről és a decoder-ekről a sokszori felesleges munkát (pl. minden ciklus-lefutás újrafordítódik). Azt ne feledjük, hogy AMD-nél a 1x-stage pipe hosszának kb. felét teszi ki a fordítás macro-op szintre.
- behoznék az x86 utasításszintre egy speciális, 8 byte-os paraméterű feltételes ugrásokhoz kapcsolható prefix-et, így meg lehetne különböztetni már programszinten az IF-ELSE ugrásokat a ciklusszervező ugrásoktól.
- az elágazásbecslés-szempontú ugrásvégrehajtás mellett az előbbi prefix-szel együttműködve alkalmaznám azt a (például IA-64-ben implementált) elágazáskezelési technikát, amelyben spekulatívan mindkét ágat elkezdi végrehajtani, majd a kiértékeléskor az hamis ág utasításait eldobja. Igencsak megnőne az eldobott utasítok száma, viszont ugyanennyivel (összességében nagyban) javulna a megtartott utasításokok mennyisége a mostanihoz képest. Az micro-architecture elbírná szerintem ezt a többletnyomást.
- az egészhez átvenném az Intel Core2-es load/store szemantikáját, igencsak megnövelt, (visszavonható) store-bufferrel
- az egészet megfejelném a Hyper-Threading egy olyan megvalósításával, ahogy nem teljesen szimmetrikus a szálvégrehajtás, hanem az OS-től kapott prioritás mentén lenne egy főszál és egy mellékszál, ami a főszál által nem használt execution- és retirement sávszélességet használhatná. Azonos prioritási szinten természetesen szimmetrikus lenne.

Az AMD CPU-k felépítéséből ebbe az egészbe leginkább a VectorPath decoder nem illik bele (Decoding a VectorPath instruction may prevent the simultaneous decode of a DirectPath instruction ezt úgy értelmezem, hogy ez olyan ciklusjellegű és ciklusváltozótól függő utasításoknál, mint a REP MOVSx, leállítja a teljes dekódolást az utasítás lefutásáig. Vajon az olyan x87 utasítások, mint FSIN, FCOS, FPATAN is ilyenek?). Az a kóbor rémképzetem van, hogy a K10-ben tapasztalt szembetűnő VectorPath->DirectPath (Double) áttérés és az x87 háttérbe szorítására figyelmeztetés valamelyik fenti elképzelésem felé visz, és afelé, hogy ''záros határidőn'' belül eltűnik a VectorPath.

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

Az eddigi cikkek szerint lesz javitas par dologban amit felhoztal:

Elagazasbecsles

- 512-entry indirect predictor
- double size return stack
- tracking more branches (nem talaltam szamot)

Load/Store

''Barcelona can now re-order loads ahead of other loads, just like Core 2 can. It can also execute loads ahead of other stores, assuming that the processor knows that the two don't share the same memory address. While Intel uses a predictor to determine whether or not the store aliases with the load, AMD takes a more conservative approach. Barcelona waits until the store address is calculated before determining whether or not the load can be processed ahead of it. By doing it this way, Barcelona is never wrong and there's no chance of a mispredict penalty. AMD's designers looked at using a predictor like Intel did but found that it offered no performance improvement on its architecture. AMD can generate up to three store addresses per clock as it has three AGUs (Address Generation Units) compared to Intel's one for stores, so it would make sense that AMD has a bit more execution power to calculate a store address before moving a load ahead of it.''

Privat velemeny - keretik nem megkovezni...

Ez a load/store volt eddig az egyik legkérdésesebb számomra, hogy mit lépnek az Intel-hez képest.

Éppen Socket F-re állok át...

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

Hali P.H.!

Kipróbáltam a REP MOVSB, FSTSW illetve FCOS utasításokkal is a dolgot, miszerint a VectorPath felfüggeszti a többi utasítás dekódolását. Ez nem teljesen igaz. Valóban lelassul a dekódolás, de nem áll meg.

Kipróbáltam egy X2-esen is hogy milyen IPC-t lehet elérni: 2,997

Arra tudnál (közelítő) értéket mondani, hogy mennyivel lassul? Nem teljesen titsza, hogy a fenti idézett mondatot hogyan kell értelmezni.
És ha nem áll le teljesen, akkor főleg az nem tiszta, hogy milyen jellegű microcode fut változó ciklushosszú VectorPath esetében.

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

FCOS + integer műveletek -> nincs lassulás
FSTSW + integer műveletek -> nincs lassulás
REP MOVSB + integer műveletek -> CX értékétől függ, CX=1 esetén nincs lassulás

Azt hiszem az 1.3, 1.4 es 1.17 szekciok segithetnek itt:
[link]

Privat velemeny - keretik nem megkovezni...

a legujabb infok szerint at kellene nevezni a topikot 10h-ra

Play nice!

#408?

Privat velemeny - keretik nem megkovezni...

Kipróbáltam egy X2-esen is hogy milyen IPC-t lehet elérni: 2,997
Ezt hogyan? Per-core? Csodálkoznék...

Mit használsz? Utasításszám, vagy a performance-counterek?

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

- a decoder-ek »mögé« tennél egy Intel-féle nagyméretű trace cache-hez hasonló macro-op cache-t tennék, levenné a L1-ről és a decoder-ekről a sokszori felesleges munkát (pl. minden ciklus-lefutás újrafordítódik). Azt ne feledjük, hogy AMD-nél a 1x-stage pipe hosszának kb. felét teszi ki a fordítás macro-op szintre.

Huh. Korántsem vagyok benne biztos, hogy ez jó ötlet. Jelenleg az AMD az alacsonyabb frekin mozgó magokat használja. Ezeken a frekiken a dekóderek elegendően jól működnek. Egy trace cache nagyon sok extra tranyót jelentene: a disszipációt nem csökkentené.

Heveny emlékeim szerint a performance counterek segedelmével ellenőrizhető, hogy a pipe hányszor fogy ki a melóból a dekóderek késlekedése miatt. Szerintem ez a szám elenyésző, és olyankor is inkább a főmemória lassúsága a valós gond. Azaz SZVSZ a sebesség sem nőne.

- az elágazásbecslés-szempontú ugrásvégrehajtás mellett az előbbi prefix-szel együttműködve alkalmaznám azt a (például IA-64-ben implementált) elágazáskezelési technikát, amelyben spekulatívan mindkét ágat elkezdi végrehajtani, majd a kiértékeléskor az hamis ág utasításait eldobja. Igencsak megnőne az eldobott utasítok száma, viszont ugyanennyivel (összességében nagyban) javulna a megtartott utasításokok mennyisége a mostanihoz képest. Az micro-architecture elbírná szerintem ezt a többletnyomást.
Láttam erre vonatkozó számítást, aszerint sajna nem sokat hoz. A SUN shadow threadje jobb. Csak ott egy pöttyet durvább a memória-architektúra. Megvalósítható, de régebbi tapasztalataim szerint sok esetben kifejezetten a memória a szűk keresztmetszet.

- az egészet megfejelném a Hyper-Threading egy olyan megvalósításával, ahogy nem teljesen szimmetrikus a szálvégrehajtás, hanem az OS-től kapott prioritás mentén lenne egy főszál és egy mellékszál, ami a főszál által nem használt execution- és retirement sávszélességet használhatná. Azonos prioritási szinten természetesen szimmetrikus lenne.
Akkor viszont nincs értelme a fentebbi mókának. A hatékony HT egyik feltétele kifejezetten az, hogy legyenek munka nélküli VE-k.


Egy HT jó lehetne, de akkor mondjuk 4 integer VE/AGU, meg még két FP VE egy megnövelt L1 mellé. A P4 azzal szúrta el, hogy az eleve lassú főmemória mellé egy nevetséges L1Dcache került. Itt a főmemória pöpec, de az L1 csak elégséges. Két szálnak kevés lenne.

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

''A P4 azzal szúrta el, hogy az eleve lassú főmemória mellé egy nevetséges L1Dcache került. Itt a főmemória pöpec, de az L1 csak elégséges. Két szálnak kevés lenne. ''

Sebessegre vagy kapacitasra gondolsz? Ha nagyobb lenne vagy meg lasabb lenne vagy komoly valtoztatasokat igenyelne a front-end hogy a mostani 3 ciklust megtartsak.

Szerk: Az irasodbol ugy ertelmeztem hogy itt=K8 vagy K10.

[Szerkesztve]

Privat velemeny - keretik nem megkovezni...

Leginkább kapacitásra. Mondjuk egy per-thread dedikált L1Dcache/ICache jó - és: durva - lenne

Itt=IMC.

Ui.: az a gond, hogy igazából semmi olyat nem látok, ami indokolná a K8 -> K10 nevezékváltást SZVSZ csalódás lesz a cucc, ha nem jön be még valami a képbe.

[Szerkesztve]

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Sokminden jo lenne, de a megnovelt merettel megnoveled a kesleltetest is es a mostanihoz kepest csak egy ciklussal is novelni mar plusz 33%-ot jelent. Nem biztos hogy jo irany.

Privat velemeny - keretik nem megkovezni...

Olvasom a topikot és egy rohatt mukkot nem értek
Nem lehetne halandó ember számára is érthetőbben irogatni mert egy tudatlan ember azt hiszi még a végén h az amd-nek a fejlesztő mérnökei vitatkoznak itt

Ha az ember féreggé teszi saját magát, ne csodálkozzon, ha rátaposnak.

AMD 45nm-en: [link]

Az embert a gondolkodás tette állattá...

Imádom a ??? cikkeket, mindig annyi újat tudok meg belőlük.

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

Hali Rive!

Kipróbáltam egy X2-esen is hogy milyen IPC-t lehet elérni: 2,997
Ezt hogyan? Per-core? Csodálkoznék...

Mit használsz? Utasításszám, vagy a performance-counterek?

Egyszerűen végrehajtottam rögzített mennyiségű utasítást (n) és a timestamp countert felhasználva megmértem hogy mennyi órajelre volt szüksége (t). Ebből számoltam ki az IPC értékét ( x = n/t ). Természetesen egy magon futott le az egész.

A mérés után megnéztem a K8 arhitektúra sematikus rajzát, ami alátámasztotta a fenti értéket. 3 párhuzamos utasításdekóder van benne.

Természetesen egyszerű utasításokat használtam ( FADD,FMUL,MOV,DEC,JNZ ).

[Szerkesztve]

Itt olvashatsz róla angolul: [link]

Az embert a gondolkodás tette állattá...

Ja, úgy más

Nincs kedved belemászni a perf. counterekbe?

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Hali Raymond!

Az ''ars technica'' cikk valóban érdekes, de első neki futásra kicsit gyanúsak voltak azok a kifejezések hogy: I'm guessing; I'm currently assuming; I'm suspect, ...

Szóval kicsit megmozgattam a Core2 lebegőpontos SSE műveleteket végző egységeit.

100.000 (8x12.500) műveletet végrehajtva az alábbi idők jöttek ki:

ADDPD reg0-7,mem -> 1,1 órajel / utasítás
DIVPD reg0-7,mem -> 31,1 órajel / utasítás (itt már jelentős a várakozás)
MULPD reg0-7,mem -> 1,1 órajel / utasítás (na, ezt hogy csinálta?!)
XORPD reg0-7,mem -> 1,1 órajel / utasítás
SQRTPD reg0-7,mem -> 57,2 órajel / utasítás

Gondolom az 1,1 órajelből az 0,1 azért jött be mert nem volt egy 9. regiszter a további latency time átlapoláshoz. Ha egy ADDPD 3 órajelig tart, és 1 órajeles átlag jött ki akkor hány DP (64 bit) összeadó dolgozott egyszerre? 6...
A MULPD-s mérést többször is átnéztem. Hibátlan eredménynek tűnik. Viszont ez azt jelentené hogy egyszerre 10 DP szorzó egységnek kellett működött. Ez szerintetek lehetséges? Tényleg ilyen ''FPU monster'' a Core2?

Gondolkodom rajta, de most még nem érdekel. Ugyan nagyjából tudom miről adhatnak infót a performance counterek, de gőzöm sincs mit kezdjek velük...

''Viszont ez azt jelentené hogy egyszerre 10 DP szorzó egységnek kellett működött. Ez szerintetek lehetséges?''

Ez lehetetlen. Ha az eredmeny jo is akkor a kovetkeztetes nem ul.

Privat velemeny - keretik nem megkovezni...

Tökéletes pipe-olt futtatási eredmény. 1-1 2x64 bites adder (ADDPD), szorzó (MULPD) dolgozik. Minden órajelben egy utasítás indul folyamatosan, a 3. vagy 5. órajel után minden órajelben egy vonul vissza, tehát az egész 100000+2 és 100000+4 órajel alatt fut le elméletileg.
A DIVPD és SQRTPD nem pipe-olt.
Az XORPD-t nem értem inkább. Nem 2 vagy 3 SSE ALU van a Core2-ben? 2 esetén már 0.5 órajel/utasításnak kellett volna kijönni.

''Gondolom az 1,1 órajelből az 0,1 azért jött be mert nem volt egy 9. regiszter a további latency time átlapoláshoz.''
Nem, a register-rename működik, minden utasítás eredményének új register-be kell kerülnie, a programozói register-készlet nem szűk keresztmetszet.


[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

Core2:
ADDPD reg0-7,mem -> 1,1 órajel / utasítás
DIVPD reg0-7,mem -> 31,1 órajel / utasítás
MULPD reg0-7,mem -> 1,1 órajel / utasítás
XORPD reg0-7,mem -> 1,1 órajel / utasítás
SQRTPD reg0-7,mem -> 57,2 órajel / utasítás

K8:
ADDPD reg0-7,mem -> 2,1 órajel / utasítás -> 2 db 64 bites összeadó (FADD,FMISC?)
DIVPD reg0-7,mem -> 34,1 órajel / utasítás -> 1 db 64 bites osztó (FMISC)
MULPD reg0-7,mem -> 2,1 órajel / utasítás -> 2 db 64 bites szorzó (FMUL,FMISC?)
XORPD reg0-7,mem -> 2,1 órajel / utasítás -> 2 db 64 bites logika (ALU)
SQRTPD reg0-7,mem -> 48,1 órajel / utasítás -> 1 db 64 bites gyökvonó (FMISC)

Szóval a K8 is veri a Core2-t, gyökvonásban.

Hali P.H.!

Most aztán megvagyok keveredve, a szorzó és az összeadó áramköröket illetően.

Ezek szerint a műveletet ténylegesen végrehajtó egységek is pipe-oltak vagy csak az ütemező?

Ezt úgy értem hogy gondolom a tényleges szorzás nem 1 órajel alatt hajtódik végre ( rengeteg tranzisztort igényelne ), hanem közben több részeredményből tevődik össze, így vannak ''lépések''. Ezek a részeredmények haladnak egymás után, és ezt nevezzük pipe-nak?

Vagy úgy működik a dolog hogy van egy rakás különálló szorzó illetve összeadó és az ütemező amikor talál egy éppen nem foglalt egységet valamint van mit ''belepakolni'', akkor odaadja neki az operandusokat, az kiszámolja az eredményt ( 3/5 órajel ) majd elveszi tőle?

''Az XORPD-t nem értem inkább. Nem 2 vagy 3 SSE ALU van a Core2-ben? 2 esetén már 0.5 órajel/utasításnak kellett volna kijönni.''

Harom.

Privat velemeny - keretik nem megkovezni...

''There are separate units for integer multiplication and floating point multiplication. The
integer multiplier on port 1 is fully pipelined with a latency of 3 and a throughput of 1 full
vector operation per clock cycle. The floating point multiplier on port 0 has a latency of 4 for
single precision and 5 for double and long double precision. The throughput of the floating
point multiplier is 1 operation per clock cycle, except for long double precision. The floating
point adder is connected to port 1. It has a latency of 3 and is fully pipelined.
Integer division uses the floating point division unit. This is the only unit that is not pipelined.''

Ebbol van: [link]

Ezekn kivul van meg ket erdekes az oldalon:
[link]
[link]

Mindegyik 2007-es update ugyhogy nem valami regi cuccok. Ami kicsit azert zavar az az hogy minden Core-rol szolo cikk kicsit mashogy irja le a belso architekturat. Apro de lenyeges kulombsegek. Pl. a portok felosztasan valahogy nem tudnak megegyezni

Privat velemeny - keretik nem megkovezni...

Ha a Quad core hozza a múlt héten bejelentett 2,9Ghz-es órajelet a kezdeti chipeknél akkor az Intelnek nagyon fel lesz adva a ledke... Szerintem 2,9 Ghz-en nem ,hogy nem csalódás hanem eléggé dúrván alázni fog a chip...

Téged is megzavart, hogy magát a CPU-t és az execution unit-okat is pipe-nak nevezik (én is, de az össes dokumentácó ilyen). Megpróbálom leírni röviden az K7-en levezetve a microarchitecure-t. K7-en, mert alapvetően alig tér el a K8 és a K10-től, és ehhez nagyon részletes dokumentációt adott ki az AMD.


Maga a teljes CPU egy pipeline, csak 3-way superscalar miatt órajelenként max. 3 ottani adategység léphet tovább a következő stage-re (minden ábrán minden szint között legalább 3 nyíl megy függőlegesen). A lépések, órajelenkénti bontásban:


cycle 1. FETCH: kiszámolja a következő utasításablak címét (+branch prediction, CALLs, RETs, ...), amit az L1-ből vagy a memóriából be kell tölteni.
cycle 2. SCAN: meghatározza az egyes utasítások elejét és végét, majd vagy a DirectPath-ra (legfejlebb 6 utasítás/órajel) és VectorPath-ra továbbítja őket (legfejlebb 1 utasátás/órajel).
cycle 3. ALIGN1 (DirectPath): 8-byte-os sorokban kapja az utasításokat, minden sorban legfejlebb 3 utasítás lehet (ekkor még minden 1 byte-os x86 utasítás VectorPath-ra került), 9 ilyen sort pufferel. Minden órajelben legfejlebb 3 utasítást megpróbál továbbítani az ALIGN2-be.
cycle 3. MECTL (VectorPath): a kapott VectorPath-utasításhoz meghatározza a microcode-ROM belépési címét.
cycle 4. ALIGN2 (DirectPath): prefix-ek, az opcode-, ModR/M- és SIB-byte-ok megkeresése, és ezen információk továbbítása.
cycle 4. MEROM (VectorPath): a microcode-ROM-ot megnyitja (indexeli, nem is tudom, hogy mondjam) az adott belépési pontnál.
cycle 5. EDEC (DirectPath): az ALIGN2-ből és a MEROM lépcsőtől kapott infomációk alapján macro-opokká dekódolja az utasításokat. Ezenkívül meghatározza az azonnal argumentumokat, register-pointereket és eltolásokat.
cycle 5. MEDEC/MESEQ: közvetlenül a microcode-ROM-ból jönnek a macro-opok (ezek saját különálló belső register-csoporton dolgoznak)
cycle 6. IDEC/Rename: a macro-opok elosztódnak a két ütemező között. Az összes macro-opnak, ami az FPU-egységbe kerül, a register-argumentumai leképeződnek a belső registerfile egy-egy elemére (itt fordul át pl. az 'XMM1' vagy 'MM6' a megfelelő sorszámú belső register sorszámára - 88- vagy 120-entry register file).

Innen az összes macro-op a Instruction Control Unit-ba (ICU) kerül. Innentől a pipe egy hurok, tehát tovább innen indulnak a macro-opok, és itt is fejezik be pályafutásukat (visszavonulás/retirement), vagy az machine state-nek (register-ek, flags, ...) eredményük szerinti felújításával, vagy kiléptetéssel (mert téves elágazási ágjóslat volt), illetve itt váltódnak ki a kivételek is. Ez osztja el a macro-opokat az integer és a FPU-egységek felé.


Az integer egység:
cycle 7. SHED: az integer ütemező, itt várják meg a macro-opok, hogy megérkezzen az összes input adatuk. (És AMD-nél valóban megvárják, nem úgy, mint Netburst alatt.) Közvetlen kapcsolata van a result bus-sal, így az input adatok nem a véglegesített machine state-ből jönnek, hanem rögtön a kiszámolás után. Innentől az elemi egységek a macro-opok helyett micro-opok, ezekből egyszerre legfejlebb 6 léphet tovább órajelenként, 3-3 az ALU-kba és az AGU-kba.
cycle 8. EXEC: a micro-opok végrehajtódnak, az eredményüket kiteszik a result bus-ra. Ha egy macro-opban levő minden micro-op lefutott, akkor az ICU elindítja a visszavonulási (retirement) folyamatot.
cycle 9. ADDGEN, cycle 10. DCACC, cycle 11. RESP: address generation (effektív -> lineáris cím konverzió, az effekív címet számolják az AGU-k), Data Cache access, Response, load/store kapcsolat a Data Cache-sel.


Az FPU-egység sokkal ''érdekesebb'':
cycle 7. STKREN: stack rename órajelenként legfeljebb 3 macro-opot fogad az ICU-ból, valamint x87 utasításoknál az ST(x) alakú stack-relatív formát fordítja a megfelelő sorszámú belső register sorszámára (88- vagy 120-entry register file)
cycle 8. REGREN: register-átnevezés. Minden művelet eredménye fizikailag más register-be íródik (tehát az ADDSS xmm0,xmm2 formában a bemeneti értékek mondjuk az fp15 és fp54 fizikai register-ek, de az eremény NEM az fp15-be fog íródni, hanem egy másik register-be.
cycle 9. SCHEDW: sheduler write, akkor íródnak a macro-opok az ütemező pufferébe, órajelenként 3.
cycle 10. SHED: maga az ütemező. Innentől megint a micro-op az elemi egység. Az ütemező folyamatosan scan-neli a puffer-ét, legfejlebb 3 olyan micro-opot keresve, amiknek már nem kell várniuk a bemeneti értékeikre, hogy továbbítsa ezeket az EXECUTION UNIT-ok felé. Minden micro-op csak bizonyos unit-ban indulhat el, néhány micro-op csak ''bizonyos időben'', mind a háromra keres egy-egy ezeknek megfelelőt. Azok még a következő órajelben a cycle 11. FREG stage-ben a register-ekből kiolvassák a bemeneti értékeiket (minden unit saját, belső register-eivel dolgozik, nem közvetlenül a register-file-ba), majd elindul a futtatásuk.

És ezek az execution unit-ok az FADD, FMUL és az FSTORE/FMISC. Órajelenként egy micro-opot tudnak fogadni, az ábrán megnézve a CPU 15 stage-es pipe-ja itt (megint, mint ahogy a két ütemező felé, vagy a 3 ALU/AGU esetében) elágazik, az FEXEC1-FEXEC4 az 12., 13., 14. és 15. stage-ek vertikálisan, de ezek 3 különálló pipe különböző szintjei. Valójában nem is három, mert egy-egy unit megintcsak többfelé ágazik, csak a port közös bennük. Ráadásul ezeknek az ágaknak nem is mindegyike teljesen pipe-olt (pl. az osztó), és nem is egyforma hosszúak (az MMX ALU csak 2 lépcsős, FEXEC12 és FEXEC 13 szintje van csak), de a leghosszabb ág is csak négy stage hosszú.
az FADD alágai: 3DNow!/SSE adder, MMX ALU/shifter, FP adder
az FMUL alágai: 3DNow!/MMX multiplier/reciprocal, MMX ALU, FP multiplier/divider/square root (ez utóbbi úgy pipe-olt, hogy négy lépcső hosszú, de az egyik lépcsőben mondjuk 30 órajelig marad az micro-op számolás közben).
Említettem, hogy a portok órajelenként tudnak egy micro-opot fogadni, viszont az alágak nem törvényszerűen. Ezért szokták megadni utasításszinten a latency mellett a throughput-ot mint legfontosabb adatot, azaz, hogy ugyanaz az ALÁG hány órajelenként tud új utasítást fogadni. Ha az alág pipe-olt, akkor órajelenként egyet, de ha nem, akkor meg kell várni majdnem a teljes lefutást. Például az lappangása K8-on DIVPD 37 órajel, és a következő DIVPD 34 órajel múlva indulhat el. Viszont ezen 34 órajel alatt az FMUL egység vígan tud fogadni és lefuttatni 34 szorzó micro-opot.
A másik lényeges dolog ezeknek az egységeknek a szélessége. Ha K8-ról beszélünk, akkor ott egy 64 bites összeadó van az FADD egyégben, ezért egy ADDPD macro-opja két összeadó micro-opot fog tartalmazni, ezek egymás utáni órajelekben lépnek be az FADD potján, egymás után mennek a pipe-stage-eken, a második 1 órajellel később fejeződik be, ezért programozói szinten ADDPD utasítás lappangása 5, átvitele 2. Tegyünk mellé még egy 64 bites összeadót, ekkor az ADDPD-hez csak egy micro-op kell, nem gyorsítunk semmit magukon az elemi összeadókon, és máris az ADDPD lappangása 4, átvitele 1 lesz.

Remélem, így már tisztább.

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

Remek! Köszönöm.

Újabb ezernyi kérdésem lett.
Jöhet belőlük egy pár?

1, Mit jelent és miért jó az hogy az L2 Cache 16 utas?
Gondolom egyszerre 16 hozzáférési kérelem ( írás / olvasás ) irányulhat a cache vezérlőhöz, de honnan a fenéből jön össze ennyi kérelem?

2, Az AGU-k generálják a memória operandusok címeit?
Ebből az következne hogy pl. egy ADD reg,mem legalább 2 macro opból áll. Először lefut az AGU-n a memória operandus címképző macro opja, majd utána az ALU-n lefut az összeadás. Valamint a lebegőpontos/MMX egységnél az FSTORE végzi azt a munkát mint az integer résznél az AGU. Jól gondolom?

Hat ennyi munka utan igazan megerdemled

Privat velemeny - keretik nem megkovezni...

A végéről kezdve:

Az AGU-k generálják mindig a címet, legyen az load, store vagy load/store (utóbbi csak x86 integer utasításkészletben van). A betöltött adat rákerül a result bus-ra (a legelső képen nem ábrázolják teljesen, de a load/store queue-ból feletti, belőle kiinduló nyilak megfelelnek neki), innen kerül a megfelelő műveletekhez.

Igen, az ADD reg, mem két micro-opból áll, egy load és egy add. Van még store és load/store micro-op, utóbbi az ADD mem,reg hatékonyságát segíti elő, nem kell a címet kétszer kiszámolni (mint P3-mon, és úgy sejtem, Netburst-on, köszönhetően az Intel teljesen micro-op szintű megközelítésének).

x-utas csoportasszociatív cache: nem a kérelmek számát jelenti, hanem a cache leképezését a fizikai memóriára.
Ha teljesen asszociatív a cache, akkor a fizikai memória bármely területe kerülhet bármely cache-vonalra. Hozzáféréskor viszont keresni kell a teljes cache-ben, nagyon lassú, mert az összes vonalat meg kell vizsgálni.
Ha direct-mapped, akkor a fizikai memória annyi azonos méretű folytonos területre van felosztva, ahány cache-vonal van, és minden területről ugyanarra a cache-vonalra kerül az adat. Nagyon gyors, nem kell keresni, de nem hatékony, gondolom, nem kell mondanom, miért.
x-utas csoportasszociatív cache: a kettő keveréke. Adott fizikai cím a cache meghatározott x számú vonalának egyikén lehet, csak ezek között kell keresni. Ez általában a fizikai cím legfelső x bit-jének elfelejtésével generálják, ezért a folyamatos memóriaterületek hozzáférése is hatékony marad.

Raymond: köszönöm, akad itt egy-két egység belőle.

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

macro-op cache: nem gondoltam a disszipációra, csak arra, hogy a ciklus-utasítások megspórolnának pár stage-t (gyorsulás). Az x86 beállt olyan 60-120W fogyasztásra, beleférnek növelő lépések, más, csökkentő lépések mellett.

elágazás-kezelés: úgy gondoltam, hogy csak azon elágazásoknak futna le mindkét ága, amelyek rendelkeznek az előző pontban említett prefix-szel, tehát a fordító jelezné, hogy IF-ELSE-ről van szó, és a displacement 8 bit-es (ezt elírtam), szóval a L1 instruction cache-re sem nehezedne számottevően nagyobb nyomás. Cikluselágazásokra teljesen megfelelő az eddigi becslési módszer. Ilyen vegyes megoldást még nem láttam sehol, és az random adatokon alapuló IF-ELSE-t minden mai x86 architechure is megsínyli. A prefix ötletét meg az Intel branch hint prefix-éből vettem.

Hyper-Threading: nem hiszem, hogy (prioritással kiegészítve) szélesíteni kellene a jelenlegi architectúrát. A fő cél az execution unit-ok lehető legteljesebb kihasználása, úgy, hogy ne egymás elől vegyék el a sávszélességet, bármilyen áron. Felsoroltam az elgondolásaimat, nem biztos, hogy mindegyik megfér egymás mellett.
El tudom képzelni, hogy egy high-class szál mondjuk az ő CPU-idejében főszálként fusson, máskor pedig mint másodszál, ami kihasználja a szabad execution portokat és macro-op helyeket. Persze, ez akkor hoz nagy teljesítménynövekedést hogy igaz, amit sejtek, hogy decode után (azaz utasítássorrendben) AMD-nél macroop-hármasoknál nincs vízszintes mozgás, tehát egy IMUL eax,ebx; IMUL ecx,edx; ADD esi,edi két hármasra fordul, ugyanúgy, mint egy ADDSS xmm0,xmm1; ADDSS xmm2,xmm3; MULPS xmm4,xmm5 (The instruction control unit takes the three macro-ops per cycle from the early decoders and places them in a centralized, fixed-issue reorder buffer). Ezesetben a tripletek teli vannak üres helyekkel (bubbles), amit ki lehetne tölteni.

Az Intel a cache mellett azzal is elszúrta, hogy a HyperThreading-et a PPro óta megjelent ''legkeskenyebb'' micro-architektúráján alkalmazta (4 port, shared INT/FPU).

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

Amindenit ez ám a nem mindegy!
Ha ez így megy tovább, lehet, hogy célszerűbb lenne a topik címét ''Nagy AMD K10 tudós topic''-ra átneveztetni.

extra - SEXRay

[link]
a bábelhal a barátod

[link]

Hmm.. A Dual quad core Barcelona az 1080P trailert H.264-ba majd' real time kódolja?

https://hardverapro.hu/aprok/hirdeto/cyberslider/index.html

Szerintem ezekből nem lenne észlelhető gyorsulás.

Régebben dolgoztam már perf. counterekkel, akkor még egy kínlódás volt az egész. Most, ahogy hirtelen utánakapargattam, már sokkal kultúráltabb a dolog. Szóval regisztráltam az AMD-nél és letöltöttem a vonatkozó szoftvert. Néhány nap/hét, és lesz valami hiteles kép a tényleges szűk keresztmetszetekről. Esetleg más is megpróbálhatná a dolgot.

A tényleges végrahajtás során előforduló valós szűk keresztmetszetek ismerete nélkül nem nagyon lehet megbecsülni, hogy ténylegesen mitől mehetne jobban egy proci.

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

ebből vissza lehetne fejteni vmilyen közelítéssel a teljesítményt?

extra - SEXRay

Hali Rive!

Tudnál segíteni abban hogy hol, merre keressem ezt az AMD softvert, illetve hol kell regisztrálni. Sajnos az AMD lapja nekem egy kicsit kesze-kuszának tűnik.

[link]

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Hát azért egy dual quad core durva, nem most lesz ilyen az asztalunkon
Az adott file-t át kéne nyomni egy X2-n, meg egy Core-on aztán összehasonlítani azzal.

https://hardverapro.hu/aprok/hirdeto/cyberslider/index.html

Vagy megnézni hogy egy hdv videót hogy tömörít egy mostani proci........

https://hardverapro.hu/aprok/hirdeto/cyberslider/index.html