-
GAMEPOD.hu
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
-
#95904256
törölt tag
Mivel jómagam nem szoktam videokódolást csinálni, ezért kíváncsiságból elővettem az egyik Prohardver!-es tesztet hogy megnézzem mennyivel is marad el a Core2 az előző arhitektúrára való duplázástól. [link]
Nos itt ilyesmi áll hogy:
MainConcept AVI -> MPEG2
C2D E6300 1866MHz: 119s
PD 925 3000MHz: 140s
Órajellel arányos gyorsulás: 1,89
Windows Media Encoder 9 MPEG2 -> WMV
C2D E6300 1866MHz: 104s
PD 925 3000MHz: 124s
Órajellel arányos gyorsulás: 1,92
Auto Gordian Knot... MPEG2 -> AVI
C2D E6300 1866MHz: 142s
PD 925 3000MHz: 177s
Órajellel arányos gyorsulás: 2,00
XMpeg v5.03 ... MPEG2 -> AVI
C2D E6300 1866MHz: 89s
PD 925 3000MHz: 108s
Órajellel arányos gyorsulás: 1,95
Ezek alapján valóban nem éri el a kétszeres sebességet, de azért nincs messze.
Ráadásul kétséges hogy ezek a programok C2D optimalizált kódot futtattak.
Valamint ne felejtsük hogy ezeket az eredményeket más is korlátozta (pl:memória).
Szerk.: Tehát ez a 128 bites SSE / 64 bites adatút nem duplázott dolog cáfolva.
[Szerkesztve] -
Raymond
félisten
''Azért hoztam fel, mert ugye magonként kellene hasonlítani, azonban a P-D nem 2x gyorsabb, mint a megegyező órajelű P4,''
Nem is lehet, mert a P4 HT-vel, a PD pedig anelkul volt merve. Igy nem egy mag versus ket mag a teszt hanem 1+ versus 2.Privat velemeny - keretik nem megkovezni...
-
#95904256
törölt tag
akosf: ''A linkelt tesztben az L2 a Pentium-D-ben és Core2-ben is 2-2 MB magonként.''
dezz: De az utóbbiban közösített, ami egy kétszálas kódolásnál számíthat.
Ez elvileg lehetséges!
Jó lenne látni egy tesztet, erre a megosztott cache-s dologra...
Itt a Prohardveres! tesztben használt programoknál azonban kétséges hogy a Pentium-D illetve Core2-őn futtatva más-más kód futott volna. Valószínűleg épp azért futtaták ugyanazt a programot hogy összehasonlítható eredményeket kapjanak. A megosztott cache használatra egyébként kikell okosítani a programokat, ezt az oprendszer nem képes automatikusan lekezelni. Ez nem egyszerű feladat. Másfelől videokódolásnál nagyon nem is látom túl nagy hasznát, ugyanis itt folyamatosan változik a bemenő adat. Ennek a megosztott cache-nek akkor lehet jelentős szerepe ha pl. egy méretes Look-Up Táblát (LUT) használ az ember. Szerintem... -
#95904256
törölt tag
Ez az L2-n keresztüli adat utaztatás csak úgy működik ha az egyik szál számára lefoglalsz egy adatterületet az OS-től, majd elérhetővé teszed ezt a területet a másik magon futó szál számára is. Ekkor egy memóriacímről olvashat a két szál. Ha szerencséd van, akkor ez a memóriaterület az L2-be is bekerül...
-
Raymond
félisten
Hidd el lenyegtelen. Akkora bemeno es kimeno adatmennyiseggel dolgozol hogy a cache nem jatszik szerepet. A videokodolas a stream processing egyik legregebben mainstreamesitett peldaja. De hogy ne csak beszeljek rola: [link] 4MB->1MB L2 csokkenes alig hoz valtozast.
Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
''Ja, A64-es megjegyzésre: ja, látom, ha más is fut, akár ''passzívan'', az eléggé befolyásolja az eredményt. Azért nem egészen tökéletes a WinXP multitaskja.''
Masrol lehet szo, mert a PM-es gepen semmi nincs a Win-en kivul. A PD-s eredmenyeken pedig latszik hogy OS-tol nem fugg a dolog. Tobbszor futtattam a programot egy kornyezetben es az elteresek csak nagyon kicsik voltak a futasok kozt.Privat velemeny - keretik nem megkovezni...
-
#95904256
törölt tag
A PerfMonitorral méret IPC=0.6 jó értéknek tűnik. Elméletileg IPC=0.5 a maximumum az E6-os Sempronon, hisz a 128 bites SSE összeadás műveleteket 2 egymást követő 64 bites összead-s műveletként futtatja, és ebből egyszere egy órajelre csak egyet tud indítani. Az IPC=0.5 feletti érték azért jött ki mert van ott a ciklusmagban két integer utasítás is, a ciklusszervezés miatt. A PerfMonitor minden bizonnyal ezt is belemérte.
Elvileg 2.000.000.000 órajel szükséges hogy 64 bites SSE enginnel lefusson a kód. A többi órajel többmindenből adódik össze, egyrész az TimeStampCountert kezelő programrészlet illetve az első ciklusban az adatok cache-be tárolása igényel néhány száz órajelet. A többi a megszakításokból és az azokat lekezelő windows rutinok futásidejéből adódik.
Természetesen lehet olyan kódot is írni ami a fetch/dekóder részt is leterheli, de itt most arról volt szó hogy a 128 bites SSE engine-t valóban megfojtja-e az adatutak szűkössége vagy sem. Egyébként a fetch/dekóder részt szerintem meglehet fojtani hosszú SSE(2) utasításokkal, de ekkor még lazábban fogja tenni az SSE műveletvégző a dolgát, vagyis épp az ellenkezőjét érjük el mint amit szerettünk volna... -
P.H.
senior tag
Ahogy mondod. Nem ingatta meg azon hitemet, hogy teljesen független utasítások esetén (akosf kódja 8 SSE-utasítás, max. 5 latency mellett, tehát abszolút in-order ütemezés, egy execution unit-ra) kétszeres a növekedés, (by throughput), teljesen függőség esetén legfeljebb 25% (by latency).
Akosf: cseréld ki az összes célregister-t xmm0-ra, így láthatjuk, lesz-e 25%-os növekedés.
Az user-kódok valahol a kettő között vannak. Hétvégén kiollózok egy ilyen '''user-kódot'' (lesz benne egy 3+1 szálas JPEG_decode_to_YUV + YUV->32bitBMP + stretch_to_screen - a'la Irfanview, csak lassabb és jobb eredményt ad - 4x4MB-os pufferekkel kommunikálva (csak SSE), egy amúgy is ''állatorvosi ló'' (SSE2, SSE és x87 implementációval) és egy brute-force (SSE2 és x87), ha lesztek partnerek, meglátjuk az eredményt ott is.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
-
P.H.
senior tag
Ha így nézzük tovább, akkor 3->2 33%, 2->1 50%, pedig utóbbi esetben azonos idő alatt kétszer annyi utasítás fut le. De soha nem voltam erős matekból.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
-
#95904256
törölt tag
-
P.H.
senior tag
''Amúgy jelen állás szerint már az is jó hír, hogy még idén kihozzák a 2.5 GHz-eseket is. Szerver vonalon már az is eléggé versenyképes. Asztalon már inkább csak bizonyos alkalmazásokban.''
A 2 GHz alatti/körüli Core2-k mennyire versenyképesek manapság asztalon a(z 'előző generációt' képviselő) 3 GHZ feletti Pentium-D-kkel?
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
Raymond
félisten
Jol nezett ki az investorhub-os post, de valaki mar elmagyarazta neki hogy rossz SKU-kat hasonlitott ossze: [link]
Az alacsony orajelek elsosorban azert lehetnek mert 4 magnak kell megutni bizonyos mercet hogy az adott SKU bin-be bekeruljon. Hiaba megy 3 mag 2.5 Ghz-n ha a negyedik csak 2.2-n megy megbizhatoan akkor az egesz chip 2.2 lesz. Az hogy opteronrol van szo szinten nem javit a helyzeten, mert a minosegi tesztek meg szigorubbak mint a desktop termekeknel ugyhogy meg nehezebb egy magasabb bin-be bekerulni.Privat velemeny - keretik nem megkovezni...
-
#95904256
törölt tag
Hali dezz!
Értem én hogy szépen kijön, de mégis hogyan?
Ezzel csak azt akarom mondani hogy szerintem senki nem fog tudni mutatni olyan float-point kódot ami 3,6-szor gyorsabban fog futni a K10-en mint a K8-as magon. Esetleg úgy tudom elképzelni hogy egy SSE4 optimalizált kódot futtatok a 128 bites motoron egy a 64 bites motoron futó SSE2 kód ellenében ... de ezt is csak azért mert bízom az SSE4-ben. -
#95904256
törölt tag
Hali dezz!
Mi az ami egyre rosszabb?
Idézem még egyszer ami pár sorral feljebb a #1278-ban is olvasható.
All of the decoders can decode one macro-fused pair per cycle, with up to three other instructions, resulting in a peak decode bandwidth of 5 instructions per cycle.
Remélem most jobban látszik. -
#95904256
törölt tag
Ezek remek ábrák!
dezz:Itt 4 mikroOP széles ''csatorna'' látható, és tesztek szerint ebből 1 lehet fúzionált, azaz 4 v. 5 mikroOP mehet át, ami 2,0 v. 2,5 x86/stb. utasítás.
A 4/5 mikroOP bizony jelenthet 4/5 utasítást is a Core2 esetében, ugyanis az utasítások jelentős részénél 1 utasítás = 1 mikroOP megfeleltetés áll fenn, ha nincs memória hivatozású operandus.
dezz:És amikor ezt összehasonlítod a K10 ide vonatkozó csatornájával, ami 3 szintén ''uop''-nak van jelölve, vedd figyelembe, hogy az valójában nem mikroOP ott, hanem AMD-féle makroOP, ami egyenként 2db mikroOP. (Ez a nem teljesen korrekt jelölés fel lett róva a szerzőnek, írta is, hogy talán módosítania kellene a képen, de végül nem foglalkozott vele tovább.)
Na, ez lehet hogy egy kicsit homályos nekem. De a Decode csatornákon keletkező 1/2 mikroOP az csak 1 utasítást jelent, nem 1/2-őt. Vagy tévedek? -
#95904256
törölt tag
dezz, akkor most a segítségedet kérem. Ugyanis nem értettem meg hogy ''a dekódolás szélessége önmagában nem döntő tényező''. Először is, ezt miért mondod? Másodszor mit értesz ''döntő'' alatt? Harmadszor ha a döntő = jelentős, akkor miért nem az?
Egyébként ha azt veszem amit már írtam, hogy az IPC=1,5 értéket is nehéz elérni akkor ezzel csak megerősítettél abban hogy az IPCmax érték növelés nem hoz túl sokat a teljesítmény növelésében. -
#95904256
törölt tag
akosf:Na, ez lehet hogy egy kicsit homályos nekem.
dezz:Melyik része?
Úgy tudtam hogy a K10 egy decode egység csak egy utasítást fordít 1-2 microOP-ra.
Te meg írtad hogy a decode egységek kimenete 1-2 microOP-ot generál.
Nem tudtam mire venni a dolgot. De ezek szerint csak redundáns információ.
akosf:De a Decode csatornákon keletkező 1/2 mikroOP az csak 1 utasítást jelent, nem 1/2-őt. Vagy tévedek?
dezz:Nem tévedsz, de én nem is mondtam mást. 3,0 -> 3,0.
Nem mondtam hogy mást mondtál.
A kérdést azért tettem fel hogy tisztázódjon a homályos folt.
Tisztázódott. Mindketten ugyanazt állítjuk. -
dezz
nagyúr
Sőt van itt még valami. AMD-nél 1db VectorPath, vagy 3db DirectPath, akár összetett, 2 mikroOP-os utasítás mehet át. Intelnél viszont csak az egyszerű, 1 mikroOP-osokból mehet át több (*), az összettekből viszont csak 1...
* Elvileg ugyan minden Simple Decoder tudja a mikroOP fúziót, azonban ez nem tűnik igaznak, mivel tesztek szerint 4 egyszerre végrehajtott mikroOP-ból csak egy lehet fúzionált. (Akinek van kedve, letesztelhetné.) -
dezz
nagyúr
Ja, és még van egy kis bonyolítás AMD-nél: a DirectPath lehet Single (1 makroOP -> 1-2 mikroOP) v. Double (2 makroOP -> 2-4 mikroOP). Mivel az ábrán keveredik a mikroOP és a makroOP, nem vagyok benne biztos, hogy az (egyszerűbb) dekóderek kimenete is 1-2 makroOP vagy 1-2 mikroOP (azaz 1 makroOP) per ciklus. Szerintem makroOP-ról van itt is szó. Szóval ez a rész itt elég ''ütős''.
Csak azt nem értem, hogy akkor ezek után a Pack Buffer miért csak 3 makroOP széles? Így ugyebár a DirectPath Double utasítások torlódnak, azaz azoknál sem jöhet össze a 3,0-ás IPC. Feltéve, ha ez egyátalán korrekt infó, mármint a 3 makroOP széles Pack Buffer kimenet, és persze az elhagyhatatlan retirement. Kedvenc doksinkban (10h opt. guide) ezt találtam:
''The fetch window has changed from 16 bytes on previous AMD64 processors to 32 bytes on AMD Family 10h processors. The 32-byte fetch, when combined with the 128-bit floating-point execution unit, allows the processor to sustain a fetch/dispatch/retire sequence of three large instructions per cycle.''
Szerintetek ez mit jelent? Úgy hangzik, mintha az alap x86/stb. utasításokról lenne szó. (Persze a VectorPath-osokról biztos nem, mert abból egyszerre egyet tud. -- Megjegyzem, a VectorPath elnevezés kicsit csalóka, nem sok köze a vektor [SSEx] egységekhez, azaz a legtöbb SIMD-es utasítás DirectPath-os, sőt abból is Single. Ugyanakkor pl. a bitmanipulációs műveletek jó része VectorPath-os.)
[Szerkesztve] -
dezz
nagyúr
Na jó, közben elértem a Figure 8-hoz, és az utána következő részhez - amit korábban már persze néztem, de kicsit megfeledkeztem róla. Szal úgy tűnik, tényleg 3 makroOP-ról van szó, ennyi az áteresztő képesség. Viszont nincs ésszerűtlenség, mert a dekóderek kimenete is egyenként 1 makroOP széles, nem több.
bocs a floodért, csak itt magamban beszélgetek
[Szerkesztve] -
#95904256
törölt tag
Szerintem a DirectPath Double kódolású utasítások két, időben egymás után létrejövő makroOP-ra fordulnak le. Ezért is lehet az hogy a DirectPath Double utasítítások ( az XCHG reg,reg utasítást kivéve ) mind legalább 2 órajel késleltetéssel rendelkeznek.
Példa:
BTC reg,reg -> BT reg,reg ; XOR reg,mask(reg)
CALL near -> PUSH ESP ; JMP near
JCXZ near -> CMP CX,0 ; JZ near
LEAVE -> MOV ESP,EBP ; POP EBP
Természetesen a második oszlopban, ahová szintén utasításokat írtam ott több a kombinációs lehetőség mint a rögzített x86 utasításkészletben, mert ezek tulajdonképpen 1-2 mikroOP-ot jelentenek. Vagyis egy DirectPath Double 2\3\4 mikroOP-ra fordulhat le, míg a DirectPath Single csak 1\2-re. Ezekből persze egyik-másik mikroOP végrehajtási ideje több órajelet is kitehet.
Egyedüli kivétel a fent említett XCHG reg,reg utasítás, ami megcáfolhatja ezt a dolgot. Ugyanis ez a K8-ban még 2 órajeles VectorPath utasítás volt, viszont a K10-ben már csak 1 órajel késleltetésű DirectPath Double utasítás. Ez meg hogy lehet?
[Szerkesztve] -
#95904256
törölt tag
dezz:Írnál 1-1 konkrét példát 2 mikroOP-os Single-re, és 2-3 mikroOP-os Double-re? Úgy értem, hogy pontosan mi történik.
Nem tudok ilyet írni, mert nincs hozzá dokumentációm. Csak találgatni lehet a mikroOP-ok felépítéséről és arról hogy melyik utasítás mennyi mikroOP-ra fordítódik le. -
P.H.
senior tag
''Írnál 1-1 konkrét példát 2 mikroOP-os Single-re, és 2-3 mikroOP-os Double-re? Úgy értem, hogy pontosan mi történik.''
Induljunk ki ebből: [link]
Minden macro-op kap egy saját tag és egy #chn értéket, valamint minden micro-op kap minden egyes bemeneti értékére egy-egy tag-#chn párt, amitől függ (legrosszann esetben két register plusz a FLAGS, ha egyet sem sikerült kiolvasni valamely registerfile-ból).
Vegyük az ADD EAX,[EBX+ECX] utasítást: ez DirectPath Single, két micro-oppal: MOV temp,[EBX+ECX] AGU micro-op, két forrásértékkel, tehát legrosszabb esetben két előző utasítástól függ (nem sikerült kiolvasni az értéket valamely registerfile-ből), ezek tag és #chn értékeit megkapja. (pl. ADD EBX,01h; ADD ECX,01h; ADD EAX,[EBX+ECX] utasításfolyam); valamint egy ADD EAX,temp micro-oppal, ekkor állítsuk be úgy a tag és #chn értékeket benne, hogy az EAX-re legyen a tag és #chn érték a megfelelő előző utasításé, a temp-re (ami valójában magát az egyik result bus-t jelenti) pedig a saját macro-opjának értékpárját. A saját tag-ja egyetlen esetben fog megjelenni a #chn-nel jelzett result bus-on: ha lefutott a load.
Ebben az nem tiszta, hogy egy ezt követő, EAX-tól függő utasítás hogyan különbözteti meg, hogy a load vagy maga az összeadás történt-e meg, ehhez valami (eddig számomra nem világos) további információ is szükséges. Bár minden macro-op (vagy micro-op?) rendelkezik egy 'finished' state-tel, ez elégséges lehet.
Fordított eset csak ADD [EBX+ECX],EAX esetben lehetséges, itt egy kicsit bonyolódik a dolog. Van egy AGU-művelet, amely kiszámolja az EBX+ECX értéket, és betölti a megfelelő adatot, majd az ADD elvégzi az összeadást, eddig ugyanaz, mint fentebb. Az ADD is kiteszi a tag értékét a megfelelő #chn result bus-ra. Viszont a load/store ''megült'' a Load/Store Queue-ban, és tovább figyeli a result bus-t, hogy mikor jelenik meg ez a tag (amikor ő kiküldte, hogy 'load completed', az persze nem számít). Ha ez megtörtént, akkor elvégzi a store-t (a címet már ismeri).
A Double egy kicsit nehezebb dolog: K8 esetén a PUSH EAX Double, itt a macro-opok között is meg kell tartani megfelelő sorrendet. Talán erre is szolgál a pack-stage, de ebbe ugye még mindig nem látunk bele teljesen. De pl. 128 bites utasítások esetében nem is fontos a sorrend, teljesen mindegy, hogy a felső vagy az alsó 64 bites művelet hajtódik végre előbb, ebben egyedül az ütemezők egyik legfontosabb alaptörvénye ad útmutatást: ha több micro-op alkalmas a futásra adott órajelben, akkor mindig a (programsorrendben?) legkorábbit fogja indítani.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
''a Table 15. 128-Bit Media Instruction Latencies-ben csak azok az utasítások Single-k, amikben vagy csak egy aritmetikai, vagy csak egy load/store/load-store művelet végződik el? Amikben meg egyszerre a kettő, azok meg mind Double-k.''
Melyekre gondolsz? Én K10 Opt. Reference-ben ilyen bejegyzéseket látok:
ADDPD xmmreg1, xmmreg2 (mem) DirectPath Single FADD 4 (6) 1/1
ADDPS xmmreg1, xmmreg2 (mem) DirectPath Single FADD 4 (6) 1/1
Az előző OFF részhez: nem csak a 'finished' state vezethet, hanem elég hangsúlyos, hogy a három ALU/AGU-egység közvetlenül is kommunikálhat egymással, a result bus megkerülésével. Lehetséges, hogy ennek itt van szerepe.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Affene, én is lassan flood-olok...
''A 4/5 mikroOP bizony jelenthet 4/5 utasítást is a Core2 esetében, ugyanis az utasítások jelentős részénél 1 utasítás = 1 mikroOP megfeleltetés áll fenn, ha nincs memória hivatozású operandus.''
A véleményem: kézzel írt assembly-kódban valóban sokkal kevesebb a memória-operandus, mint fordított kódokban. Viszont általában a programozási nyelvek alapjai a változók, ezeken dolgoznak, tehát minden egyes utasítás egy-egy betöltés-(jó esetben komplex) operation-tárolás sorozat. Persze adottak a register direktíva, némi fordítási optimalizáció, illetve a ciklusváltozók register-ben tartása (ahogy én észrevettem, ezekre a célokra az ESI-EDI-EBX használatos - a kernel-hívások ezek értékeit megtartják, plusz az EBP-t természetesen -, de az objektumorientált nyelveknél ide kerülnek még maguknak az objektumoknak a címei is, tehát elég szűkös a készlet). Az említett kompex operation-ökkel meg az a baj, hogy jó hosszú szekvenciális függő utasításfolyamot generálnak, amin túl kell látnia az out-of-order magnak, hogy tudjon hatékonyan működni, tehát minél hosszabb, annál rosszabb.
Van egy kb. 23 ezer utasításból álló teljesen assembly programom (amiből lett kis módosítással a korábbi teszt is, azért olyan a kezelőfelület, amilyen, mert teljes program, de csak bizonyos részeit tettem elérhetővé GUI-ról), ebből akár tudok pontos adatot is mondani, hogy kézzel írt programban mennyi a memória-operandusú utasítások száma (teljesen általánosan, GUI, általános és specializált algoritmusok, értelmes egésszé összerakva).
''Mert a dekóderek utáni részeknek, és talán a retirementnek szűkebb a keresztmetszete.''
Ez így lehet, de fontosabb, hogy a decode-fázis az egyetlen a magon belül, amit nem befolyásolnak a függőségek.
''Egyébként ha azt veszem amit már írtam, hogy az IPC=1,5 értéket is nehéz elérni akkor ezzel csak megerősítettél abban hogy az IPCmax érték növelés nem hoz túl sokat a teljesítmény növelésében.''
Egy mondat: mint korábban említettem, Intel esetében eddig is (legalábbis semmi nem szólt ellene) 128 bites volt a decode, a schedule (az execute unit-on belül tört 64 bitre a 128 bites micro-op, majd állt össze 128 bitre az eredmény) és a retirement, tehát a natív 128 bit bevezetése egyetlen (bár a legfontosabb) lépcsőt érintett, a pipeline hosszát. AMD esetében mind a négy fő lépcső 64 bites volt, tehát a hatásának végig a teljes CPU-n érezhetőnek kell lennie, sokkal jobban, mint Intel esetében.
#1316: így értendő (L1-hozzáférés +2 cycle latency, az FMISC/FSTORE az egyoperandusú nem-integer műveleteket - konvertálás, ilyesmi - hajtja végre):
ADDPD xmmreg1, xmmreg2 DirectPath Single FADD 4 1/1
ADDPD xmmreg1, mem DirectPath Single FADD 6 1/1
ADDPS xmmreg1, xmmreg2 DirectPath Single FADD 4 1/1
ADDPS xmmreg1, mem DirectPath Single FADD 6 1/1
A memóriahozzáférést természetesen az AGU-k végzik, kiteszik a result bus-ra az eredményt. 3 result bus van összesen, az operation micro-op ott kapja el az eredményt, ahova ment (integer vagy FPU egység)
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Jól értem, te azt mondod, hogy egy macro-op load/store/load-store micro-op-ja nem az LSU-nak szól, hanem csak egy AGU-nak?
Az L1 (és csak az) tekinthető Intel és AMD esetében is a pipe (és az AGU-k vagy a Port2:Load) meghosszabbításának. Ha a kért címet és a teljes adatméretet tartalmazza az L1, akkor load és store esetben nincs baj, +2 cycle kell a teljesítéshez. De ha nincs ott, vagy load-store esetben kell segítőeszköz, előbbi esetben ez a 2 db Load/Store Unit (AMD esetében). Ha az adat nincs L1-ben, akkor a cím a kisebb L2 LSU-ba kerül, és csinál egy próbát a nagyobb késleltetésű L2-n. Ha az L2-ben sincs, akkor a nagyobb memory LSU-ba kerül, ez a rendszermemóriához fordul. Mindkét eset kimenetele az, hogy az adat cím és az azon szereplő 64 byte-os adat az L1-be kerül (64-byte violation esetén 2x64 bit)
Viszont mindhárom esetben (load, store és load-store egyaránt) a cím (és az kiírt adat, ha van ilyen) bekerül az átmeneti tárolóként szolgáló Memory Order Buffer-be (akárhogyan is nem szerepel a képeken; ha AMD esetében valóban nincs, akkor az L2 LSU-nak kell átvennie ezt a szerepet, mert egy ilyen szerepű egységnek kötelező lenni out-of-order felépítés esetén), mivel out-of-order esetben lehetséges spekulatív load, de spekulatív store nem, visszavonhatónak kell lennie a retirement által. A load-store itt ''ül meg'', továbbá itt dönti el a megfelelően fejlett egység, hogy melyik művelet rendezhető át melyikkel (load-load vagy load-store is akár, Core2 és K10 esetén). Illetve a Store-to-Load Forward (az Intel-es Store-Forwarding megfelelője és kiterjesztése AMD-nél) akár megvalósítható lenne csak a result bus-rendszeren is, de ez is egy forrás, mert ez is tartja a tárolt adatot egy ideig.
#1318 akosf: Az L1 késleltetést talán egyszerűen AMD esetében, össze kell hasonlítani sok teljesen függő egyszerű integer reg,reg utasítás RDTSC-jét teljesen függő reg,mem utasítások idejével, de ezen még gondolkodok egy kicsit (lehet, hogy célravezetőbb a Store-Forwarding elkerülésével 32 bites store és eltolt 8 bites load azonos címre, majd elosztani a clock-count-ot kettővel...)
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
VaniliásRönk
nagyúr
Költségcsökkentés:
- hatékonyabban lehet kiválogatni az alacsony fogyasztású chipeket
- nem kell int. VGA-s chipseteket külön gyártani
- a teljesítményt is lehet növelni és hatékonyabban skálázni, ami a notikra nagyon ráfér
Szerintem."Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
-
dezz
nagyúr
Pontosítanék: persze nem fél év múlva, hanem 3-4 hónap múlva. (De gyorsan tellik az idő...) Végülis már tényleg nem ártana némi desktop kiszivárogtatás sem. De pl. hiába gyorsabb valamivel clock-for-clock, ha nem sikerül elég magas órajeleket elérniük. Szóval most az órajel növelésén dolgoznak 1000-rel, és majd meglátjuk, ez mennyire sikerül, legalábbis év végéig.
-
P.H.
senior tag
''#1320: Hát, ebből most nem igazán tudom kibogózni, hogy a válasz igen vagy nem. Vagy néha igen, néha nem?''
Szó szerint, ahogy mondod, néha igen, néha nem. Az Optimization Manual-ok elég szűkszavúan írnak erről, érthetően: az Intel csak az OP reg,reg formájú utasítások időzítéseit teszi közzé, majd hozzáteszi, hogy az OP reg,mem formában az integer esetben +2, FPU-esetben +6 órajellel növekszik; AMD kiírja ugyan részletesen az OP reg,mem és az OP mem,reg formát is, de ő is megjegyzi, hogy az +2 órajelben különbözik a OP reg,reg formáétól. De mindkét esetben ők is egy ideális környezetet feltételeznek, a többivel nem foglalkoznak, mert nem is nagyon lehet. Mi is ez az ideális eset AMD esetében, egy load micro-opnál:
Amikor az ütemező egy címszámítási micro-opot elindít az egyik AGU-ban, akkor egyszerre ezzel elküldi azt a LSU-ba is, egész pontosan az LS1-be. Az AGU 1 (illetve összetett cím esetén 2) órajel alatt kiszámolja a virtuális/effektív címet (utóbbi az effektív cím+szegmens bázis összeg), majd abban az esetben, ha az LS1 üres, akkor közvetlenül a L1 D-Cache-nek továbbítja ezt a virtuálius címet. Azonban az L1 D-Cache tartalmának indexeléséhez szükség van a virtuális mellett a fizikai címre is, ennek meghatározásában segít a kétszintű Translation Lookaside Buffer, az első, gyorsabb hozzáférésű szint az utolsó 40 virtuáliscímhez tartozó fizikai címet tartalmazza. (Itt azt hozzá kell venni, hogy a legszűkebb pipeline+LSU egységen kívül az egész rendszerben, tehát már a TLB-kben és a cache-ekben a memóriahozzáférés adategysége a 64 byte-os határra illesztett 64 összefüggő byte). Ha L1 TLB-ben megtalálja a szükséges fizikai címet, akkor ezzel a két értékkel ''megnyitja'' az L1 D-Cache megfelelő két (2-way set-associative) vonalát és összehasonlításra kerül a két cím az ott lévőkkel; itt derül ki, hogy a keresett adatot tartalmazza-e az L1 D-Cache (hit/miss). Találat esetén ez a megnyitás azt is jelenti, hogy a következő órajelben a kért adatot a cache közvetlenül az pipeline-ba, a megfelelő result-busra juttatja, az LS1-beli bejegyzés pedig törlődik.
A load-ok D-Cache-hez való hozzáféréssel párhuzamosan ellenőrzik az LS1 és LS2 tartalmát, hogy van-e olyan függőben levő megfelelő méretű tárolás(i szándék) a kért címre. Ha van, akkor a cache hit/miss eredménytől függetlenül továbbítják az adatot a result-busra (ha az még nem ismert, csak a cím, akkor egy függőségi bejegyzést jelölnek be, hogy az adat megérkezésekor azonnal továbbíthassák). Ez a Store(-to-Load) Forwading.
A normál store és load-store eset annyiban különbözik, hogy az LS1 bejegyzés nem törlődik, hanem átkerül az LS2-be, és ott várja meg a címhez tartozó tárolandó adatot. A cache-probe ugyanúgy megtörténik, a tényleges írás viszont nem, majd csak a retirement során, programsorrendben. A Non-Temporal Store-ok ezt az egész hierarchiát kikerülik, közvetlenül néhány 64 byte-os buffer-be írják adatukat, az AGU-k közvetlenül ezen buffer-controller-be továbbítják a címet, és az egységek az adatot (illetve a pipeline ezenkívül közvetlenül kommunikál vele, mert meghatározott szabályai vannak annak, hogy bizonyos adott körülmények között le kell zárni ezeket a buffer-eket, és tartalmukat ki kell írni a rendszermemóriába).
Ez az ideális eset, ebben az esetben az AGU-k közvetlenül LSU-hoz (Store Forwarding céljából), a L1 TLB-khez + L1 D-Cache-hez szólnak, közvetlenül továbbítják az adatot a result-busra, tehát így a pipeline meghosszabbításának tekinthető (mint korábban, a K7-es leírásban jelen is vannak, mint stage-ek). A legfontosabb nem ideális esetek:
- az LS1 nem üres: három AGU órajelenként akár három címet számíthat ki, viszont az L1 D-Cache csak két porttal rendelkezik. Ezután az LS1 mindig a ''legöregebb'' két hozzáférést továbbítja az L1 D-Cache felé, a többit átmenetileg tárolja.
- a keresett cím nem található meg a 40 elemű L1 TLB-ben. Ekkor a lassabb, de 512 elemű L2 TLB-hez kell fordulni, ha ott találat van, akkor adatcsere szükséges a két TLB-szint között. Ha a L2 TLB-ben sincs meg, akkor kezdődik a lényegesen hosszabb négyszintű virtuális->fizikai cím fordítás (table-walking, esetlegesen rendszermemória-hozzáférés lehet szükséges már ehhez is).
- ha a Store Forwarding nem jár sikerrel, valamint az L1 D-Cache-ben sincs meg a keresett vonal, akkor memory hierarchy mélyebb szintjeihez kell fordulni, ez L2 probe, adatcsere az L1-L2 között, esetleges rendszermemória-hozzáférés, legrosszabb esetben egy page miss, tehát a lapozófile-hoz kell fordulni.
Utóbbi két esetben, illetve store-ok esetében kerül a bejegyzés át LS1-ból LS2-be.
Ha ez még nem lenne elég, tovább bonyolítja a helyzetet, hogy az összes exclusive cache-nek értesülnie kell minden kell minden cache-hozzáféréshez systemwide, és megfelelően kezelnie kell a helyzetet (összes exclusive cache: ez magonként 3 AMD esetében, legutóbbi Intel-ek esetében natív 2-magonként 1-et vagy hármat? De úgy tudom, az I-Cache-ek sem exclusive-ek, mint ahogy a L1 D-Cache-ek sem), a MOESI protocol szerinti jelöléseket fenn kell tartani, self-modifying code-okat kezelni kell, illetve adott esetben továbbítani kell a kért adatvonalat egy másik cache-be. Mivel egy adott cache csak bizonyos számú hozzáférést tud kezelni egyszerre, ezért emiatt is esetlegesen várnia kell egy request-nek. Non-Temporal Store esetben semmi nem tartja fenn ezt a rendszerszintű koherenciát, ez kizárólag a programozó felelőssége.
A fentiek valamelyikének felmerülésekor (tehát az ideális eset kivételével) a memóriahozzáférések nem tekinthetőek a pipeline részének, programozói szempontból csak annyi látszik, hogy
- load esetben a cím kiszámolásra került az AGU által, eddig kezelhető/optimalizálható a kód, ezután várunk a kért adatra. Az adatok megfelelő elrendezése nagymértékben csökkentheti ezt a bizonytalanságot.
- store esetben a címet az AGU, az adatot valamely egység adta, innen a művelet befejezettnek tekinthető.
Tehát, hogy politikailag korrektek legyünk, minden memóriahozzáférést valamely AGU kezdeményezi (a cím kiszámításával), vele párhuzamosan az LSU felkészül, és nem ideális körülmények között vagy tárolás esetén átveszi.
''ps. előnyösebb lenne nem keverni egy válaszban jelzés nélkül mások szövegeit a címzettével.''
Egy hsz-t néztem, és válaszoltam az ottaniakra, függetlenül, hogy idézet vagy válasz volt.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
slett27
addikt
-
laci666
senior tag
Nem kell az ördögöt a falra festeni az AMD él és élni fog.
Csak hiresztelnek itt mindent össze vissza az AMD ki mászik a slamasztikából az tuti.
Az Intel meg elmehet................ASUS Prime A320I-K,AMD Ryzen3 2200G ,2x8GB 3000MHz DDR4 Corsair ,240 GB Kingston HyperX Savage SSD,LG 27MP59G,SilverStone Raven Z RVZ02,Bequiet Shadow RockLP(Gyári AMD hűtő hely hiány miatt),Huawei Nova 5T, XBOX ONE X,MSI GS63 7RF Stealth
-
Gyuri27
félisten
kellene az 1 hsz-be valami szép, átlátható táblázat. Mert kezdem elveszíteni a fonalat.
laci666: látod látod, valahogy mindig kerül egy kis lé a kamrába. A Morgen pedig nem kis név, ha már ők látnak valamiben fantáziát az rossz nem lehet.
[Szerkesztve]Amd - Radeon - Ryzen
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen