- Franciaországban nyit a Honor 200 Lite
- Világító alma helyett világító tok és szíj az almákra
- Motorola Moto G24 Power - hol van az erő?
- Garmin Forerunner 165 - alapozó edzés
- Na, még egyszer, csak ezúttal OnePlus Open néven
- Telekom mobilszolgáltatások
- A Watch7-tel debütálhat a Samsung vércukormérője
- Fotók, videók mobillal
- iPhone topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
Hirdetés
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
A személyre szabott reklám lehet a streaming következő slágere
it A jobb célzott hirdetések érdekében adatplatformot indít a Warner Bros Discovery.
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Mackósajt
senior tag
válasz
laci666
#1395
üzenetére
Ebből a felületes cikkből nem derül ki, hogy nincs semmi baj, még ha így is lenne.
Eleve: ''processzor és videokártya gyártó cég a pénzt a Morgan Stanley Senior Funding-tól felvett hitel visszafizetésére fordítja, melyet 2006 októberében vett fel, amikor az Intel-lel folyatatott árháborúban kifogyott a pénzből.''
A cikk írója kevesebb mint egy év alatt tökéletesen elfelejteni látszik, hogy az AMD akkor vette meg az ATI-t, és arra vette fel a kölcsönt...
Amúgy fordítok: az AMD új, más jellegű (feltehetőleg hosszabb lejáratú) adósságokba verte magát, hogy kiváltsa a Morgan-tól felvett hitelt, amelyet máskülönben képtelen lett volna visszafizetni.
A new-yorki gyárat meg már tavaly is tervezték, de akkor valamivel korábbra. A cikk szerint még el sem határozták magukat, szal gykorlatilag ''de jó is volna, álmodozzunk róla'' szinten van a dolog. Ami konkrétan azóta történt, az a drezdai gyár fejlesztésének halasztása, mivel nincs rá pénzük. (Ez pedig gyártókapacitás gondokat vetít előre ismét, ha esetleg be is jönnek az új típusok.)
(Különben ebben a cikkben semmi nincs, amit más oldalak ne írtak volna meg már jóval korábban.)
Az meg, amit egyesek mondanak több topicban is, hogy az Intel fölött az azonnali feldarabolás Damoklész kardja függne az AMD összeomlásának esetére, meglehetősen valószerűtlen. -
FireGL
aktív tag
válasz
Mackósajt
#1401
üzenetére
''Ami konkrétan azóta történt, az a drezdai gyár fejlesztésének halasztása, mivel nincs rá pénzük''
Akkor ide is belinkelem mert erről a PH nem ír és így hajlamsoak vagytok hülyeségeket kitalálni. Már nem először linkelem be.
Az Europai Bizottság 262 millio euroval támogatja a Drezdai gyár bővítését: [link]
Próbáljunk meg inkább a K10-ről írni, mert így elég gáz hogy miden második-harmadik oldalon ez a flame megy.
Az embert a gondolkodás tette állattá...
-
#95904256
törölt tag
Meglehetősen nagy. Még tavaly januárban vette meg az AMD a Z-RAM technológiát, mondván hogy az jól fog jönni a 65nm-es CPU-khoz. Ráadásul a Z-RAM csak a SOI-val együtt használható. Az AMD meg épp erre van berendezkedve. A Z-RAM-ról még annyit illik tudni hogy kb. 1/5-e a helyigénye a mostani SRAM-okhoz képest. Ez az info esetleg felhasználható ahhoz hogy a már közismert die-fotók cache méretéből lehessen erre a technológiára következtetni...
szerk.: [link] alapján meghatározható?
[Szerkesztve] -
laci666
senior tag
válasz
Mackósajt
#1401
üzenetére
Csak valamit kifelejtettél hogy New York államtol 1,2 milliárd dolárt kapna amitt nem kellene vissza fizetnie az AMD-nek ha 2011-ben be indul a termelés.Szerintem az az 1,2 milliárd elég össztönzö hatású föleg ha egy petákot se kell vissza fizetni.
''Az meg, amit egyesek mondanak több topicban is, hogy az Intel fölött az azonnali feldarabolás Damoklész kardja függne az AMD összeomlásának esetére, meglehetősen valószerűtlen''
Engem
érdekel hogy mi lesz az Intellel föleg az nem hogy feldarabolnák ha az AMD becsödölne de mivel az AMD él és virul szerintem ez tárgytalan.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
-
laci666
senior tag
Igazad van
Inkább már azt olvasnám hogy a K10 lenyomja a Penry-t ami reméljük igy lesz.
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
-
#1408
#95904256
törölt tag
VaniliásRönk
#1405
#95904256
törölt tag
válasz
VaniliásRönk
#1405
üzenetére
Hm...
Szerintem a fotón látható K8-F 2x1024 kB-os L2 gyorsítótára és a K10-H 2MB-os osztott gyorsítótára közt méretben alig van különbség! Az ötszörös, de még a kétszeres méretbeli különbség is már nagyon látványos lennye. Lehet hogy mégsem jó ez a módszer?
szerk.: 65nm vs. 90nm ?
[Szerkesztve] -
ftc
nagyúr
válasz
#95904256
#1404
üzenetére
jó lenne látni egy 65nm-s X2-t is .Mert gyártása olcsobb mint SRAM. Akkor raknák L1,L2,L3 is
Ezt csak annak a fényében kérdeztem, hogy Hynix is megvette a technológiát memoriagyártáshoz![;]](//cdn.rios.hu/dl/s/v1.gif)
és AMD oldaláról nem nagyon nyilatkoztak, hogy hol lesz használva.
[link]
Egyik hszből:
zram works good at 1.2v with 0.003mA
A következő hír... K10-n már túlmutat mit is akar AMD
[link] -
FireGL
aktív tag
válasz
#95904256
#1404
üzenetére
''Az Z-RAM technológia első licencelője az AMD volt, még 2006 elején, de konkrét elképzelésekről azóta sem hallani a vállalat felől. Legkorábban az évtized vége felé jelenhetnek meg a SRAM-ot legalább részben (például a harmadszintű gyorsítótárnál) felváltó Z-RAM gyorsítótárral tervezett processzorok. A cache sűrűségének növelésére az IBM saját eDRAM (beágyazott DRAM) technológiát fejleszt, mely lehetővé tenné a logikával egy szilíciumlapkára integrálást, és hatalmas, a SRAM-hoz képest háromszor nagyobb tárak integrálását -- a vállalat 24-48 megabájtról beszélt 45 nanométeres csíkszélességű eljáráson.''
[link]
Majd kiderül, hogy ténylegesen van benne Z-RAM vagy sem.
Tripla gyorsítótár, dupla teljesítmény - jön az IBM processzorba ágyazott DRAM-ja [link]
''A vállalat az új eDRAM kereskedelmi alkalmazását a 45 nanométeres csíkszélességű gyártástechnológiára tervezi. Az IBM termékei mellett a közös félvezetőgyártási eljárás következtében az AMD, a Sony és a Toshiba processzoraiban is megjelenhet eDRAM.''
[Szerkesztve]Az embert a gondolkodás tette állattá...
-
-
Raymond
félisten
-
dezz
nagyúr
válasz
Raymond
#1415
üzenetére
Persze, de én az előzőleg linkelt képen látható 90nm-es ''Rev. F Dual Core''-hoz hasonlítottam.
A K8-féle 65nm-es állítólag csak egy gyors, átmeneti megoldás volt, nem kihasználva az összes kicsinyítési lehetőséget, így ahhoz nem annyira érdemes hasonlítani. Ha viszont azt vesszük, hogy ahhoz a bizonyos Rev. F-hez képest 50%-ra kicsinyítés helyett kb. 75%-ra kicsinyítettek, az azt jelenti, hogy a bővítés nélküli állapothoz képest 50%-kal nagyobb lett. -
Raymond
félisten
Was?
A kep ugyanarrol az oldarol van ahonnan a tablazat. Csak egy 90->65 kicsinyites van es az arany ugyanaz a Brisbane es a Barcelona eseteben is. Annyi csak a kulonbseg hogy a Barcelona kicsit nagyobb a Brisbane-hez kepest a plus FP egysegek es a par toldas miatt.
Egy magot nem tudsz 50%-ra kicsinyiteni egyik valtasnal sem, hiaba van az elmeleti szam. Nincs szo felmagoldasrol vagy hasonlokrol. Nezd att a szamokat ujra mindket gyartonal.Privat velemeny - keretik nem megkovezni...
-
dezz
nagyúr
válasz
Raymond
#1417
üzenetére
Te melyik képről beszélsz, mert én erről: [link]
Világosan látszik, hogy a 250nm->130nm váltáskor is, és a 130nm->90nm váltáskor is majdnem pont a felére sikerült nyomni a magot.
Igen, az Intel sorra csak kb. 70%-ra nyomja a magot, de akkor nézzük az AMD-s számokat:
130 nm ---- (Hip7) -------- 55 mm2
90 nm ------ Windsor ---- 31 mm2
65 nm ------ Brisbane --- 20.8 mm2
65 nm ------ Barcelona - 25.5 mm2
31/55=0,5636 -> az eredeti 56%-a.
20,8/31=0,67 -> az eredeti 67%-ára, ebből is látható, amit írtam, de más forrásból is lehetett hallani: a Brisbane egy gyors, ''felületes'' shrink volt - túl sokat nem volt érdemes dolgozniuk vele, a gyártás kisebb részét teszi ki, stb.
25,5/20,8=1,226 -> 22,6%-os bővítés (a. verzió)
Ha viszont azt feltételezzük (a korábbiak alapján), hogy a 130nm->65nm váltásból is ki tudták volna hozni a közel ''felezést'', ha nagyon akarták volna, akkor a Brisbane egy magja 16-17 mm2 is lehetett volna. Ehhez képest a 25,5 mm2 az nagyjából 50%-os bővítés (b. verzió).
Valahol az a. és a b. verzió között van az igazság.
-
Raymond
félisten
''Világosan látszik, hogy a 250nm->130nm váltáskor is, és a 130nm->90nm váltáskor is majdnem pont a felére sikerült nyomni a magot.''
De a dolgok nem ilyen egyszeruek. A fizika es kemia is beleszol a dolgokba. A 90nm egy hatar ami mogott (alatt) mar valtoznak a torvenyek. Ezt mindegyik gyartonal lathattad.
''31/55=0,5636 -> az eredeti 56%-a.''
A 90nm feletti vilagot felejtsd el.
''20,8/31=0,67 -> az eredeti 67%-ára, ebből is látható, amit írtam, de más forrásból is lehetett hallani: a Brisbane egy gyors, ''felületes'' shrink volt - túl sokat nem volt érdemes dolgozniuk vele, a gyártás kisebb részét teszi ki, stb.''
A feluletesseghez annyit hogy a Barcelona mag ugyanakkor mint a Brisbane plusz a bovitett FPU resz. A tobbi valtoztatas nem igenyelt sok heleyt, csak kicsivel tolodott par komponens de azt sem nagyon. Hasonlitsd ossze a Brisbane magot a maik keprol az egyik Barcelona maggal. A ''gyartas kisebb reszerol'' pedig annyit hogy per pillanat ezekbol a procikbol el az AMD. A ket(harom) csucs procin kivul (amit csak tenyleg kis mennyisegben gyartanak) mind 65nm K8 es a desktop piacon az lesz jovo tavaszig.
''Ha viszont azt feltételezzük (a korábbiak alapján), hogy .......... nagyjából 50%-os bővítés (b. verzió).''
Ezt igy nem vehetd. Nem ugralhatsz at node-okat csak ugy. Egy 130->65 osszehasonlitas ertelmetlen.Privat velemeny - keretik nem megkovezni...
-
dezz
nagyúr
válasz
Raymond
#1419
üzenetére
Nekem nem úgy tűnik, mintha nagyon változnának:
(A Chip Architectes oldalon látható táblázat: )
:::::::::::::::::::::::: 130 nm to 90 nm | 90 nm to 65 nm | 65 nm to 45 nm |
:::::::::::::::::::::::::::: transition :::::: | ::: transition :::: | :::: transition :::: |
------------------------------------------------------------------------------------------------------
Ideal Area Scaling :: | ::::: 0.48 :::: | :::::: 0.52 :::::::: | ::::::: 0.48 :::::::: |
Logic Area Scaling : | ::::: 0.72 :::: | :::::: 0.70 :::::::: | ::::::: 0.70 :::::::: | (Intel)
SRAM Area Scaling | ::::: 0.67 :::: | :::::: 0.64 :::::::: | ::::::: 0.48 :::::::: | (Intel)
Mint láthatod, az ideális (elméletileg elérhető, amibe nyilván beleszámolták azokat a bizonyos fizikai és kémiai kötöttségeket) 65->45-nél is 0,48... Az SRAM-nél sikerül is (AMD-nél még jobban, ott mindig megvan a ~0,50). Namost az egy dolog, hogy az Intel a magot nem is törekszik 0,70 alá nyomni, az AMD-nél más a helyzet, ők korábban is megközelítették a magnál is a 0,50-et, tehát lehetséges a mag SRAM-ot közelítő összenyomása. Mi alapján állítod akkor, hogy ez 65->45-nél lehetetlen?
Még1x: nem én állítom, hanem sok helyen lehetett olvasni, hogy a Brisbane egy gyors, felületesebb shrink volt, mint a korábbiak, mert így is le voltak maradva a 65nm-re való átállással, és mivel órajelben sem túl jók, olcsó procik lesznek belőlük. Nézd végig a termékvonalat, a nagy része ma is 90nm-es. Az első, igazán jól megcsinált 65nm-es proci a K10 lesz, a Brisbane csak egy kis bemelegítés volt hozzá.
De nézzük csak meg jobban a képeket! Mérjük csak a Brisbane magját a Barcelonáéhoz! Szélesebb. De ez még nem minden: a L1-ek is szélesebbek - miközben magasságban megegyeznek... Pedig szélességben kellene egyezniük, nem magasságban, mivel láthatóan függőlegesen széthúzottabbak a Barcelona L1-ei! Jól van ez így? Mármint, jól méretezték be a Brisbane képét (elvileg méretarányos az összes kép)? Úgy tűnik, a magasságot vették alapnak, nem a szélességet! Megfelelő méretre kicsinyítve a Brisbane magot (90%-ra) egy érdekes történik: a két mag is egyforma szélességűvé válik így! Szal szerintem ez a megfelelő méret!!! Így összehasonlítva a 90nm-es Windsor maggal már 0,60 az arány, nem 0,67! Ez már nem is olyan rossz, megközelíti a korábbi váltás 0,56-ját!
És nézzük csak, mennyivel hosszabb így a Barcelona egy magja (a 2. FPU nélkül!), mint a Brisbane-é: 13,5%-kal! Azaz nem éppen csak a 2. FPU egységgel nőtt a mag.
[Szerkesztve] -
#95904256
törölt tag
Remek összefoglaló!
Különösen ez a sor tetszett benne:
Thirdly, K10 processors can now use unaligned loading even for Load-Execute instructions that combine loading with the data operations.
szerk.: Ugyanis 32 bites módban a 8 SSE regiszter nekem eddig mindig szűk keresztmetszetnek tűnt. Ez legalább segít a dologon, mégha speciálisan K10-re is kell fordítani a kódot.
[Szerkesztve] -
#95904256
törölt tag
Interjú Hector Ruizzal: [link]
Újdonság nincs benne, de pár apró részletre fény derül hogy miért is késik a Barcelona. A ''natív négy mag'' összehozása nagyobb falatnak bizonyult mint gondolták, ráadásul minden egyes technikai probléma orvoslása kb. hat-hat hetet igényel. Ezért csúsznak már lassan hat hónappal az eredetileg tervezett megjelenési időponthoz képest. -
#95904256
törölt tag
válasz
Gyuri27
#1424
üzenetére
Persze, de érdekfeszítő dolgok nincsenek benne.
Az interjú első fele tulajdonképp arról szól hogy Ruiz úr az Intelt vádolja azzal hogy főképp az OEM partnerekkel olyan viszonyt alakított ki ami a piaci szabályokat felrúgja, így ez ellen lépéseket fognak tenni. Tkp. lesz egy újabb per az Intellel.
Az interjú közepén esik pár szó a Barcelonáról, melyben azt Ruiz úr azt az egekig magasztalja. Itt esik szó arról is hogy még mindig technológiai problémákkal küzdenek. Egy kicsit elszámolták magukat ezen a téren.
Majd az interjú végén Ruiz úr egészségi állapota felől érdeklődnek, valamint hogy nem gondolkodik-e már a visszavonuláson. De természetesen esze ágában sincs neki. -
dezz
nagyúr
válasz
#95904256
#1425
üzenetére
Miféle újabb per? Hiszen az már legalább egy éve megy...
(Ennek egyik monentuma volt nemrég, hogy az Intel ''véletlenül'' a backupokból is törölt bizonyos ide vonatkozó, bizonyítékként bekérni akart emaileket.) Itt Európában maga az EU indított pert az Intel ellen. A japán esetről is említést tesz, aholis a japán kornány fogta perbe az Intelt, mely per az Intel elmarasztalásával végződött, és alá kellett írniuk egy megállapodást, miszerint távol tartják magukat a versenyellenes magatartástól - azonban Ruiz szerint nem hagytak fel velük teljesen ott sem.
Egyébként azt állítja, már megoldották a problémákat. Ennek eredménye állítólag a B2-es revizió, ami már elkészült, azonban csak most kezdik gyártani, és hónapok múlva lesz belőle termék. Addig is marad a B0 revizió, ami működik, de csak alacsonyabb órajelen a kívánatosnál. (A B1 állítólag már magasabb órajelet bírt, de nem működött tökéletesen, így ''kuka''.)
Gyuri27: Hát... Ott van 11 oldal, minden oldalon egy v. több újdonság, melyek mindegyike igényelne 1-2-3 sort, még rövid leíráshoz is. -
P.H.
senior tag
Mivel a cikk terjedelme kezelhető, viszont alapos áttekintést az a K10 felépítését illetően, megpróbálkoztam a lefordításával (remélem, nem sértek szerői jogokat és érdekeket; ezért maradtak ki pl. a képek belőle). A fordítás nem szó szerinti, de igyekeztem a lehető legjobban tükrözni az eredeti tartalmat, pár saját megjegyzéssel kiegészítve.
Ha mégis aggályos lenne, az illetékesek majd megteszik a megfelelő lépéseket.
Az első Barcelona processzorok egy hónapon belül elérhetővé válnak. Ezek lesznek az első termékek, melyek az AMD új K10 microarchitektúrájára épülnek, melytől oly sokat vár a cég. Nézzük meg közelebbről azokat a felépítésbeli újdonságokat, melyek e CPU-kban fognak bemutatkozni.
Bevezető
Az AMD az új, K10 mikroarchitektúrára épülő négymagos processzorait ígéretei szerint augusztus végén vagy szeptember elején dobja piacra. Az első K10-alapú CPU-k a szerverekbe szánt, Barcelona néven ismert Opteron-ok lesznek. Sajnos az AMD mérnökei a jelenlegi revízióval nem érték el a tömegtermeléshez szükséges mennyiséget a magas órajelű változatokból. Úgy tűnik, hogy ennek útjában az áll, hogy a nagy frekvencián működő 4 mag többet fogyaszt, mint amennyit a platform TDP megenged. Bár minden új stepping-gel és a gyártási technológia finomításaival a fogyasztás csökkent és magasabb órajelek elérhetőek, a cég anyagi helyzete szükségessé teszi, hogy bevezesse a piacra a jelenlegi revíziót, így induláskor az első négymagos modell 2 GHz-en fog működni.
A negyedik negyedévre ígéri az AMD az Opteron chip-ek órajelének 2,4-2,5 GHz-re emelését, valamint az első asztali K10-alapú CPU-kat:
- Phenom FX (Agena FX) - 4 mag; 2 MB L3; AM2+ vagy Socket F+ foglalat; 2,2-2,4 GHz-ről indulva
- Phenom X4 (Agena) - 4 mag; 2 MB L3; AM2+ foglalat; 2,2-2,4 GHz-ről indulva
2008 elejére jövendöli a cég a ''kisebb'' modelleket:
- Phenom X2 (Kuma) - 2 mag; 2 MB L3; AM2+ foglalat; 2,2-2,6 GHz-ről indulva
- Athlon X2 (Rana) - 2 mag; L3 nélkül; AM2+ foglalat; 2,2-2,6 GHz-ről indulva
- Sempron (Spica) - 1 mag; AM2+ foglalat; 2,2-2,4 GHz-ről indulva
De mindez még jövő. Most nézzük meg közelebbről a fejlesztéseket. Megpróbálom felsorolni az összes újdonságot és kifejteni, miben jelentenek ezek teljesítménytöbbletet.
Utasításbetöltés
A processzor a kód feldolgozását annak L1 I-cache-ből betöltésével és dekódolásával/fordításával kezdi. Az x86 utasítások hossza változó, ez megnehezíti az egyes utasítások kezdetének meghatározását a dekódolás előtt. Annak érdekében, hogy az egyes utasítások határainak meghatározása ne befolyásolja a dekódolás sebességét, az K8/K10 esetén ez még akkor megtörténik, amikor a kód az L1 I-cache-be kerül. Ezt az információt a L1 I-cache speciális mezőiben, az utasításbyte-okkal páruzamosan tárolja (3 bit minden byte mellett). Mivel ez az elődekódolásnak nevezett folyamat még a pipeline előtt, azon kívül történik meg, így a dekódolás sebessége egyenletes és független az utasítások formátumától és hosszától.
A cache-ból a processzor utasításblokkokat tölt be és kiválasztja belőlük a dekódolandó utasításokat. A K10-ek (aligned) 32 byte-os blokkot olvas(hat)nak be az L1 I-cache-ből órajelenként, míg a K8 és a Core 2 processzorok 16 byte-os blokkokkal dolgoznak. A 16 byte-os órajelenkénti blokkméret a K8-nak és Core2-nek arra elég, hogy 5 byte-os átlagos utasításméret esetén órajelenként 3 utasítást küldhessenek dekódolásra. Az x86 utasítások maximális hossza viszont 16 byte lehet, illetve számos algoritmusban néhány szomszédos utasítás hossza meghaladja az 5 byte-ot. Ezen esetekben órajelenként már 3 utasítást is lehetetlen dekódolásra küldeni.
Nevezetesen, az SSE2 OP reg,reg (egyszerű utasítások, melyeknek minden forrásadata és célja is register, pl. a MOVAPD XMM0,XMM1) utasítások 4 byte hosszúak. Azonban ha az utasítás egy forrásadatához vagy a céljához memóriacímen keresztül lehet hozzáférni (előbbire példa: MOVAPD XMM0,[EAX+16]), akkor az offset méretétől függően 6-9 byte hosszúak lehetnek. 64 bites módban ha valamely paraméter a +8 (XMM8-XMM15) register egyike, egy további REX prefix byte-tal is számolnunk kell, azaz 7-10 byte-os utasításhosszal. Az SSE1 utasítások egy byte-tal rövidebbek, de csak a vektorjellegű formájuk (amely 4x32 bit adaton dolgozik), skalár formájuk esetében - ez 1x32 bites adatméretet használ - ugyancsak 7-10 byte-os mérettel kell számolnunk.
A 16 byte-os blokkméret K8 esetében azért nem szűk keresztmetszet, mert a vektorjellegű utasítások dekódolása 3 utasítás/2 órajel sebességre korlátozott (mivel ezek a 128 bites utasítások már itt 2x64 bites feldolgozási egységként jelennek meg, tehát 3 db 128 bites utasítás összesen 6 db 64 bites egységre fordul; mivel azonban a felépítés 3-széles, ezért órajelenként 3 db 64 bites egység, azaz ''1,5 db'' 128 bites x86-utasítás fordítódik). Ellenben a K10 natívan 128 bites feldolgozási egységekre fordítja az utasításokat, tehát a 16 byte-os blokkok ténylegesen szűkös lenne.
Itt álljunk meg egy pillanatra: a Core 2 processzorok ugyanúgy 16 byte-os utasításblokkokat dolgoznak fel, mint a K8 CPU-k, ez csak akkor teszi lehetővé órajelenkénti 4 utasítás dekódolását, ha az átlagos utasításméret a 4 byte-ot nem lépi túl, ellenkező esetben akár 3 utasítást sem tud továbbküldeni. Van azonban egy belső 4x16=64 byte-os pufferük ebben a lépcsőben, amely az utolsó 4 beolvasott 16 byte-os blokkot tartalmazza. Ebből a pufferből 32 byte/órajel sebességgel olvassa ki az adatokat, tehát azok a rövid ciklusok, melyek beleférnek ebbe a 64 byte-os puffer-be, L1 I-cache hozzáférés nélkül futnaknak, továbbá 1 órajelet megspórolhatnak a ciklus újrakezdésénél. Viszont ezeknek a max. 64 byte-os ciklusoknak is csak akkor hatékony a végrehajtása, ha legfejlebb 18 utasításból állnak, ebből legfejlebb 4 feltételes ugrást tartalmaznak (Egy biztosan van bennük, mert ciklusok, tehát további 3 IF-jellegű elágazást vagy 3-ágú CASE-t tartalmazhatnak), és nincs bennük eljárászárás (RET = return).
Az elágazáskezelésre vonatkozó fejezet egyelőre kimarad, hamarosan pótlom.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
Dekódolás/utasításfordítás
A 32 byte-os blokkokat, melyek az utasításcache-ből érkeznek, a Predecode/Pick Buffer-be másolja, kisorjázza az utasításokat (egy több byte-os utasítás kezdődhet az egyik blokk végén és végződhet a következő blokk elején), azok jellege ilyenkor már ismert, tehát mehetnek a megfelelő dekóder-lépcsőkre: az egyszerű utasítások, melyek egy (Single) vagy két (Double) elemi egységre fordulnak, a DirectPath-nak nevezett egyszerű dekóderbe kerülnek, a komplex, 3 vagy több elemi egységre forduló utasítások a VectorPath-ra (a mikrokód dekóderbe) kerülnek. Ezeket az egységeket a továbbiakban macro-opoknak nevezzük (a cikk MOP-nak nevezi őket, én a továbbiakban maradok az AMD szerinti elnevezésnél).
Órajelenként legfejlebb 3 macro-op hagyhatja el a dekóder-fokozatot. A DirectPath-dekóder órajelenként vagy 3 db 1 macro-opra forduló, vagy 1 db 1 macro-opra és 1 db 2 macro-opra forduló, vagy pedig ''1,5 db'' 2 macro-opra forduló utasítást dekódol. A komplex utasítások akár több, mint 3 macro-opot is eredményezhetnek, ezért több órajelre lehet szükség a feldolgozásukhoz. Annak elkerülése végett, hogy két út kimeneti macro-opjai konfliktusba kerüljenek a dekóder-lépcsők elhagyásakor (órajelenként legfejlebb 3 macro-op kerülhet ki, akárhonnan is jöjjön), ezért a K8 és a K10 képes képes egyszerre, párhuzamosan küldeni egyszerű és a komplex utasításokat a két útra.
Minden macro-op két micro-opból állhat: egy integer vagy lebegőpontos aritmetikai micro-opból és egy memóriahozzáférési micro-opból (ezek egyikéből vagy mindkettőből). Ez a két micro-op egészen az ütemezőig egy egységet képez, az ütemezőkben válnak el és futnak függetlenül egymástól.
A dekódereket elhagyó órajelenkénti 3 macro-op egy hármas csoportot alkot. Számos esetben a dekóderek csak 2, sőt esetenként csak 1 macro-opot generálnak az adott órajelben, pl. váltakozó DirectPath és VectorPath utasítások esetén. Az ilyen, nem teljes hármasokat üres macro-opok egészítik ki hármasokká, így kerülnek tovább.
Vektorjellegű (128 bites) SSEx utasítások a K8 processzorok esetében 2 db 64 bites macro-opra fordulnak le, egy-egy külön a felső és az alsó 64 bites félnek, emiatt ezek esetében az ideálishoz képest felére csökkentve a dekódolási sávszélességet, és kétszer annyi helyet foglalva a belső pufferekben (pl. az ütemezőkben). A K10 natív 128 bites FPU-egységeinek köszönhetően nincs szükség erre a darabolásra többé. K8 esetében a legtöbb SSEx-utasítás DirectPath Double úton fordult, 2 macro-opra, K10 esetében ezek DirectPath Single 1 macro-op utasítások. Továbbá néhány SSEx-utasítás, amely K8 esetében VectorPath úton (3 vagy több macro-op) fordult, K10 esetében DirectPath (Single vagy Double) lett, 1 vagy 2 macro-opot adva. (Ezt azért emeli ki a szerző, mert a korábbi, 64 bites feldolgozást használó Intel processzoroknál is a fordítás 128 bites egységekre történt, így kerültek be az végrehajtó egységekbe, ott 2 db 64 bites darabban kerültek feldolgozásra, majd az egység elhagyása előtt összeállt az eredmény 128 bitre. Tehát a natív 128 bitre váltás önmagában nem befolyásolta számottevően pl. a dekódolást.)
A vermet használó utasítások dekódolása szintén egyszerűsödött. A legtöbb veremművelet CALL-RET (eljáráshívás és visszatérés) illetve PUSH-POP utasítás, ezek egyetlen macro-opra fordulnak K10 esetében, továbbá a Sideband Stack Optimizer segítségével ezen az utasítások láncolata egymástól független, párhuzamosan végrehajtható egységekre fordul.
Sideband Stack Optimizer
Ez az egység a Core és Core 2 CPU-k Stack Pointer Tracker egységével megegyezően működnek. Miért van szükség ezekre? Az x86 a CALL, RET, PUSH és POP utasításokat használják eljárások hívásra, eljárásokból visszatérésre, paraméterek átadására és a register-értékek átmeneti mentésére. Ezek az utasítások a verem tetejére mutató ESP register-t módosítják, sorozatuk tehát csak egymás után hajtható végre, mert a bemeneti registerértékük (az ESP) értéke függ a programsorrendben előző utasítás eredményétől (amit az ugyancsak az ESP register-be ír).
A két táblázatban bemutatja, hogy egy általános eljáráshívás PUSH-PUSH-...-PUSH-CALL-PUSH-PUSH sorozat, egy eljárás befejezése pedig POP-POP-...-POP-RET szekvencia, és ez milyen elemi műveletekre fordul le K8 és K10 esetében.
Mint látható, egy eljáráshívás a paraméterek átadásával, a vezérlésátadással és bizonyos register-értékek átmeneti elmentésével jár, melyek mindegyike módosítja az ESP registerek értékét. Ez az utasításláncolat nem párhuzamosítható, és a vermet érintő későbbi utasítások is csak a lánc teljes lefutása után férhetnek hozzá a veremhez.
Mindkét gyártó megoldása azonos elven alapul: az ESP register a processzor mélyén a lehető legkevesebb esetben módosul, pontos értékét nem is ismeri a Sideband Stack Optimizer, csak egy számlálót tartalmaz. A lefordítandó utasításokról tudja, hogy azok mennyivel módosítjanák az ESP értékét, az utasításokat egy ESP+xxx memóriahozzáférésre fordítja, ahol xxx a számláló aktuális értéke, majd a számlálót növeli/csökkenti az utasításnak megfelelően. Ezenkívül ismer még egy speciális szinkronizáló macro-opot, ez egyszerű ADD ESP,counter alak, és ha bizonyos utasításokkal találkozik fordítás közben (pl. amelyek már alapvetően ESP+xxx alakúak), leküld még a lefordított utasítás előtt a futtató egységekhez egy ilyen szinkronizálást, majd nullázza a számlálóját. Az ESP+xxx alakra fordított memóriahozzáférő utasítások pedig egymástól függetlenül végrehajthatók, illetve az eljárástörzs betöltheti a paramétereket akár már a verem teljes lekezelése előtt (out-of-order).
Ennek, a megnövekedett méretű return-address puffernek, valamint az indirekt ugrások hatékonyabb kezelése jótékonyan befolyásolja sok kis, specializást eljárásokat alkalmazó programok futását (tipikus C/C++ megközelítés).
A K10 dekóderei ugyan nem képesek órajelenként 4 utasítás fordítására, mint a Core 2-éi megfelelő körülmények között, de ez nem jelent szűk keresztmetszetet: az átlagos feldolgozás majdnem mindig eléri a 3 művelet/órajel ütemet, így a K10 dekóderei kielégítően és egyenletesen ellátják a végrehajtási egységeket, mind az üresjáratokat, mind az utasítástorlódásokat elkerülve.
Instruction Control Unit (ICU)
A lefordított macro-op hármasok az Instruction Control Unit-ba kerülnek, mely továbbítja őket az átrendezési pufferbe (Re-Order Buffer, ROB). Ez utóbbi 24 db ilyen hármas tárolására képes, így legfeljebb 24x3=72 macro-opot képes kezelni egyszerre.
Innen a macro-opok az integer vagy az FPU-egység ütemezőibe is bekerülnek, pontosan abban a sorrendben, ahogy a dekódolási fázisból érkeztek (~programsorrendben), de a ROB egészen addig tárolja őket, amíg be nem fejezték életútjukat a CPU-n belül (lefutnak, eredményük ismert lesz, továbbá programsorrendben véglegesítődnek, tehát nem kerülnek érvénytelenítésre pl. egy téves elágazásbecslés miatt). A véglegesítés (retirement, visszavonulás) során továbbítják eredményüket a memóriába, vagy befolyásolják a CPU-környezetet (jobban nem tudom megfogalmazni, tehát az architectural state-et módosítják, a programsorrentben utánuk következő utasítások az ő eredményeiket fogják látni). A ROB feladata tehát, hogy a téves elágazásbecslés, megszakítás, kivétel, stb. miatt feleslegessé vált macro-opokat és eredményeiket eldobja.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
Az integer egység
K8 és K10 esetében egyaránt az integer egység 3 szimmetrikus pipe-ból áll. (Jelen esetben a szimmetrikus azt jelenti, hogy 3 kivételtől eltekintve mindhárom alkalmas bármely integer utasítástípus végrehajtására, tehát általánosak). Mindhárom saját, független, 8 macro-op (tehát legfeljebb 16 micro-op) fogadására alkalmas ütemezővel, ALU-val (Arithmetic and Logic Unit), AGU-val (Address Generation Unit) és elágazásfeldolgozóval rendelkezik. Az említett kivételek: a szorzóutasítások csak a 0. pipe-ban, a K10 új LZCNT és POPCNT utasításai csak a 2. pipe-ban hajtódhatnak végre.
Abból, hogy a macro-opok hármasokba rendeződve kerülnek ki a dekóderekból, és a 3 szimmetrikus integer-pipe létéből azonnal látszik, hogy egy-egy integer macro-op abba a pipe-ba fog kerülni és lefutni, amely pozíción van a saját hármasában (amely viszont javarészt a programsorrendből adódik). Ez egyrészt az utasítások kezelését leegyszerűsíti, másrészt az utasítások bizonyos balszerencsés elrendezése mellett, hosszabb függőségi láncok esetén okozhat kiegyensúlyozatlanságot (szerencsére ez nagyon ritkán fordul elő a valóságban, így nem befolyásolja a teljesítményt). A szorzási és a 2 új utasítás macro-opjait a dekóder-ek helyezik a hármas megfelelő pozíciójára, így azok a megfelelő helyre kerülnek.
Mint említettük, a macro-opok egy aritmetikai és egy memóriahozzáférési micro-opból állhatnak, ezek az ütemezőkbe kerülve válnak el egymástól. A megfelelő forrásadatok rendelkezésre állásakor mindenhárom pipe egy-egy ilyen aritmetikai és memóriahozzáférési micro-opot futtathat le. Mivel órajelenként legfejlebb kettő memóriahozzáférés (64 bites olvasás/írás, bármilyen kombinációban) lehetséges, ez összességében 5 micro-op órajelenként. A micro-opok az ütemezőkben levő macro-opokból out-of-order módon kerülnek futtatásra, amennyiben rendelkeznek az összes forrásadatukkal. Amennyiben egy macro-op aritmetikai ÉS memóriahozzáférési micro-opja egyaránt lefutott (ha van neki mindkettő), a macro-op elhagyja az ütemezőjét, helyet adva újabb macro-opoknak.
A K8 a memóriahozzáféréseket programsorrendben kezeli, azaz az eredeti sorrendben későbbi hozzáférések nem előzhetik meg a sorrendben korábbiakat. Azaz ha egy korábbi hozzáférés valamilyen oknál fogva nem végrehajtható, a későbbiek várakozni kényszerülnek, még ha minden forrásadatuk rendelkezésre áll is. Ez a K8 legsúlyosabb szűk keresztmetszeteinek egyike. Tehát bár a K8 órajelenként két memóriahozzáférést hajthat végre, számos kód esetén mégis kevésbé hatékony, mint a Core 2, mely órajelenként ugyan csak egyetlen hozzáférésre képes, viszont képes spekulatívan átrendezni azok sorrendjét, és bizonyos írásokat/olvasásokat átugrani.
A K10-re épülő CPU-kat már nem érinti ez a szűk keresztmetszet: nem csupán az olvasásokat képes átrendezni egymás között, hanem bizonyos későbbi olvasási műveleteket is képes a korábbi írások elé ütemezni, ha biztosan nem azonos címet érintenek. Utóbbi átrendezéssel nagymértékben képes számos kódot felgyorsítani, pl. azokat a ciklusokat, melyek olvasási műveletekkel kezdődnek és írással fejeződnek be. Azok a CPU-k, melyek nem képesek erre, nem kezdhetik meg a következő ciklus végrehajtását, amíg az aktuális záró írásai be nem fejeződtek. Az olvasási átrendezéssel viszont ezen várakozás nélkül megkezdhetik a következő iteráció végrehajtását.
A K10 ugyan nem képes a későbbi olvasási műveletek végrehajtására addig, amíg korábbi írási művelet címe nem ismert (a Core 2 képes erre, ez a spekulatív loading, amely érvénytelenítésre kerülhet téves jóslat esetén), ez nem befolyásolja számottevően a teljesítményét, mivel ezen esetek rendkívül ritkák (kb. az esetek 5%-a), ezért a spekulatív olvasások képessége nem létfontosságú.
Az integer osztási algoritmusok is átdolgozásra kerültek K10 esetében: az osztás sebessége az osztó és az osztandó legnagyobb helyiértékű bitjétől függ. Pl. ha az osztandó 0, az osztáshoz kb. feleannyi idő szükséges. Valójában az integer osztás igen ritka művelet; mivel igen lassú, ezért a programozók általában gondosan elkerülik, reciprokkal szorzással és shift műveletekkel helyettesítve, tehát ez az átdolgozásnak nincs számottevő hatása az általános teljesítményre.
Mindent egybevetve a K10 integer egysége igen hatékony. Miután kiegészült a memóriaműveletek átrendezésének képességével, nem tartalmaz egyetlen szűk keresztmetszetet sem. Bár a K10 pufferei nem olyan mélyek, mint a Core 2-éi, esetében pl. nincs registerfile-olvasási korlát, valamint mentes néhány egyéb, Core 2 esetén jelen levő ütemezésbeli korlátozástól, melyek megakadályozzák, hogy az Intel processzora egyenletesen maximális teljesítményét nyújthassa.
FPU
A lebegőpontos egységet K8 és K10 esetében elválasztották az integer egységtől, és teljesen más tervezési elvet követ. Az ütemezői puffere 12 macro-op hármast (legfejlebb 36 macro-opot) képes tárolni. Az integer egységgel ellentétben 3 különböző funkciójú pipe található benne: FADD a lebegőpontos összeadásokhoz, FMUL a lebegőpontos szorzásokhoz és az FMISC (vagy FSTORE) a memóriába íráshoz és egyéb műveletekhez. Továbbá a puffer nem a hármasbeli pozíciójuk alapján rendeli a különböző pipe-okhoz a macro-opokat.
A K8 és K10 egyaránt órajelenként mindhárom pipe-ban képes egy-egy micro-opot elindítani. A K8 80 bites végrehajtó egységekkel rendelkezik, a 128 bites SSEx-utasítások a dekódolás során két 64 bites műveletre fordultak, a felső és az alsó fél különböző órajelekben hajtódott végre. Ez nemcsak a vektorjellegű utasítások futását lassította, hanem az FPU ütemező pufferméretét is a felére csökkentette, így korlátozva az FPU-egység out-of-order előrelátási mélységét.
K10 esetében a végrehajtó egységek 128 bitesek, így esetében egy 128 bites utasítás egy egység, tehát az elméleti végrehajtási sebessége megduplázódik a K8-hoz képest. Továbbá, mivel ez feleannyi macro-opot is jelent, az ütemező pufferének hossza is effektíve kétszeresére nő, hatékonyabb soronkívüli végrehajtást eredményezve.
A K8 az SSEx betöltési műveleteket az FSTORE-ban hajtotta végre (lefoglalva azt), tehát órajelenként egy betöltő utasítás futhatott le. Mivel a K8 órajelenként két olvasási memóriahozzáférést képes végrehajtani, a betöltés mellett még egy OP reg,mem formájú műveletet tudott végrehajtani azzal párhuzamosan. A K10 más mechanizmussal kezeli el a SSEx betöltő memóriahozzáféréseket:
- Először is egyáltalán nem használ FPU-erőforrásokat, így felszabadítva a FSTORE pipe-ot, illetve órajelenként két betöltésre képes.
- Másodszor, ha a forrásadat 16-byte aligned (16 byte-tal osztható címen van), az unaligned (MOVU**) és az aligned (MOVA**) utasításforma teljesítménye megegyezik.
- Harmadszor, az OP reg,mem formájú adatok forrása is lehet unaligned. Ha a fordítóprogram számára fordítási időben nem tiszta, hogy a forrásadat aligned lesz-e, akkor egy MOVU** reg,mem + OP reg,reg formára fordítja a programrészt, K10 esetében viszont ez nem szükséges, tehát csökken a programbeli utasítások száma. Jelenleg az Intel CPU-i az OP reg,mem utasításokra unaligned forrásadat esetén Általános Védelmi Hiba kivételt dobnak, tehát az újrafordított programok esetén érdemes ezt a K10-képességet kihasználó programrészeket csak az új AMD processzorokon futtatni.
- Negyedrészt, az L1 D-cache olvasására szolgáló buszokat 128 bitre szélesítették ki, ennek eredményként a K10 órajelenként 2 db 128 bites olvasásra képes. Ez nagyon fontos bővítés, hisz egyszerre végrehajtható 2 művelet összesen 4 forrásadatot feltételez, melyek közül kettő lehet memóriabeli adat. Ellenben, az írásra szolgáló két busz 64 bit széles maradt, így a 128 bites tárolások 2 db 64 bites csomagra oszlanak. Ennek következtében a CPU órajelenként 1 db 128 bites írásra, 2 db 128 bites olvasásra, vagy 1 db 128 bites olvasásra és 1 db 64 bites írásra képest. Azonban elmondható, hogy nagy általánosságban a kódokban kétszer annyi olvasási művelet van, mint írási, tehát ez nem befolyásolja számottevően a 128 bites feldolgozási sebességet.
- Ötödször a 128 bites register->register adatmásolást már mindhárom pipe végrehajthatja, az FSTORE is, nemcsak az FADD és FMUL, így utóbbi két egységet részben felszabadítja más, specifikus műveletek számára.
Láthatjuk, a K10 FPU-ja sokkal rugalmasabb lett. Néhány olyan képességgel gazdagodott, melyekkel az Intel processzorok nem rendelkeznek jelenleg, nevezetesen az unaligned betöltések, OP reg,mem esetben is, illetve az órajelenkénti 2 db 128 bites betöltés. A Core 2-vel ellentétben az integer és FPU egységeknek külön ütemezőik és puffereik vannak, illetve külön futtatási port-okba kerülnek az integer és a lebegőpontos műveletek. Továbbá, a K10 az FSTORE pipe-ot általánosabbá tette, mely tovább befolyásolhatja előnyösen a feldolgozási sebességet.
Az fentieket egyben tekintve, a K10 FPU-ja sokkal nagyobb teljesítményt ígér, mint a Core 2 lebegőpontos egységei.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 memória-alrendszer
- Load/Store Unit
Miután valamely AGU kiszámította a szükséges memóriacímet, K8 esetében a olvasási ás írási kérelmek az LSU (Load/Store Unit) egységbe kerülnek, ez két puffert tartalmaz, az LS1 és LS2 sorokat. Először mindkét típusú kérés a 12 elemű LS1-be kerül, amely órajelenként kettőt továbbít ezek közül az L1 D-cache felé, szigorúan programsorrendben. Cache-tévesztés esetén a műveletek átkerülnek a 32 elemű LS2 sorba, innen férhetnek hozzá az L2 cache-hez, illetve szükség esetén a rendszermemóriához.
K10 esetén ez némileg módosult: az LS1 a továbbiakban kizárólag az olvasási kérelmeket fogadja, az írási műveletek azonnal az LS2-be kerülnek. Az LS1-beli betöltések out-of-order módon futnak le, közben figyelemmel kísérve az LS2-beli tárolási címeket. Ahogy korábban leírtuk, a K10 a 128 bites írásokat 2 db 64 bites egységben kezeli, tehát azok két elemet foglalnak az LS2 egységben.
- L1 cache-ek
A K8 és K10 egyaránt két elsőszintű gyorsítótárat tartalmaz: 64 KB-ot az adatoknak és külön 64 KB-ot az utasításoknak. Mindkettő 2-utas csoportasszociatív (2-way set-associative). A kis asszociativitás számos alkalommal okoz konfliktusokat az azonos csoporthoz tartozó vonalakon, ez gyakori cache-tévesztéshez vezet, hátrányosan befolyásolva a teljesítményt (a kis asszociativitást általában nagyobb L1 cache-mérettel kompenzálják, ahogyan az AMD is teszi). A L1 D-cache legfőbb előnye a két port: órajelenként 2 db olvasási és/vagy írási műveletet képes teljesíteni.
Sajnos a K10 esetében is azonos L1-méret és -asszociativitás maradt. Az egyetlen szembetűnő módosítás az adatút-szélességek növekedése. Amint az előző fejezetben említettük, 2 db 128 bites olvasást tud órajelenként megvalósítani, mely jótékony hatással van a memória-argumentumokkal dolgozó SSEx-feldolgozásra.
- L2 cache
K8 és K10 (dual- és quad-core) esetén egyaránt minden mag saját L2 cache-sel rendelkezik, melyek K10 esetében is azonos paraméterekkel rendelkeznek: 512 KB/mag és 16-utas asszociativitás. Ezen külön L2-táraknak előnyeik és hátrányaik is van a Core 2 egyesített L2-jével összehasonlítva: többek között előnye, hogy több mag erős terhelése esetén is mentes a konfliktusoktól és hozzáférési versenyhelyzetektől; hátránya pl., hogy ha csak egy mag van erősen leterhelve, az kevesebb gyorsítótárral gazdálkodhat.
Az L2 cache exkluzív szervezésű: nem található meg ugyanaz az adat az L1-ben és az L2-ben egyidőben. A két szint 2 db egyirányú buszon cserél adatot, az egyiken fogad, a másikon küld. K8 esetén mindkét adatút 64 bites, így 8 órajel szükséges egy 64 byte-os egység cseréjéhez (ennél kisebb adatméret nem értelmezhető ezen a szinten). Ennek következménye, hogy az L2->mag átvitel aránylag magas késleltetéssel rendelkezik, főleg több vonal párhuzamos igénylése esetén.
Bár még nem tisztázott teljesen, valószínűleg ez a két busz K10 esetén 128 bitre szélesedik, jelentősen csökkentve az említett késleltetést.
- L3 cache
A meglehetősen kisméretű L2 cache-méretek ellensúlyozására a K10 egységesített 2 MB L3 gyorsítótárat alkalmaz, 32-utas asszociativitással. Ez adaptív és exkluzív szervezésű: egyaránt tartalmazza azokat az adatokat, melyek a bármely mag L2-cacheből kerülnek ki (helyhiány és cserélődés miatt), és a több mag által használt adatvonalakat. Amikor a mag L3-olvasási műveletet kezdeményez, az egy speciális vizsgálatot is maga után von: ha az adatot csak egy mag használja, az kikerül az L3-ból, helyet adva az adott mag L2-cache-éből kikerülő adatnak. Ha azonban az adatot más mag is használta, az benn marad az L3-tárban továbbra, és egy régebben használt L3-vonal kerül kiírásra a rendszermemóriába, helyet adva a bekerülő L2-vonalnak.
Látható, hogy az L3-cache jelentős hatással van a magok közti kommunikáció sebességére. Amint korábban kiderült, a korábbi Athlon64 processzorok magjai a memóriabuszon keresztül cserélnek adatokat, nagyban lassítva a közösen módosított adatok cseréjét (Shared/Modified, MOESI protokoll szerint), K10 ezt az L3 cache-en keresztül oldja meg: ha az egyik mag a kérdéses adathoz fordul, a másik mag elhelyezi a módosított adatot az L3 cache-ben, így az előbbi sokkal kisebb késleltetéssel férhet hozzá ahhoz. Amint lesz lehetőségünk, ezt azonnal leteszteljük.
Az L3-cache késleltetése természetesen nagyobb lesz, mint az L2-táraké, mindenesetre az AMD dokumentációiból az derül ki, hogy sebessége függ majd a terheléstől is: ha kisebb a terhelés a CPU-n, a késleltetése csökken, nagyobb terhelés esetén pedig a sávszélessége nő. Hogy hogyan is működik ez a valóságban, alkalomadtán ezt is megvizsgáljuk.
- Translation Lookaside Buffer-ek
A cache-ek mellett még egy típusú gyorsító puffert találunk a processzorokban, a TLB-ket, ezek a virtuális címekhez tartozó, laptáblák alapján számolt fizikai címeket tárolják. A méretük határozza meg, hány lap hozzáférhető költséges table-walk eljárás nélkül (mely több 10 vagy 100 órajelet vehet igénybe). Ez főleg azoknál az alkalmazásoknál fontos, melyek véletlenszerű memóriahozzáféréseket használnak, sűrűn fordulva más-más lapokhoz. A K10 nagyobb TLB-méretekkel rendelkezik, ahogy a táblázatokban látható: főként a 2 MB-os lapokhoz tartoző bejegyzések száma nőtt, továbbá megjelent az 1 GB-os lapméret támogatása, melynek hatása elsősorban a nagy méretű adatokkal dolgozó szerveralkalmazások esetében mutatkozik meg. Megfelelő OS-támogatás esetén a 2 MB és 1 GB lapméreteket kihasználó programok látványos gyorsulást mutathatnak.
- Memóriavezérlő
Ha a kért adat a cache-ek egyikében sem található meg, a memóriahozzáférési kérést az integrált memóriavezérlő kapja meg. Integrált volta csökkenti a memóriakésleltetést, viszont a CPU-t bizonyos memóriatípusokhoz köti, növeli a lapka méretét és csökkentheti a kihozatalt. Az integrált vezérlő a K8 egyik nagy újítása volt, viszont számos esetben nem volt elég hatékony. A K10 esetében viszont jelentős fejlesztésen esett át.
Elsősorban, az adatátvitel az eddigi egyetlen 128 bites vonal mellett további 2 db, független 64 bites vonalon történik, így egyszerre két vagy több mag hatékonyabban dolgozhat a rendszermemóriával.
Másodsorban az ütemező és átrendező algoritmusokat átgyúrták: a vezérlő összegyűjti a különböző az olvasási és írási hozzáféréseket, így a memóriabusz jobban kihasználható. Továbbá a kiírandó adatok egy, egyelőre ismeretlen méretű pufferben tárolódnak átmenetileg (valószínűleg 16-30 elemű, 64 byte elemméretű pufferre számíthatunk). Ezzel a csoportosítással az egymást követő váltakozó írási és olvasási műveletek esetén elkerülhető a memóriabusz folyamatos átkapcsolása, számottevően növelve annak teljesítményét.
Harmadsorban, a memóriavezérlő elemzi a beérkező kérések sorozatait és immár önállóan is képes előbetöltésre (prefetch).
- Előbetöltés
A prefetch egy kényes kérdés K8 esetében. A kis késleltetésű integrált memóriavezérlő által az AMD sokáig kiemelkedő memóriaeredményeket tudott felmutatni, viszont DDR2 memóriák bevezetése után nem tudott lépést tartani a Core 2-vel és annak erőteljes előbetöltési módszereivel. A K8 két előbetöltési mechanizmust alkalmaz, egyet-egyet az utasításoknak és az adatoknak, utóbbi egyszerűen az L2-be tölti be az adatokat. A K10 prefetch-módszereit az alábbiak szerint módosították.
Először is közvetlenül az L1 D-cache-be tölti be az adatokat, így nem kell számolni az L2 késleltetésével. Bár ez, főképp az alacsony asszociativitás miatt, növeli az L1-beli cserélődések számát (felesleges adatok jelenhetnek meg benne), az AMD állítása szerint általánosságban pozitív hatással bír.
Másodszor az alkalmazott adaptív prefetch-módszer immár dinamikusan határozza meg az előbetöltési távolságot, ebben a programban elhelyezett előbetöltő utasításokat is figyelembe tudja venni, ezáltal csökkenti a feleslegesen betöltött adatok mennyiségét. Sokkal rugalmasabbá vált ezáltal, korábban a K8 csak a valójában hozzáférttel szomszédos cache-vonalat volt képes előbetölteni.
Harmadszor maga az integrált memóriavezérlő is kapott egy saját prefetch-képességet: elemzi a magokból érkező memóriahozzáféréseket, az eredmények alapján az írási puffereibe előbetölt adatokat, hozzájárulva a memóriabusz jobb kihasználásához. Mivel a saját puffereibe dolgozik, nincs negatív hatása a cache-ek tartalmára, viszont érezhetően csökkenti az adathozzáférések késleltetését.
Összességében, bár a K10 memória-alrendszerét átdolgozták, azt kell mondanunk, még mindig nem érte utol az Intel processzorokat ezen a téren. Többek között nem képes a pillanatnyilag ismeretlen címre menő korábbi írások elé rendezni a későbbi olvasásokat, alacsonyabb az L1 asszociativitása, keskenyebb a bus (és az sávszélesség) az L1 és L2 között, kisebb az L2 cache. És nem utolsósorban egyszerűbbek az előbetöltési algoritmusok, melyek a Core 2 esetében még mindig hatékonyabbak (például a K10-nek nincs L2->L1 előbetöltési képessége az L2 késleltetésének elrejtésére). Ezek hatása alkalmazásonként eltérő, de az esetek nagy többségében az Intel processzorok hatékonyabbnak tekinthetők ebből a szempontból.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
Egyéb fejlesztések
Ebben a részben csak egy dolgot említek meg, az új utasítások és a virtualizációs fejlesztések igazán csak a (rendszer)programozókat érintik.
A K10 CPU-k új feszültség- és órajelszabályozást alkalmaznak: minden mag a többitől független, terheléstől függő saját órajellel rendelkezik, viszont nem teljesen világos egyelőre az L3 mechanizmusa e téren. Minden mag egyforma feszültégértékkel rendelkezik, mely értéket a legjobban terhelt mag határoz meg. A memóriavezérlő tőlük függetlenül szabályozza feszültségét, kisebb terhelése esetén kisebb értéket állíthat be.
Konklúzió
Minden információt még nem tett közzé az AMD az új processzorait illetően, ezért még várhatunk néhány meglepetést. Mindenesetre, van elég ismeretünk ahhoz, hogy a legfőbb következtetéseket levonhassuk az új mikroarchitektúráról. A számos fejlesztésnek köszönhetően az új AMD CPU-k lényeges teljesítménynövekedést ígérnek elődjükhöz képest, különösen az intenzív lebegőpontos számításokat használó alkalmazásokban. Ez a CPU alkalmas lehet, hogy sikeresen felvegye a versenyt az azonos órajelen működő Intel processzorokkal az alkalmazásban széles körében, és győztesen kerüljön ki. Az újabb alkalmazások, melyeket már az új, egyedülálló képességeihez terveznek, mint a hatékony unaligned load-ok és az 1 GB-os lapméret kihasználása, további teljesítménynövekedést könyvelhetnek el.
Azt viszont hozzá kell tennünk, hogy az új microarchitektúrának továbbra is vannak gyenge pontjai, elég csak megemlítenünk a cache- és a prefetch-rendszert, melyek egyes alkalmazási területeken negatív hatással lehetnek a teljesítményére. A legfontosabb azonban az, hogy a két rivális harcában valószínűleg a működési frekvencia lesz a meghatározó, ami nem lesz túl magas a mostani megjelenés idején. Reméljük, az AMD mihamarobb eléri a megfelelő és versenyképes órajeleket CPU-inál, hogy továbbra is jelentős tényezője maradjon a vásárlók kegyeiért folytatott csatának.Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
robyeger
addikt
Hali! Csinos összefoglaló, grat
De két dolgot kritizálnék, amiről már régebben eszme cserét is folytattunk:
1. ''Az L2 cache exkluzív szervezésű: nem található meg ugyanaz az adat az L1-ben és az L2-ben egyidőben. A két szint 2 db egyirányú buszon cserél adatot, az egyiken fogad, a másikon küld. K8 esetén mindkét adatút 64 bites, így 8 órajel szükséges egy 64 byte-os egység cseréjéhez '',
-szóval ide nyugodtan oda lehet írni, hogy ez alapórajel, hátha valaki azt hiszi, hogy magórajel, ezért is látszódnak magas késleltetések.
2. ''Látható, hogy az L3-cache jelentős hatással van a magok közti kommunikáció sebességére. Amint korábban kiderült, a korábbi Athlon64 processzorok magjai a memóriabuszon keresztül cserélnek adatokat, nagyban lassítva a közösen módosított adatok cseréjé'',
-nem tudom te mit nevezel memóriabusznak?, de itt nem megy le az adat a memóriavezérlőhöz, sőt még az XBAR-on se halad át, a magok az SRQ keresztül kommunikálnak, maga a szorzás (processzor szorzó) is ezen egységben történik.
[Szerkesztve]Keresem a 9th Company: Roots Of Terror játék magyar feliratos változatát,mindenféle megoldás érdekel; Intel Pentium-D940/''C1''stepping/ (1.3V-200x16) @ (1.43V-333x12) 4Ghz
-
P.H.
senior tag
válasz
robyeger
#1438
üzenetére
Mivel a fentiek a [link] cikk fordítása (a mondatok 95%-ának egyértelműen megtalálhatóak az eredeti megfelelői benne, a saját megjegyzéseim OFF-ban vannak), javaslom, kritikáidat itt nyújtsd be: malich_y@mail.ru.
Annyit fűznék hozzá, hogy
1. esetben jól hiszi, magórajel (hiszen »magon« belül vagyunk; L1 és integrált, magórajelen működő L2 között nem sok CPU esetén volt eddig 200 MHz-es adatátvitel: pl. 200 MHz-es Pentium Pro-nál igen). De ha nem így gondolod, megkérlek, keress egy A64-ról ill. Opteron-ról szóló, ilyen szintű szakmai cikket (ne benchmark-ból következtesd ki), ami kifejezetten kimondja, hogy ez így volt K8 esetén, és jelentsd ki tisztességesen, hogy arra gondolsz, K10 esetén is így van (mert ebben a cikkben szó nincs arról, hogy változott volna a kettő közti busz órajele).
2. esetben az idézett rész a ''L3 cache should help speed up the data transfer rate between the cores. As we have already found out, contemporary Athlon 64 processors exchange data between the cores via the memory bus. As a result, access to shared modified data occurs much slower. According to AMD’s materials, quad-core K10 processors may exchange data via L3 cache.'' fordítása. Bár kissé leegyszerűsítette a helyzetet, tudom, hogy mire gondol.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
FireGL
aktív tag
''(mert ebben a cikkben szó nincs arról, hogy változott volna a kettő közti busz órajele)''
Több helyen szó volt róla, hogy a K10 a DDR2 1066MHz memóriákat is szabványosan fogja kezelni. Ezt pedig 200MHz-es órajel miatt nem stimmel. Mivel írták, hogy az AM2-vel is visszafelé kompatibilis lesz, lehet itt fog 200-on menni. Ha az 1066MHz-es memória sebességből következtetek akkor az AM2+ az órajelben is lehet hogy hoz változást.Az embert a gondolkodás tette állattá...
-
dezz
nagyúr
Wow, P.H., ez nem semmi, hogy lefordítottad szinte az egészet... Szerintem érdemes lenne egy cikk formájában leadni a Logouton! (Előtte ki lehet kérni az eredeti cikk szerzőinek engedélyét, bizonyára hozzájárulnak. De talán még erre sincs szükség, meg kellene kérdezni a házigazdikat.)
szerk: ja, a #1355-ösre kaphatok esetleg választ?
robyeger: ''-szóval ide nyugodtan oda lehet írni, hogy ez alapórajel, hátha valaki azt hiszi, hogy magórajel, ezért is látszódnak magas késleltetések.''
Alapórajel!? Ezt szerintem nem gondoltad végig... Akkor minden prociszériánál a szorzótól függene, hány magórajel késleltetésű a L2... Meg ugye (8 * szorzó) lenne a késleltetés, ami kicsit soknak tűnik.
''-nem tudom te mit nevezel memóriabusznak?, de itt nem megy le az adat a memóriavezérlőhöz, sőt még az XBAR-on se halad át, a magok az SRQ keresztül kommunikálnak, maga a szorzás (processzor szorzó) is ezen egységben történik.''
Ott lement, itt nem megy le, ez van a szövegben. Hol a probléma? ;)
A memóriabusz az IMC és a memória közötti busz, nem? Szóval, úgy tűnik, úgy értik, a memórián keresztül cserélnek adatot, ami tényleg jó lassú (csak talán nem akarták ezt nagyon forszírozni).
FireGL: P.H. abban a mondatban nem az alapórajelre gondolt, hanem a L1 és a L2 közötti busz órajelére.
Egyébként meg nyugodtan lehet 200MHz alapórajelű a K10 is, attól még ki tudhatja izzadni az 1066MHz-t a memóriának, pontosabban az 533-at. Állítólag K10-nél független órajelen jár a HT is és az IMC is. De ha mégsem, akkor sincs több ''baj'' a 200MHz-cel, mint eddig, inkább kevesebb: K8-nál a memória órajele így jön ki: alapórajel * mag-szorzó / memória-osztó. Tehát a magórajel eleve befolyásoló tényező, és mivel nincs is túl nagy választék az osztókból, nem mindig jön ki a szabványos memória-órajel. K10-nél - a ''mégsem'' esetén legalábbis - valószínű nagyobb lesz a választék.
[Szerkesztve] -
robyeger
addikt
Tényleg pedig olvastam a cikket. Majd megpróbálok levelezni orosz barátunkkal, de talán van más is akit érdekel a mondandóm, ezért megosztanám
Szeretem a K8-at, mindig tud új meglepetéssel szolgálni , ezért kezdem a:
2. Akár hogy akarom fordítani tényleg azt jelenti hogy a magok a memória ''buszon'' keresztül kommunikálnak. Eddig azt hittem, hogy az AMD-nél a két K8-as magot az SRQ-nál illesztették(kapcsolták) össze és csak azért csináltak osztott memória vezérlőt, mert a K8 csak 1db 128bites memória csatornát tud használni, és megosztva a vezérlőt a magok függetlenül tudnak egymástól kommunikálni a memó felé, amúgy nem lenne lehetséges, egymásra kellene várniuk. Utána olvastam a MOESI protokollnak és úgy néz ki igaza lesz orosz barátunknak. Amit kihámoztam, hogy a valóságban a két magot kizárólag a memóriavezérlőnél(IMC) illesztették össze, akkor pedig nem lehet egy időben 1magnak, a memóriával és a másik maggal is kommunikálni. Szerintem ez csak késleltetésben jobb a PentiumD megvalósításhoz képest integrált volta miatt, módszerében viszont ugyan olyan primitív. K10-nél már 2x64bitet fognak használni, így 2db független kommunikáció lesz lehetséges.
1. X-bit labs már a Hammer-nél se nagyon ecsetelte a processzor szorzót, sajnos most se tette meg. Hiszen a IMC magórajelen működik és az XBAR-on is olyan sebességgel szaladgálnak az adatok, pont ezért lassúnak nem lehetne nevezni, csak ha útközben ott van az SRQ - L2 cache páros, ahol a szorzó miatt szenvedi el a nagyobb késleltetést.
[Szerkesztve]Keresem a 9th Company: Roots Of Terror játék magyar feliratos változatát,mindenféle megoldás érdekel; Intel Pentium-D940/''C1''stepping/ (1.3V-200x16) @ (1.43V-333x12) 4Ghz
-
robyeger
addikt
Feltételezhető, hogy marad a 200Mhz-es alapórajel a K10-nél is, habár ebbe az újabb HTT szabvány is nagyban beleszólhat. Amúgy könnyű kiszámolni, hogy 2db 64bites adatút 200Mhz-en, 6.4GB/sec elméleti sávszélességet biztosít 1db L2 cache számára, ez 400Mhz-es dupla csatornás memóriáknak tökéletesen elég*. Ezért van az, hogy 1magos AM2-es procinak a 800Mhz-es simpla csatornás memória is elégséges, *kivéve a 3D alkalmazásokat, ahol a videó kártya(GPU-ja) a CPUtól függetlenül is emelhet le adatokat az alaplapi memóriából a HTT keresztül, ez processzor szorzótól/alapórajeltől független, (pl: Intelnél az FSBtől).
Ha K10-nél megdublázzák, akkor 12.8GB/sec-re nő az L2 cache koherencia, ami a 800Mhz-es dupla csatornás memóriá sávszélességének felel meg. Ha hozzá veszük a HTT terhelést (grafikus port, IDE, stb...), akkor kiaknázhatók a 1066Mhz-es memóriák is.
Már most meg lehet jósolni, hogy 1db K10-es L2 cache az ennél magasabb DDR3-as frekvenciákkal nem fog tudni semmit kezdeni, nagy kérdés hogy majd a konkurens Intel Nehalem architektúrája ugyan mire fog jutni veleKeresem a 9th Company: Roots Of Terror játék magyar feliratos változatát,mindenféle megoldás érdekel; Intel Pentium-D940/''C1''stepping/ (1.3V-200x16) @ (1.43V-333x12) 4Ghz
-
robyeger
addikt
Gondlom észrevetted már te is, hogy a magórajel nagyban befolyásolja a CPU és memória transzfer teljesítményét, ebbe a késleltetések is beletartoznak, pontosabban a magból nézve egy alacsonyabb órajeles buszról jövő adatok, mindig nagy késleltetésűnek tünnek.
Keresem a 9th Company: Roots Of Terror játék magyar feliratos változatát,mindenféle megoldás érdekel; Intel Pentium-D940/''C1''stepping/ (1.3V-200x16) @ (1.43V-333x12) 4Ghz
-
Raymond
félisten
válasz
robyeger
#1443
üzenetére
''Feltételezheto, hogy marad a 200Mhz-es alapórajel a K10-nél is, habár ebbe az újabb HTT szabvány is nagyban beleszólhat.''
Hogy szolna bele? Nem valtozott ott semmi a HT uj verzioinal.
''Amúgy könnyu kiszámolni, hogy 2db 64bites adatút 200Mhz-en, 6.4GB/sec elméleti sávszélességet biztosít...''
Miota? Jobb lesz ha megprobalsz egy masik szamologepet is hasznalni.
''...12.8GB/sec-re no az L2 cache koherencia...''
Ennek abszolute semmi ertelme. Azt is irhattad volna hogy peldaul ''a lepkek favago kepessege ketszeresere novekedett''.
''Már most meg lehet jósolni, hogy 1db K10-es L2 cache az ennél magasabb DDR3-as frekvenciákkal nem fog tudni semmit kezdeni,...''
LOLerCoaSteR....
Latom idetalaltal a hulyesegekkel. A honapokkal ezelott lefolytatott ''K8 osztott memoria vezerlo'' diskurank ota semmit nem tanultal az itteni hsz-ekbol itelve. Sot, talan meg romolott is a helyzet.
Tobbiektol bocs, nincs per pillanat idom forumozni. Net sincs meg otthon miota koltoztem, melo meg sok van ahoz hogy normalisan irogathassak. Talan a hetvegen.
P.H. le a kalappal a forditasert.Privat velemeny - keretik nem megkovezni...
-
robyeger
addikt
válasz
Raymond
#1445
üzenetére
Ugye azt nem várod el tőlem, hogy a ''hülyeség'' és a ''lepke'' hasonlattól megváltoztatom a véleményem, de mire is?, gondolom majd ha túl leszel a költözködésen kifejted részletesebben is.
Amúgy az a 2db adatút Full duplex vagy ''double pump'' vagy nevezd aminek akarod, de beszélhetünk 4db 64bites adatsínről is, mint a hammer prezentáció 26. oldalán látható ábrán is a CPU és az SRQ között [link], szóval tök mind1, számszakilag ugyan az lesz = 2x2x64/8x200 = 6400Keresem a 9th Company: Roots Of Terror játék magyar feliratos változatát,mindenféle megoldás érdekel; Intel Pentium-D940/''C1''stepping/ (1.3V-200x16) @ (1.43V-333x12) 4Ghz
-
Raymond
félisten
válasz
robyeger
#1446
üzenetére
Tenyleg nincs idom nem vicceltem de egye fene:
A koherencianak semmi koze a gigabyte-okhoz vagy barmilyen mas meretegyseghez. Ha mar nem kerestel ra magadtol, itt az egyik elos google link:
[link]
Amúgy az a 2db adatút Full duplex vagy ''double pump''...
A full-duplex es a double-pump-nak szinten semmi koze egymashoz, nem cserelheted ossze a ket szot. A full-duplex ketiranyu egyideju kommunikacio, a double-pump pedig nem Nem hinnem hogy a szamtechben talalhato abszolute alapfogalmakat itt kene elmagyarazni. Ezeket megtanulhatnak magadtol.Privat velemeny - keretik nem megkovezni...
-
robyeger
addikt
válasz
Raymond
#1447
üzenetére
1db off hsz erejéig válaszolok a nyelvészeti kérdésedre
:
[link] Ez biztos, hogy magyarul van?, mert én egy kummányit se értek belőle, de könyörgöm el ne magyarázd
Jó vettem a célzást, magyarosan megfogalmazva: ''az L2 gyorsítótárak áteresztő képessége a magok között''
A full duplex és a double pump-ra nem mondtam, hogy teljesen azonosak, csak számszakilag egyezik meg az elméleti sávszélességük.
[Szerkesztve]Keresem a 9th Company: Roots Of Terror játék magyar feliratos változatát,mindenféle megoldás érdekel; Intel Pentium-D940/''C1''stepping/ (1.3V-200x16) @ (1.43V-333x12) 4Ghz
-
dezz
nagyúr
válasz
robyeger
#1442
üzenetére
''és csak azért csináltak osztott memória vezérlőt, mert a K8 csak 1db 128bites memória csatornát tud használni''
Nem, két csatornás elérést is tud kezelni, csak egyszerre egy címre (amin az adat egyik fele az egyik csatornáról jön, másik fel meg a másikról). A K10 újdonsága a két csatorna föggetlen kezelési lehetősége.
''és megosztva a vezérlőt a magok függetlenül tudnak egymástól kommunikálni a memó felé, amúgy nem lenne lehetséges, egymásra kellene várniuk.''
''a valóságban a két magot kizárólag a memóriavezérlőnél(IMC) illesztették össze''
Ez így hibás megfogalmazás. Az SRQ is közös és az XBAR is, és pl. a HT-s hozzáféréseket az utóbbi intézi, stb. Az egy másik dolog, hogy a két mag közötti adatcserét esetleg az IMC intézi, bár én nem lennék ebben biztos.
''Szerintem ez csak késleltetésben jobb a PentiumD megvalósításhoz képest integrált volta miatt, módszerében viszont ugyan olyan primitív.''
Bizonyos szempontból talán, más szempontból meg egyátalán nem. (Ha igaz egyátalán.)
''K10-nél már 2x64bitet fognak használni, így 2db független kommunikáció lesz lehetséges.''
Ennél fontosabb (a magok közötti közvetlen kommunikáció szempontjából), hogy a két mag közötti kommunikáció jó esetben a L3 által, rosszabb esetben az XBAR által fog zajlani.
#1443: ''2db 64bites adatút 200Mhz-en, 6.4GB/sec'' - szerintem csak 3.2.
''ez processzor szorzótól/alapórajeltől független'' - nem lehet független, mert a memória órajelét a magórajel is befolyásolja (abból oszt vissza).
''Már most meg lehet jósolni, hogy 1db K10-es L2 cache az ennél magasabb DDR3-as frekvenciákkal nem fog tudni semmit kezdeni''
És miért ne számítana a jobb késleltetés?
#1444: Észrevettem, de ez hogy is jön ide? Válaszolnál konkrétan is?
#1448: ''A full duplex és a double pump-ra nem mondtam, hogy teljesen azonosak, csak számszakilag egyezik meg az elméleti sávszélességük.''
Hát ez, hogy ''az a 2db adatút Full duplex vagy ''double pump'' vagy nevezd aminek akarod'' tényleg eléggé úgy hangzott, mintha szinonímák lennének... ;)
Egyébként még ''számszakilag'' sem, mert az adatirány váltások is időbe tellenek.
[Szerkesztve] -
P.H.
senior tag
Az logout eleve kizárt, két ok miatt is:
- a megjelenést követően okafogyottá válik ez a fordítás, úgyis lesz egy cikk róla
- a szöveg .TXT-ben 33 KB, az 15 ezres limitet figyelembe véve legalább 3 darabban lehetne lehozni.
''- Ha ez memória-hozzáférést takar (ami persze jobb esetben valamelyik cache-ben végződik), akkor AGU-s indítás ide vagy oda, az LSU is meg van dolgoztatva, tehát egy macro-op-ból megvan az egész! (Így tehát egy Inteles micro-op inkább egy AMD-s micro-opra hajaz, semmint egy egész AMD-s macro-opra - tehát a ''3 vs. 4 szélesség'' helytelen, és ez inkább 6 vs. 5 szélesség!)''
Ezt kifejtenéd egy picit bővebben? Sejtem, mire gondolsz, de nem akarok elhamarkodott választ adni.
''2. Ha az FPU-s memória-műveletet is az AGU és az LSU végzi el, mit csinál az FSTORE?''
Fontos elem az FPU-egységben, hogy a registerfile olvasásának lépcsője közvetlenül az FADD/FMUL/FSTORE kezdőlépcsői előtt vannak, de már az ütemezés után - és így a műveletek indítása után (míg az integer-egységben ez az ütemezés előtt). K8 esetében továbbá a registerfile-ba is csak a három egység valamelyike írhat.
Ebből következik, hogy lebegőpontos betöltés (sima load) esetén egy AGU-művelet adja a címet, egy FPU-műveletnek pedig a kapott betöltött adatot be kell írnia a registerfile-ba. Ehhez szükséges egy FPU micro-op, de ezt bármely egység végre tudja hajtani. Csak nem egyszerű eligazodni a K8-as Optimization Manual-ban sem, mivel
MOVAPS reg,mem (load 4x32 bit) mellett nem szerepel semmi
MOVAPD reg,mem (load 2x64 bit) mellett pedig FADD/FMUL/FSTORE szerepel
MOVSS reg,mem (load 1x32 bit) mellett szintén semmi
MOVSD reg,mem (load 1x64 bit) mellett pedig FADD/FMUL van
holott az első két művelet gyakorlatilag ugyanazt jelenti: 128-es memóriaadat betöltése register-be, a második kettő is csak adatméretben tér el egymástól. (A cikk azt írja, a sima load utasításokat eddig az FSTORE végezte, van olyan forrás, ahol tényleg ez található, az Opt. Manual-okban viszont nem).
OP reg,mem esetben a betöltött adatot ugyanígy tudja fogadni az FADD és az FMUL egység (és az FSTORE is), csak mint forrásadatot kezeli és végrehajtja vele a megfelelő műveletet, nem csupán kiírja azt a registerfile-ba.
K10 esetében úgy látszik, megoldották, hogy a registerfile-ba lehet egy negyedik úton is lehet írni (talán az ICU felől), ezért nem szükségesek FPU-erőforrások a sima betöltésekhez, és pl. a konvertálás nélküli (bitmásolásos) intreg->xmmreg adatmozgatáshoz.
Viszont az FSTORE egység legfőbb jellemzője, hogy (az FADD és FMUL egységekkel ellentétben) egyetlen forrásadata lehet csak (vagy egy sem), ennek megfelelően tárolások (szinte az összes) esetén ez az egység olvassa ki a registerfile-ból a megfelelő értéket, és küldi az AGU által kiszámolt cím mellé, de csupán ennyi a dolga sima lebegőpontos adatok esetében. További egyedi tevékenységei (melyeket az FADD és FMUL nem végezhet):
- FPU-státuszok továbbítása az FPU-egységből közvetlenül az integer register-ekbe ([link] ábrán jól látszik a belőle kiinduló adatút az integer egységbe)
- (betöltésnél, integer vagy xmm register-ből) integer->lebegőpontos és (tárolásnál, integer vagy xmm register-be) lebegőpontos->integer konvertálás.
- x87 lebegőpontos konstansok betöltése (0.0, 1.0, PI, log2, stb.)
Kicsit összegezve, a memória-műveletek »csak« azért dolgoztatják (részben csak eddig dolgoztatták) az FADD, FMUL, és FSTORE egységeket, mert a registerfile ''mélyen benn van'' az FPU-egységben, közvetlenül előttük vagy rajtuk keresztül (volt) hozzáférhető.
#1442 robyeger:
Még mielőtt a leveleddel néhány vidám pillanatot sikerülne szerezned nekik, azért érdemes átnézni, hogy ők mire jutottak. Úgy veszem észre, nem találkoztál még vele. Akkor kezdjük az elején, a MOESI-vel, ahogy az elméletben működik (innen: [link])
''If a processor does not find the cache-line in someone else's cache then it loads it from system memory into its cache and marks it as Exclusive. Now whenever it writes something in the cache-line then it becomes Modified. It does in general not write the modified cache-line back to memory. It only does so if a special memory-page-attribute tells it to do so (write through). The cache line will be evicted only later on if another cache-line comes in which competes for the same place in the cache.
If a processor needs to read from memory and it finds the cache line in someone else's cache then it will mark the cache line as Shared. If the cache-line it finds in the other processors cache is Modified then it will load it directly from there instead of reading it from the memory which may be not up to date. Cache to cache transfers are generally faster then memory accesses.
The status of the cache-line in the other cache goes from Modified to Owner. This cache-line still isn't written back to memory. Any other (third) processor that needs this cache-line from memory will find a Shared version and a Owner version in the caches of the first two processors. It will obtain the Owner version instead of reading it from system memory. The owner is the latest who modified the cache-line and stays responsible to update the system memory later on.
A cache-line stays shared as long as nobody modifies the cache-line again. If one of the processors modifies it then it must let this know to the other processors by sending an invalidate probe throughout the system. The state becomes Modified in this processor and Invalid in the other ones. If it continues to write to the cache line then it does not have to send anymore invalidate probes because the cache line isn't shared anymore. It has taken over the responsibility to update the system memory with the modified cache line whenever it must evict the cache-line later on.''
Csak megjegyzésképpen: érdemes elolvasni hozzá ezt a cikket, főleg ezt az oldalát: [link]. Az alján látható, hogy többek között az Intel által használt MESI cache-protocol és az AMD által használt MOESI eltér skálázhatóságban, utóbbi mellett több magot lehet összerakni, mint előbbinél, ezért használja ezt az AMD.
A következő: X-bit's Investigation: Data Transfer Rate between the Cores in Dual-Core Processors, átfogó cikk többmagos rendszerek inter-core kommunikációjáról. Ami itt fontos: [link], [link] és [link]. Érdekes olvasmány; a lényeg kiemelve:
- nem módosított adat esetén: ''So, the results of reading unmodified data make me think that there’s no fast reading directly from another core’s cache. This must be how the MOESI protocol is implemented here: it requests the most recent copy of data from system memory.''
- módosított adat esetén: ''So, I have to state that I can’t find any indication of direct data transfers from one execution core to another in the Athlon 64 X2 processor. According to my tests, the most recent copy of data is always read from system RAM. This must be a limitation of the MOESI protocol implementation. The following seems to happen when data are accessed: on receiving a read request probe read that the second core puts on the system bus, the first core performs a write-back of the modified cache line into memory. After this write or at the same time with it, the requested line is transferred to the second core. If the data in the first core’s cache haven’t been modified, they are read from system RAM. Why is there no direct transfer between the cores via the crossbar switch? Ask AMD’s engineers about that!''
Tehát ezek szerint a MOESI (ami a nagy skálázhatósághoz kell) implementálása olyan, hogy több olyan helyzetben is a rendszermemóriához fordulnaki, amelyekben elméletileg nem kellene.
De ez még mindig csak teszteken alapuló következtetés, mint a te véleményed, itt még csak Occam és az ő borotvája lehet érv a tieddel szemben (és az, hogy nem látnak bele 200 MHz-eket a CPU-ba, illetve nem akarják annak ismert szerkezetét átrajzolni ). De tegyünk hozzá további két dolgot:
- itt [link] egy elég érdekes beszélgetés van a cikkről, az oldal közepén kezdődően. Egy kissé szőrszálhasogató, de van benne valami:
''Today I talked to Patrick Patla, AMD's Director - Server Workstation Division and John Fruehe, Worldwide Channel Market Development for the same division. I asked them about whether the two cores in an AMD dual-core processor can share information in their Level 2 cache with each other over the System Request Queue, and they both emphatically said they could.''
válasz: ''From what you are telling me, AMD says that they can, but ''They Can'' & They Do'' is a different story. And as far as I am concerned they at this point do not share L2 cache. The same goes for there upcoming Quad-Core. L3 is a different story.''
- ...és a K10 az L3-mal: Amint korábban kiderült, a korábbi Athlon64 processzorok magjai a memóriabuszon keresztül cserélnek adatokat, nagyban lassítva a közösen módosított adatok cseréjét (Shared/Modified, MOESI protokoll szerint), K10 ezt az L3 cache-en keresztül oldja meg: ha az egyik mag a kérdéses adathoz fordul, a másik mag elhelyezi a módosított adatot az L3 cache-ben, így az előbbi sokkal kisebb késleltetéssel férhet hozzá ahhoz. (Így értette, kissé leegyszerűsítve a fent vázolt helyzetet)
A mechanizmus ugyanaz maradt: a másik mag ''elindítja a tárolási eljárást'' a módosított adatra, amely ''az L3-ig jut'' csak, és a másik mag onnan kapja meg, a rendszermemória helyett.
És tényleg nagyon zavaró, hogy (már nem először) a kifejezéseket látszólag értelmük ismerete nélkül használod, egyszerűen nem lehet odafigyelni a valós mondanivalóra, és komolyan venni azt, az ilyen mondatok mellett.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
érdekel hogy mi lesz az Intellel föleg az nem hogy feldarabolnák ha az AMD becsödölne de mivel az AMD él és virul szerintem ez tárgytalan.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
és AMD oldaláról nem nagyon nyilatkoztak, hogy hol lesz használva.
Ú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.
- Politika
- GTA VI
- Milyen NAS-t vegyek?
- Alkoholista nevelde
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Franciaországban nyit a Honor 200 Lite
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Világító alma helyett világító tok és szíj az almákra
- Jövedelem
- Rossz üzlet az EV-kölcsönzés
- További aktív témák...
- i3 8100/ ingyen automata
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i3 9100 4 mag 4 szál processzor garanciával hibátlan működéssel
- BESZÁMÍTÁS! ÚJ Intel Core i5 11400F / i9 11900KF / i9 11900K tálcás processzorok 27% áfás számlával
- Újszerű - INTEL Core i5-14600KF 14mag 20 szál 5.3GHz CPU - bolti garanciával