- Ismét a Honoré a legvékonyabb hajlítható
- Xiaomi 13 - felnőni nehéz
- iPhone topik
- Amazfit Active 2 NFC - jó kör
- Google Pixel topik
- Fotók, videók mobillal
- Telekom mobilszolgáltatások
- Samsung Galaxy A54 - türelemjáték
- Xiaomi 14 - párátlanul jó lehetne
- A lapkakészlet és az akku különbözteti meg a Motorola Edge 60 és Edge 60 Pro-t
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
dezz
nagyúr
válasz
#95904256
#1264
üzenetére
''Ha jól sejtem ezek az IPC maximális értékei:
K8: 3,0
Core2: 4,0
K10: 3,0''
Erről már beszéltünk. Ez így helytelen. Az AMD-nél ez (AMD-féle) makroOP-okban értendő, Intelnél meg mikroOP-okban. Namost az alap gépi kód AMD-nél általában 1db (AMD-féle) makroOP-ra fordul, Intel esetén viszont általában 2 mikroOP-ra. Így az Intel-féle mikroOP fúzió nélkül a Core2 2,0-ra jön ki, azzal együtt meg kb. egálban vannak.
[Szerkesztve] -
Andre1234
aktív tag
válasz
#95904256
#1236
üzenetére
Én már annak is örülök ha kijön szeptemberben a barca..
Lehet hogy marketing szöveg lehet hogy nem de vhogyan válaszonli kell a penyrin-re.
Lassan ismét elkezdődik az üzenetháború a két cég között ismét.
Miért is???
Utasítás/clock magassab órajelen nem több számítási eredmény? -
P.H.
senior tag
válasz
#95904256
#1227
üzenetére
''A memory access reordering pedig valóban egy olyan elem ami elősegíti a nagyobb teljesítmény elérését, azonban ezzel nem lehet úgy számolni hogy pusztán rátevődik a gyorsulásra.''
Egyrészt a pipeline-on kívül van a Load/Store Queue és az Store-Load Forwarding (Intel és AMD esetében is), illetve még egy, sokkal fontosabb szempont jön a képbe: egy ciklus általában bizonyos adatok betöltésével, feldolgozásával, és a célhelyre kiírásával foglalkozik, mindez teljes függésben (unrolled esetben kissé hatékonyabban, egyszerre több ilyen függő, de egymástól független sorozat van egymás mellett). A modern out-of-order CPU-k a függőségeket úgy ''oldják fel'', hogy a decore-fázis pár ciklussal előrébb jár, mint az execution unitok, és sokkal többel előrébb, mint a retirement. Ehhez kell a minél nagyobb ICU, ROB, ütemezői bufferek, stb. (ezért írtam másik topikban, hogy nem értem, miért nem használja ki az AMD a rendelkezésre álló 96 elemű ICU-t a 3-szélesség esetén; mondjuk az látható, hogy K7->K8 és PentiumM -> Core microarchitecture esetben is nőtt az ütemezők puffermérete, K8->K10 esetben talán a sokkal kevesebb macro-op miatt nem szükséges). No most, ha a csak a load-ok rendezhetők át egymás között (vagy hajthatók végre párhuzamosan), de a store-okkal nem, mint eddig, akkor látható, hogy ez ''némileg'' visszafogja a teljes alapelvet. (A bonyolultabb [xxx+yyy*z(+aaa)] vs. egyszerűbb [xxx] effektívcím-számítás - ami még magában pipeline-ban történik - rendezése egy cikluson belül még K10 esetén is ugyanúgy optimalizációs lépés, mint korábban.)
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#1224
üzenetére
Nem, ebben tévedsz, pipeline-on belül minden (és az említett) esetben legfejlebb akkora gyorsulás lehet, mint amekkora a legerősebben szűk keresztmetszet átmérőjének növekedése (amit említettél, ott kétszeres).
Pl. Ha folyamatos 128 bites add-mul-load/store SSE-utasításfolyamról van szó, akkor órajelenként eddig K8-on ''1.5 utasítás'' (1 128 bites utasítás=2 64 bites macro-op, a pack-stage-ek miatt 3 macro-op=''1.5 utasítás'') ment át a decode-fázison; órajelenként 3 64 bites macro-op, tehát 1.5 128 bites utasítás fejeződött be az execution unitokban; viszont órajelenként 1 128 bites utasítás ment át a retirement-fázison, így gyorsan betelt az ICU, mivel a többi fokozat gyorsabb volt, mint a retirement, tehát az ICU nem ürült, ezt akadályozta a szűk retirement. Így igen gyorsan gyakorlatilag órajelenként 1 db 128 bites utasítás ''került ki'' a CPU-ból befejezetten (nesze neked superscalar felépítés).
K10 esetén órajelenként 3 128 bites utasítás dekódolódik, az említett kódfelépítés esetében órajelenként 3 végezhet, és 3 vonulhat vissza (lévén nem Double-ok már, hanem DirectPath utasítások).
''Utasítás'' alatt fent mindenhol a programozói szintű utasításokat értem.
Tehát úgy nem lehet összeadni, hogy ez is 2x-esére gyorsul, az is 2x-esére, akkor összesen négyszeresére, mert ez egy pipeline, amiben csak az ütemezőkben előzhetnek meg bizonyos utasítások más, programsorrendben későbbieket (sehol máshol), és az eleje (decode) és a vége (retirement) is programsorrendbeli.
Mivel az eddigi legszűkebb keresztmetszet 3x-osára szélesedik, ezért ebből legfejlebb háromszoros gyorsulás következhet. Viszont a memory access reorder (a későbbi load-ok a korábbi store-okat megelőzhetik, ha nem azonos címre mennek, illetve nem fednek át; ezek eddig az x86 világban Core2 kivételével MINDIG programsorrendben történtek) által hozott gyorsulás még a fentiekre tevődik rá (és ez az tisztán x86 integer kódokat is érinti).
Még mindig tisztán elméletileg.
[Szerkesztve] -
-
P.H.
senior tag
válasz
#95904256
#1220
üzenetére
Elméletileg lehetséges pl. ugyanannál az SSE vagy (akár integer) SSE2 kódnál is, ha azt vesszük, hogy a decode-sávszélesség kétszeres, a retire-sávszélesség háromszoros, a 64->128 megintcsak kétszeres gyorsulást hozhat elméletben K10-nél K8 ellenében, plusz a Core2-ből ismert memory access reordering is jelentősen emelhet mindezen felül nem keveset. Mindez inkább attól függ, mi volt az adott kódban eddig a legmarkánsabb szűk keresztmetszet (pl. felváltott SSE add-mul-load/store utasításoknál, amik teljesen párhuzamosan haladhatnak, a retirement + a memory access, ott lehet több, mint háromszoros gyorsulás. Illetve néhány utasítás, pl. a shuffle utasítások VectorPath-ról DirectPath lettek.) Persze mindez tisztán elméleti számítás.
[Szerkesztve] -
Andre1234
aktív tag
válasz
#95904256
#1206
üzenetére
3GHz K10! Várunk szeretettel..
A vga-k hogy voltak kötve???Nekem úgy tűnik a képen hogy a két fölső CF-ben van és a harmadik ??Írja angolul csak nem nagyon világos számomra.Nem akarok butaságot leírni.
Tényleg hídban van mind3????
mod:ja igen... látjátok az a kis csúnyaságot a kép tetjén ami a tápra van ráírva???
[link]
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1175
üzenetére
Az AM2+ és az AM3-as procik között az a legnagyobb különbség, hogy az utóbbi támogatja a DDR3-at is. De kompatibilis a DDR2-vel is. (Azt nem tudom, készíthető-e DDR2 foglalatos AM3-as alaplap.)
Némi újabb AM2+, AM3 infó: [link]
''65nm, 45nm CPUs to fit into every AM2 motherboard''
Jóvá akarják tenni a 939-es fiaskót. -
Rive
veterán
válasz
#95904256
#1175
üzenetére
Hallottátok hogy az OCZ kijött egy speciálisan AM2-es AMD processzorokhoz tervezett memóriával? [link] Gondolom méregdrága lehet ha 4GB-osnál kisebb kiszerelésben nem lehet hozzájutni. Azonban ez ''csak'' egy DDR2-667-es RAM, 5-5-5-15 késleltetéssel. Ez mitől érheti meg az árát?
Szerintem nem éri meg az árát. SZVSZ max. annyi változás várható tőle, mint anno az FPM -> EDO kapcsán. Azaz memóriasebességben - nem gép-sebességben! - 3-5%. -
VR6-Fan
veterán
válasz
#95904256
#1171
üzenetére
nagoyn jó lenne főleg ha az intel mindenkori procijaivla az árversenyt is tudná tartani
(remélem a teljesítményre nem lesz panasz!!?)
de persze tudom azt is hogy most a szerver az elsődleges szempont.
amennyiben ki jönnek az AM2+ lapok és veszek egyet valami közép kategoriás ATI-re gondolok(asszem RD780) meg hozzá 2-1giga 1066-os ramot és amég nem lesz K10 addig valami olcsó K9, ez mennyire jó ötlet illetve amik most jönnek ki phomonok azok am2->am2+->am3-ban mint menni fognak
-
VR6-Fan
veterán
válasz
#95904256
#1169
üzenetére
a születés napom elött egy nappal
![;]](//cdn.rios.hu/dl/s/v1.gif)
és a desktop részlegről mit lehet tudni meg esetleg kósza árszegmens pletykák se keringenek valahol
illetve az AM2+-os lapokról(tudod nem ide tartozik, csak ha már itt vannak olyanok akik elégé benne vannak ) illetve az RD7xx-as chip családról némi hasonló info morzsa? -
dezz
nagyúr
válasz
#95904256
#1156
üzenetére
Nocsak, nocsak, nocsak... Nem is olyan nagyon gyors fp-ben ez a Core(2). Hiszen legjobb esetben is csak 2x gyorsabb, mint a K8, más esetekben még annyival sem. (x87 kódban még lassabb is.) Csakhogy, mint láttuk, a K8 kifejezetten lassú SSEx-ben... Minden valószínűség szerint jóval a 2x64->1x128 bit jelentette alap ~2x-es gyorsulás felett fog gyorsulni a K10 a K8-hoz képest, így szépen beelőzheti a Core(2)-t... Mondjuk a teljes képhez hiányzik még a PM/Core(1) teszt. (Meg persze ehhez a Penrynnek és az SSE4-nek is lesz 1-2 szava.)
És akkor egy K8 vs. Netburst összehasonlítás, csak úgy poénból:
Fast SSE2: 531 / 219 * 1890 / 3000 = 1,52
Fast SSE::: 531 / 312 * 1890 / 3000 = 1,07
Fast x87::::: 406 / 406 * 1890 / 3000 = 0,63
Slow SSE2: 391 / 187 * 1890 / 3000 = 1,31
Slow SSE::: 515 / 412 * 1890 / 3000 = 0,78
Slow x87::::: 406 / 500 * 1890 / 3000 = 0,51
Namost, pl. a 3D renderer szoftverek x87-ben vannak, hát nem csoda, hogy inkább K8-ból építettek renderfarmokat korábban. -
#95904256
törölt tag
válasz
#95904256
#1155
üzenetére
C2D / K8 teljesímény arány, órajelre vetíteve a fenti adatokból )
( K8futásidő #1154 / C2Dfutásidő #1155 * K8órajel / C2D órajel )
Fast SSE2 : 531 / 218 * 1890 / 2295 = 2,0059
Fast SSE : 531 / 218 * 1890 / 2295 = 2,0059
Fast x87 : 406 / 375 * 1890 / 2295 = 0,8916
Slow SSE2 : 391 / 171 * 1890 / 2295 = 1,8830
Slow SSE : 515 / 375 * 1890 / 2295 = 1,1310
Slow x87 : 406 / 406 * 1890 / 2295 = 0,8235 -
-
P.H.
senior tag
válasz
#95904256
#1138
üzenetére
ADDPS 8 független utasítással: természetesen 2 028 118 976
Függő utasítások, mindhárom esetben K8 latency 5 op reg,reg esetén, latency 7 op reg,mem esetén:
ADDPS: 4.072.882.360
MULPS: 4.067.804.988
MULPD: 4.074.141.459
A Te esetedben is és itt is ''elrejtette'' a load-ok lappangását a soros utasításvégzés, K8 esetében szépen kijön a ''The low half of the result is available one cycle earlier than listed'' (ez azért érdekes, mert MULPD mellett nincs ott ez a megjegyzés. Lemaradt?)
Fentebb természetesen a 25%-kal a 5->4 latency-változásra gondoltan, 4-->3 esetben ez 33%. (Ja, és itt ugyan nem, mert órajelenként függő és független esetben is legfeljebb egy utasítás végez, de K8 esetében brutálisan kijön a korábban említett retirement-bottleneck, hogy órajelenként egy SSEx utasítás vonul vissza, hétvégén beteszem majd a - fentebb állatorvási lóként emlegetett - programot és a forrást is, egyúttal ki fogja hozni az Intel-ek egy load-portjából fakadó szűk keresztmetszetét is. Netburst esetében igen látványos, kíváncsi leszek Core2-re is).
Az assembly forrásokat mivel fordítod?
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1137
üzenetére
Kicsit félreérthetően fogalmaztam. Persze a legeslegfontosabb a valós alkalmazások, mint valós programok teljesítménye, de ott a ''valós alkalmazás''-on egy összetettebb számítást értettem, illetve annak magját, ami nagyrészt a regiszterekkel dolgozik, vagy esetleg a L1-D-ből/-be is, és minnél magasabb IPC-re hajt. Tehát ami a magot teszteli, és a memóriahozzáférés, sőt még a többi cache elérése sem befolyásolja. (Aztán lehet továbblépni, a L2 bevonásával, majd a L3 bevonásával, és így tovább. Aztán ki lehet adni, mint teljes körű belső teszt-programcsomag.
)
[Szerkesztve] -
-
-
Raymond
titán
válasz
#95904256
#1115
üzenetére
Otthon lefuttatom. Addig kiprobaltam itt par Netburst-os procin es mindegyiknel 2+ az eredmeny verziotol, magok szamatol es OS-tol fuggetlenul:
PD930 (3Ghz)
WXP__32bit 2.041.455.751
WXP__64bit 2.015.496.982
W2K3_32bit 2.011.497.459
PD820 (2.8Ghz)
WXP__32bit 2.048.120.649
P4NW (2Ghz)
WXP__32bit 2.019.251.600
Ad cache:
Osztott vagy nem osztott video kodolasnal mindegy mintahogy a meret is aranylag lenyegtelen mivel stream-elt adatok feldolgozasarol van szo. Egyebkent a C2D kozos L2 cache automatikusan mukodik mert hardveres implementacio igy nem kell hozza OS tamogatas.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#1106
üzenetére
Én mondjuk szívesebben vetném össze közel azonos órajelű Core Duo-val, az is 64 bites execution unitokkal rendelkezik, de közelebb áll a Core2-höz felépítésben (micro-op fusion, rövid pipe, shared L2, stb.). Szerintem úgy másképp alakulna az órajellel arányos gyorsulás.
dezz: immediate x87 és SIMD esetében nem lehet, csak csak x86 utasításokban, nem jelentős, ha elfér 8 biten, akkor úgy ábrázolódik. A címeltolások száma sokkal fontosabb tényező, ez sokkal ritkábban fér el 8 biten (optimalizációs fogás úgy beállítani a pointer-eket, hogy a lehető legtöbb elférjen), ekkor pedig minimum 6 byte-os utasításokkal számolhatunk (SIMD esetben min. 7 byte).
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1105
üzenetére
Igazad van, nem sok az immediate adat (legalábbis a hosszabb). És gondolom, ez nagyrészt így is marad. Kicsit bugyuta volt a kérdés is.
Viszont akkor nyilván jót tesz a dolog az utasítás-áteresztő képességnek, vagy nem? Csak nem véletlenül szélesítették ki a duplájára, amikor a C2D-nek is ''elég'' a 128 oda.
Nemrég egy Barcelona bemutatón 720p-s videót kódoltak h.264-be real-time (1080p-set meg közel real-time, ha jól emlékszem). Core2Quaddal nem mutogattak még ilyet. És a publikált SPECfp értékek is elég jók.
ps. jaj, közben látom, hogy tényleg 64 bitesnek írtam az adatutat a C2D-nél - a 128 vs. 256 bitre gondoltam.
(#1106): Azért ez így egy kicsit csalóka, mert a P-D viszont már messze áll a 2x-es gyorsulástól az egymagos P4-hez képest, vagy ebben nem? És akkor ott van még, amit írtál, tehát a memóriahozzáférés. Plusz a nagyobb L2.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1103
üzenetére
Értsd: a C2D-nél már 128 bites. Bár csak az I-Cache - a D-Cache 256 bites. Viszont a K10-nél mindkettő 256 bites. [link] Kérdés, az adatok mekkora része bennefoglalt az utasításokban.
Lehet, hogy 1-1 utasítás 2x gyorsabb lehet, de nem vettem észre, hogy pl. a videokódolás is 2x gyorsabbá vált volna.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1098
üzenetére
A K8 megjelenése utáni években 2 új mikroarchitektúrán is elkezdtek dolgozni - versenyezni akarván az Itaniummal, amiről akkor még azt lehetett gondolni, leváltja az x86-ot. (Talán a NetBurst-ös szenvedésben is szerepet játszott ez a dolog.) De mint tudjuk, nem így történt. Aztán az AMD az X2 projekttel töltötte az idejét (pl. áthozták a korábban csak szerverprocikban megtalálható crossbar switchet, stb.), miközben az Intel egyszerűen egymás mellé tett két P4-et, így született a P-D. És csak ezután kezdhettek hozzá a K8 frissítéséhez+bővítéséhez, ami a K10.
Az Intelnél is 64 bites maradt az SSEx a Core2-ig, és még annál is csak az egységek 128 bitesek, az adatutak maradtak 64 bitesek, így nem is hozza a (közel) 2x-es gyorsulást (amit az Inteles marketing próbált elhitetni). Ellentétben a K10-zel...
[Szerkesztve] -
-
-
#1065
VaniliásRönk
nagyúr
#95904256
#1064
VaniliásRönk
nagyúr
válasz
#95904256
#1064
üzenetére
Már megbocsáss, de nem emlékszem hogy 2x is szerkesztettem volna a hsz-t, bár megeshet, a memóriám néha cserben hagy, de számonra is nyilvánvaló hülyeségeket biztos nem írok le, márpedig ez az azonos terültelen többet fűt dolog ez az.
Szerk.: Ez meg off.
Szerk.2: Úgyhogy itt max. én vagyok hülyének nézve. (így látszik hogy 2x módosítottam)
[Szerkesztve] -
#1063
VaniliásRönk
nagyúr
#95904256
#1062
VaniliásRönk
nagyúr
válasz
#95904256
#1062
üzenetére
A 1049-be csak beírtam azt amit a ''Szerk.:'' után látsz, olyat biztos nem írtam hogy kisebb területen fűt ugyanannyit, mert ez csak hűtési gondokat okozhat (ami így vagy úgy megoldható lenne), a fogyasztást nem befolyásolja, tökmindegy mekkora területen fogyaszt ugyanannyit a CPU. (na ez viszont gond, Prescott óta ez a vesszőparipája mindkét gyártónak, Intel itt is megmutatja mennyire korrekt a TDP értékeivel)
-
#1061
VaniliásRönk
nagyúr
#95904256
#1059
VaniliásRönk
nagyúr
válasz
#95904256
#1059
üzenetére
Azt hittem valami újat mondasz. Egyértelmű, hogy ha nem emelnek órajelet, és a tranzisztorok száma sem nő, akkor csökken a fogyasztás, de Penryn több tranzisztorból fog állni, és az órajelét is emelni szeretnék.
Ha már az első modelleknél ugyanannyi (Intelnél a ''vagy kisebb'' felejtős, ha már ők is csak azt mondjék hogy vagy, akkor az lesz ugyanannyi) a fogyasztás, ami ha jól tudom 3.33GHz lesz, akkor ők is bajban lesznek az órajel további emelésével. -
-
#1047
VaniliásRönk
nagyúr
#95904256
#1046
VaniliásRönk
nagyúr
-
Oliverda
titán
válasz
#95904256
#1034
üzenetére
Hát, ha nem is jelentősen fűt, de biztos nincs jótékony hatással a fogyasztásra. Valahol mintha egyszer olvastam volna hogy könnyebb azt a procit húzni amelyikben kisebb a cache. Az is lehet hogy innen ered az állítólagos gyenge tuning potenciálja az eddig elkészült Penryn prociknak.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1039
üzenetére
Ugyebár volt itt korábban egy összehasonlítás, amiben a feladatok többségében azonos órajelre számolva 5-10% gyorsulás volt tapasztalható - azonban nem lehet tudni, ez mennyiben írható a megemelt FSB és/vagy L2 számlájára. (Ezeknek meg is van az AMD oldali megfelelője, a jobb és gyorsabb memóriavezérlő, és a bejött L3 képében.) Jó, hogy gyorsult az osztás, de kérdéses, ez mekkora hatással van egy egész program futására, főleg hogy ahol lehet, inkább kiváltják egy (reciprokos) szorzással. Az SSE4 is jó dolog, de csak egyes feladatokban számít, és kérdéses, mennyire. (Az Intel saját tesztjei mellett várjuk meg a tesztoldalak tesztjeit, mivel kérdéses, mennyire és hogyan is volt optimizálva az, amivel összehasonlították az SSE4-re optimizált változatot abból a bizonyos videokóderből.) A másik, hogy az SSE4 nagy része már meglévő utasítások egyéb adattípusokkal való kiegészítése. Persze nem árt, hogy pl. SP FP mellett már pl. 16 bites inttel is megy valami, csak kérdéses, mire elég a 16 bites int?
-
#65675776
törölt tag
válasz
#95904256
#975
üzenetére
Ez nem úgy tűnik, hanem így van. A Socket F többletkivezetései pl a több HT link miatt szükségesek (egy link 74 vezetéket igényel, legalábbis HT1.01 szinten). Emellett nem lepődnék meg ha kiderülne, hogy a Socket F már fel van készítve a splitted power planes-re, csak jelenleg nem lenne kihasználva.
-
#961
Komplikato
veterán
#95904256
#941
Komplikato
veterán
válasz
#95904256
#941
üzenetére
''Lényeg: 4 magos Barcelona tömegtermelés leghamarabb októberben indul.''
Barcelona available in July claim - [link]
An American server renting company has announce that Barcelona Quad core based servers comes in July 2007.
We are not sure is the information up to date but the company has all the names and the specs up on its site. It will offer Opteron 2258, Opteron 2260, Opteron 2262, Opteron 2264, Opteron 2266 and Opteron 2268.
If this turns to be true, which we really doubt the cheapest Barcelona server will be available for rent for $259 a month for a 2 GB machine, which is not too bad.
Barcelona K10 comes in late Q3 in best case scenario while the real availability is expected in early Q4.
You can check the specs here.
[link]
Hmmm.
Az oké, hogy pletykalap, de a linken tényleg ott van.
Szerk.: Amúgy volt egy marék AMD-s hír az oldalukon, csak a fene tudja melyik igaz.
[Szerkesztve] -
Raymond
titán
válasz
#95904256
#957
üzenetére
A juliusi inkabb ugy nezett ki mint egy valasz a 10h-ra. Most hogy gyakorlatilag biztos hogy meg a szerver valtozatok sem lesznek elerhetoek normalis mennyisegben osznel hamarabb nincs okuk akkorat csokkenteni az arakon. Inkabb fogjak a reszvenytulajokat simogatni es javitanak a gross margin-on ami miatt ragjak a fuluket mar par negyedeve.
Ha kell a teljesitmeny akkor szvsz egy C2Q nem lenne rossz. Foleg ha tenyleg lezuhannak az ara a beka segge ala. Persze ezek az arak relativak. Az hogy nekem OK (lenne ha kene) egy 266-os ar az nem jelenti azt hogy neked is az. -
P.H.
senior tag
válasz
#95904256
#932
üzenetére
Meg akartam kérdezni, milyen jellegű kódnál jött ki a 87% különbség, de nem kérdezem, nincs miért. Dezz, megnéztem, aztán a K8 idevonatkozó adatait is.
K8 retirement-szélesség órajelenként 3 macro-op. De nem DirectPath Double utasítások esetén, ez minden 128 bites SSEx utasításra hatással van. A két 64 bites macro-opnak azonos órajelben, egyszerre kell visszavonulnia, így a 3. slot-ba sem kerülhet másik 128 bites utasítás egy macro-opja. Tehát a retirement leszűkül órajelenkénti 1 vectorSSE utasításra, legyen az op reg,reg vagy op reg,mem. (Ellenben Core2 4 vagy a korábbi Intel-ek 3 értékével, op reg,reg-re nézve...)
''Most 128 bit SSE and SSE2 instructions are implemented as double dispatch instructions. Only those that can not be split into two independent 64 bit operations are handled as Vector Path (Micro Code) instructions. Those SSE2 instructions that operate on only one half of a 128 bit register are implemented as a single (Direct Path) instruction.
[...]
A disadvantage may be that the decode rate of 128 bit SSE2 instructions is limited to 1.5 per cycle. In general however this not a performance limiter because the maximum throughput is limited by the FP units and the retirement hardware to a single 128 bit SSE instruction per cycle.
[...]
Instructions generated by Doubles can mix with other (Direct Path) instructions during decoding and retirement. The two instructions generated by a Double must however retire simultaneously, imagine a PUSH that does retire the memory store but doesn't retire the Stack Pointer update.. This leads to the limitation that both instructions generated by a Double must be in the same 3 instruction line during retirement.''
Vigasz, hogy K10 esetén DirectPath lesz a 128 bites utasítások többsége, így a decoder-bandwidth kétszeresére, a retirement háromszorosára fog nőni ezek esetében, kisebb latency és nagyobb throughput mellett, ez talán jelentősen megnöveli a SSEx-teljesítményt. Nem alaptalan Dezz [link] elmélkedése.
[Szerkesztve] -
válasz
#95904256
#932
üzenetére
nagyon nem értek hozzá, de olvasgattam amit itt írogattok, tehát csak tippelgetek és javítsatok ki ha rosszul látom a kérdést
nem az lehet ennek a fő oka, hogy a c2 az egyszerre 128 biten tolja át azt a 128 bites sse utasítást míg az amd csak 2x64-en (tudom ennél kicsit sokkal sokkal bonyolultabb)?
ha esetleg így van akkor szerintem az amd 87%-os ''lemaradása'' nem is olyan nagyon rossz, és ahogyan olvastam a k10 pontosan 2x olyan gyors lesz ezen a téren, tehát az intel optimalizált kódban is megveri a k10 a c2-t.
nekem ez jött le az itteni hozzászólásokból.
-
P.H.
senior tag
válasz
#95904256
#688
üzenetére
Tekinthető alapnak ez Intel-dokumentáció (http://www.intel.com/design/processor/manuals/248966.pdf)
Adós vagyok még egy válasszal ROB-ra vonatkozó kijelentésemre, de először egy helyesbítés: a 4-1-1-1 bottleneck Core2-re nem igaz. Valóban 4-1-1-1 felállás, de nem μop-ok a decoder-ek kimenetei, hanem micro-fused μops, ezt a fenti .pdf konzekvensen használja minden említéskor (nem úgy, mint egyes dokumentációk, amik oldalakon keresztül vezetik le, hogy „single-μop”, aztán a végére odabiggyesztik egy mondatba, hogy ezek valójában micro-fused μops…)
''All decoders support the common cases of single μop flows, including: micro-fusion, stack pointer tracking and macro-fusion. Thus, the three simple decoders are not limited to decoding single-μop instructions. Packing instructions into a 4-1-1-1 template is not necessary and not recommended. ''
Ezt bottleneck-nek tekinteni semmiképpen nem lehet, még az AMD megoldásánál is szélesebb, ezt így ebben a formában csak sorozatos op [mem],reg vagy microcode-ROM alapú utasítások tudják megfogni.
Intel ROB (és egy kicsit tágabban, és ott nem csak Core2-re gondoltam):
- Az Intel CPU-k esetében semmi nem cáfolja azt, hogy egyetlen, 128 bites egységméretű register-file van, tehát az integer register-ek is 128 bitesek (Core2 esetében kibővítették az integer ALU-kat is 128 bitre, ezek végzik pl. a SSEx logikai műveleteket, az int-FPU és FPU-int átkapcsolás ára egy + órajel késleltetés). Ha egy register-file van, akkor az rename miatt annyi belső register-nek kellene lennie legalább, ahány elemű a ROB (minden micro-fused μops-nak jusson más-más célregister átnevezés után) + a véglegesített register-értékek + a belső átmeneti register-ek. Ezt a nagy register-filet írni/olvasni kell, ez a ROB feladata. Emellett a μop-okban található argument placeholder-ek (hogy mondják ezt magyarul két szóban?) is 128 bitesek, az AMD 64 biteseivel szemben.
- Intel esetében egy hosszabb kódot figyelembe véve valamivel több μops keletkezik fordítás után, mint amennyi micro-op AMD esetében, ez a szám nem csökkent számottevően az idők folyamán (ennek egyik oka, hogy az Intel alapból 128 bites register-file-t és default adatméretet alkalmaz, Netburst óta biztosan, az execution pipe-okban törtek ketté 64 bites elemekre a 128 bites adatok, majd fűződtek össze, növelve a késleltetést). K10 esetében viszont drasztikusan csökken a szükséges micro-opok száma 128 bites műveletek esetében, felére. De nézzük végig a ROB- és Reservation Station-méreteket, utóbbi adja nagyjából az adott CPU out-of-order előrelátási mélységét:
Core2:
..ROB: 96 micro-fused μops
..RS: 32 entries
..decoders: 4-1-1-1 micro-fused μops/cycle
..ROB read ports: 2 (3?)
..Possible input registers/cycle: 4x3
Pentium M/Core Solo-Duo:
..ROB: 40 micro-fused μops
..RS: 20 entries
..decoder: 4-1-1 micro-fused μops /cycle (128 bites műveleteknél csak store-fusion van, load-op fusion nincs)
..ROB read ports: 2
..Possible input registers/cycle: 3x3
Netburst:
..ROB 126 μops
..RS: N/A
..decoder: 4 μops/cycle + trace cache
..ROB read ports: N/A
PPro/P2/P3: ROB:
..40 μops
..RS: 20 entries
..decoders: 4-1-1 μops/cycle
..ROB read ports: 2
..Possible input registers/cycle: 3+2+2
K7:
..Instruction Control Unit: 72 macro-ops (up to 144 micro-ops)
..Integer Scheduler (18 macro-ops) + FPU scheduler (36 macro-ops): 54 macro-ops (up to 18*2+36=72 micro-ops)
..IFFRF-read + FPU register-file read: 9+5/cycle
..Possible input registers/cycle: 3x3 + 2+2+1
K8, K10:
..Instruction Control Unit: 72 macro-ops (up to 144 micro-ops)
..Integer Scheduler (3x8 macro-ops) + FPU scheduler (36 macro-ops): 60 macro-ops (up to 24*2+36=84 micro-ops)
..IFFRF-read + FPU register-file read: 9+5/cycle
..Possible input registers/cycle: 3x3 + 2+2+1
- Hogy miért emeltem ki a ROB – Register File olvasások számát? Van itt egy súlyos maradvány bottleneck Core2 esetében:
As a μop is renamed, it determines whether its source operands have executed and been written to the reorder buffer (ROB), or whether they will be captured “in flight” in the RS or in the bypass network. Typically, the great majority of source operands are found to be “in flight” during renaming. Those that have been written back to the ROB are read through a set of read ports.
Since the Intel Core Microarchitecture is optimized for the common case where the operands are “in flight”, it does not provide a full set of read ports to enable all renamed μops to read all sources from the ROB in the same cycle.
When not all sources can be read, a μop can stall in the rename stage until it can getaccess to enough ROB read ports to complete renaming the μop. This stall is usually short-lived. Typically, a μop will complete renaming in the next cycle, but it appears to the application as a loss of rename bandwidth. Some of the software-visible situations that can cause ROB read port stalls include:
• Registers that have become cold and require a ROB read port because execution units are doing other independent calculations.
• Constants inside registers
• Pointer and index registers
In rare cases, ROB read port stalls may lead to more significant performance degradations. There are a couple of heuristics that can help prevent over-subscribing the ROB read ports:
• Keep common register usage clustered together. Multiple references to the same written-back register can be “folded” inside the out of order execution core.
• Keep dependency chains intact. This practice ensures that the registers will not have been written back when the new micro-ops are written to the RS.
These two scheduling heuristics may conflict with other more common scheduling heuristics. To reduce demand on the ROB read port, use these two heuristics only if both the following situations are met:
• short latency operations
• indications of actual ROB read port stalls can be confirmed by measurements of the performance event (the relevant event is RAT_STALLS.ROB_READ_PORT, see Appendix A of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3B)
If the code has a long dependency chain, these two heuristics should not be used because they can cause the RS to fill, causing damage that outweighs the positive effects of reducing demands on the ROB read port.
Annyira zavaró ez a szűk keresztmetszet, hogy az Optimization Reference szerzője tanácstalan, hogy hogyan kellene elkerülni. És ezalapján egy sima
movaps xmm1,[esi+ecx]
addps xmm1,[edi+ecx] vagy xorps xmm1,xmm2
movaps [ebx+ecx],xmm1
sub ecx,edx
jg …
ciklus is meggátolja a 4 micro-fused μop/cycle ROB-ba érkezését. (amennyiben esi, edi, ebx mondjuk tömbcím, tehát konstans, és az xmm2 mondjuk egy előjelváltó 128 bites konstans, edx-ben pedig a 10h érték van, előre felvett konstansként).
- Az Intel esetében a Reservation Station osztja el a μop-okat a 6 execution unit között. Minden órajelben hatot kell találnia a 6 execution port-ra („vízszintes” irány) out-of-order („függőleges” irány). Ezzel szemben AMD esetén a scheduler-eknek 9-et (dezz #734, raymond #736: jó az a kilences szám, 9 execution unit van, legalábbis K7 óta. Nem újdonság, de úgy látszik, nem minden csoda tart csak három napig. Az, hogy az „instructions” hogy került mögé „micro-op” helyett, azt a szerző tudja…), viszont fixed-issue miatt csak függőlegesen kell keresnie. Ez a fixed-issue végigvezet majdnem a teljes CPU-n, kissé VLIW-felépítésre emlékeztetve, meglehetősen leegyszerűsítve sok mindent (decode, execution, retirement…)
Én nem nagyon látom, hogy az Intel-ek egyszerűbb felépítésűek lennének, mint az AMD-k (1 horizontal-vertical vs ’6’ vertical ütemező, egy, 128 bites közös register-file vs két, 64 bites register-file - integer oldalon valós rename nélkül -, RISC vs valamennyire VLIW felépítés). Sőt. A bonyolultabb/nagyobb adatméretű ROB- és RS felépítést az Intel általában az execution unit-ok egyszerűsítésével szokta ellensúlyozni (mint pl. amit említettem, hogy közös ALU van az integer (8-16-32-64 bit), az MMX (64 bit) és az SSEx (128 bit) logikai műveleteknek; vagy annak idején a közös integer-FMUL egység, stb.).
Azt is azért látni kell, hogy a K7-K8-K10 vonal kevesebbet változott az idők folyamán szerkezetileg, mint mondjuk csak a Netburst a Villamette és a Presler között. Erre lehet azt is mondani, hogy mert olyan hatékony, azt is, hogy az AMD-nek nincs annyi feljesztési tőkéje, mint az Intel-nek, de ez már inkább hitvita és szimpátia kérdése, mint szakmai. Az, hogy az AMD miért nem tudja járatni ezt az alapvető felépítést az annak „megfelelő” órajelen (szerintem egy olyan 4 GHz-ig kellene dual-core K10-nek skálázódni, hogy megoldódjanak rövidtávon az AMD problémái), ezt pontosan nem tudjuk, de lehetséges, hogy ennek okát nem a szűk értelemben vett magokon belül kell keresni.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#911
üzenetére
A súlyozást úgy értettem, hogy a hétköznapi használat során előforduló ilyen-olyan feladatok közötti arányt is beleszámítva. És az FSB különbözőségéből eredő eltérést is bele kellene számolni - ha tudnánk, mi mennyire múlik rajta. Vélhetően éppen a jétékok és a médiafeldolgozás során jön ki jobban.
Nos a nagy eltérések miatt nem igazán érdemes ilyen nagyátlagot számolni. Ez a szám az esetek egy részében (átlagos hétköznapi feladatok) erős túlzásnak bizonyul, más esetekben (médiafeldolgozás) meg túl alacsonynak. Tehát érdemes legalább néhány feladat-ketegóriát megkülönböztetni, és csak azokon belül átlagot számolni.
Jó dolog a Radix16-os osztás, azonban eddig kimondottan lassú volt a C2D osztása a K8-hoz képest, úgy tudom. Így valószínű beelőzte, de nem lett 2x gyorsabb a másiknál. (Az AMD egyébként az osztás megfelelő szorzással helyettesítését ajánlja, mert az meg eleve jóval gyorsabb.)
SSE4 vs. SSE4A(?): végülis a táblázatban látható új utasítások jó része olyan utasítások új variációi, amik már az SSE2/3-ban is megvoltak. El tudnád mondani, mire szolgálnak ezek az új variációk? Nekem úgy tűnik, korábban inkább floating-pointosak voltak, ezen újak meg inkább integeresek. Hacsak nem 16 bites integerekkel számolunk, nem lesz feltétlenül gyorsabb a dolog, inkább csak pontosabb (mármint egy 32 bites int v. fixpontos számítás egy 32 bites floating-pointnál). Persze pl. az egy utasításos dot product nem rossz dolog.
ftc: én is el tudom képzelni, hogy az ''SSE4A nagy része'' a Budapestben fog debütálni, hiszen korábban arról szóltak a hírek, hogy az SSE4A-ban majdnem minden benne lesz, ami az SSE4-ben, kivéve pár ''Intel 64''-hez kötődő művelet (bár nem tudom, melyek lennének ez utóbbiak). -
dezz
nagyúr
válasz
#95904256
#906
üzenetére
Az ilyen egyszerű átlagolás értelmetlen. Tessék súlyozni egy kicsit.
Szal nem mindegy, milyen feladatnál mennyi gyorsulásra lehet számítani. Átlagos esetben, azonos órajelen 6-11% (de nyugodtan kerekíthetünk 5-10-re is), 1066-os Core2-höz képest. És lesz pár eset, amikor ennél nagyobb lesz a gyorsulás.
Tényleg csak 4 ''egyszerű'' utasítás az SSE4A? Szép...
(Bár kérdés, mennyit számítanak majd.) Azért ezt meg kell néznem, hogy elhigyjem.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#893
üzenetére
Az FSB különbsége attól még ott van. Persze végülis tök mindegy, milyen tényezők által gyorsabb, azt kell behoznia a K10-nek.
szerk: viszont az teszteredmények többségében látható 20-25%-ból levonva azt a 14%-ot, már csak 6-11% marad, nem 10-20, átlagosan. A 20 kivételes eset.
vedini: Miért lenne ciki? Nem mindenkinek ez a kimondott szakterülete (vagy foglalkozik a témával mérnöki mélységben).
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#877
üzenetére
Köszönöm, nem kevés időt szántál rá.
Nem kapaszkodtam elég erősen.
Először azt hittem, n=1 elírás, de itthon K7-en kipróbáltam, valóban. Sőt, a 3DNow! a kettő hatványaival konzekvensen gondban van, SSE csak 1 esetében. (A példák K7-es eredményei megegyeznek a K8-eredményeiddel. Gondolom, az eltérő első SSE-megvalósítások után fontosabb volt a backward compatibility.)
Igen, meg lehet valósítani, néztem utána a képletet, legfeljebb annyit lehet felhozni ellene, hogy a nagyobb SSE-kód (a 2 menet 2 MOVAPS, 2 MULPS, 1-1 ADDPS és SUBPS, teljes függőségben, ahogy én írtam) csökkenti az ütemezők előrelátási tartományát, illetve az összes 3DNow! DirectPath, a vector SSE-utasítások DirectPath Double-k K8-on. Amúgy nem lehetséges, hogy ezek miatt gyorsabb pár százalékkal a 3DNow!-kód?
alienpapa, VaniliásRönk: én dezz-ék DX10-es beszélgetésére néztem hasonlóan. De gondolom, akosf hsz-e után tisztább a kép.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#826
üzenetére
Tényleg így van. Akkor viszont nem világos a következő:
Az PFRCP egy belső ROM-táblából veszi a közelítő értéket, latency 3 mellett. (''An (on-chip) ROM-based table lookup can be used to quickly produce a 14-to-15-bit precision approximation of 1/b using just one 3-cycle latency PFRCP instruction''). Az RCPSS lappangása 3, RCPPS-é 4 (a 2 db 2x32 bites adategység miatt), ez alapján ezek is lookup-táblából kell vegyék eredményüket. Ekkor viszont három eset lehetséges:
- van egy ROM-tábla az PFRCP-nek és egy külön ROM-tábla az RCPxS utasításoknak, ezek eredménye különbözik, viszont utóbbi ugyanazt adja, mint Intel esetében?
- az, hogy egy közös ROM-tábla van, és PFRCP és RCPxS utasítások eredménye megegyezik, viszont utóbbi nem ugyanazt adja, mint az Intel-nél, nem jöhet számításba, mivel RCPxS hibahatárának az AMD is az említett relative error-t adja meg,hacsak nem
- a két hibamegjelölés ugyanazt a pontosságot takarja?
Tudnál mondani konkrét példaértéket, ahol kijön a különbség? (Itanium esetében az Intel a RCPxS pontosságát már 2^-17 nagyságrendben jelöli meg, de ez nem hiszem, hogy változhatna x86 esetében a jövőben.)
Ha jól értelmezem, akkor K8 esetében precíz, 24 bites a/b értékek kiszámítása PFRCP-PUNPCKLDQ-PFRCPIT1-PFRCPIT2-PFMUL (latency 4-2-4-4-4) sorozattal jóval gyorsabb, mint DIVPS (latency 33) használatával? És ha jól látom, az előbbi minden utasítása fully pipelined, tehát több sorozat is futhat egymás mellett, sorozatonként 2-2 register használatával? (És akkor ez még K10 esetében is áll, hiába fele a DIVPS lappangása, ha nem pipe-olt). Ezt megjegyzem
[Szerkesztve] -
-
P.H.
senior tag
válasz
#95904256
#815
üzenetére
Nem egészen értem, én vagyok az emlegetett 'harmadik fél', vagy ő: [link]
Bevallom, soha nem próbáltam 3DNow!-t, mert nem találtam megfelelő alkalmazási helyzetet (vagy nagy adattömb volt adott, vagy két érték, de akkor legalább 64 bites részértékek kellettek). De nem »hiszem«, hogy lehetséges lenne más eredményt adni 3DNow!-ban, mint SSE-ben és 32 bites FPU-ban, akármelyik platformon.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#805
üzenetére
Ha szó szerint veszem, amit mondasz, ''SSE1-re lenne optimalizálva'' (úgy értem, nem csak két darab 32 bites értékről van szó), akkor nem tűnik gyorsabbnak. Software Optimization Guide for AMD Athlon™ 64 and AMD Opteron™ Processors dokumentáció szerint PFADD reg,reg lappangása 4 (2x32 bit FP), ADDPS reg,reg lappangása 5 (4x32 bit FP), FPMUL/MULPS hasonlóan (SSE-comment mindkettőre: ''The low half of the result is available one cycle earlier than listed''. (Bár ez nem is meglepetés, tekintve, hogy K8-on egyetlen '3Dnow! and SSE dual 32 bit floating point unit'' van, és az SSE1-utasításokat két 2x32 bites egységben futtatja.)
''egy bittel pontosabb is'' Nem hiszem, hogy ezt az IEEE-szabvány megengedné.
[Szerkesztve] -
Raymond
titán
válasz
#95904256
#724
üzenetére
Nemigen megy semmi. Egyre tobb (egymastol fuggetlen) forrasbol hallani hogy eltoljak a Barcelona-t nyar vegere vagy oszre
Szerk.: Peldaul utoljara itt:
''Speaking of AMD, we were originally hoping as many others that Computex 2007 would have been the launch event for Barcelona and Agena. Unfortunately, this will not occur and the best we can hope for at this time is a Barcelona release in the latter part of Q3 at best and Agena following up in late Q4 or possibly sliding to Q1 2008 based on recently received information.''
[link]
[Szerkesztve] -
Raymond
titán
válasz
#95904256
#719
üzenetére
Az L3 inkabb a negymagosoknal lehet fontos a szinkronizacio vegett. Igaz hogy az uj mag ehesebb mit a regi K8, de legfokeppen olyan esetekben ahol stream-elt adatokkal dolgozik. Itt jon a kepbe az atdolgozott memoria vezerlo es a load/store ujitasok. Igy a ketmagosok el lehetnek L3 nelkul.
-
dezz
nagyúr
válasz
#95904256
#691
üzenetére
A Brisbane-os dolgot én sem értem, de a 45nm-eset nem az AMD mondta, hanem én gondolom, illetve elég logikus. Ti. az Intel azzal ''cikizte'' a Barcelonát, hogy egy ekkora chipet nem lehet jó kihozatallal gyártani (és hogy ezért jobb az ő 2x2 magos megoldásuk). Nos, ez nyilván túlzás, viszont 45nm-en lesz igazán gazdaságos a K10 arch. (4 magos esetén).
Ugyanazt a teljesítményt hozza? ;) Elvileg nem. Attól meg szerintem nem lesz bonyolultabb, hogy szélesebbek egyes adatutak, nagyobbak egyes bufferek, stb. A többi meg adott, legalábbis egyelőre.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#625
üzenetére
Hát, lehet, de azért gondolom, hogy az is csinál valamilyen dekódolást, mert abból is vezet egy nyíl a diagramon a Pack Bufferbe, 3 uOP-os szélességgel.
Úgy tudom, egy ideje az önmódosító kód non-allowed a fejlettebb prociknál. (Vagy legalábbis a memóriában kell csinálni egy cache flush után, vagy ilyesmi.) -
dezz
nagyúr
válasz
#95904256
#623
üzenetére
''Szerintem összeszedted az összes olyan különbséget amiért a K10 egy hajszálnyival képes a Core2-re ráverni.''
No azért van ott még jópár más kisebb különbség is. Én itt csak azokat igyekeztem kiemelni, amik az fp teljesítményben is nagyobb szerepet játszanak/játszhatnak.
''Talán a 256 bites I-cache ami egy kicsit talányos. Akárhogy is nézegetem, az a Core2 nagyon eltaláltatott.''
Nyilván, ha egyszer elég szépen elverte a K8-at, anélkül, hogy egy monstrum lenne. Viszont, vélhetően megelégedtek azzal, hogy ''legyorsulja'' a K8-at, nem akartak kapásból minden világrekordot megdönteni (mi marad későbbre? ). FP teljesítményben eleve sokat hozott a végrehajtó egységek 128-bitesítése, de talán nem akartak minden cseppet kisajtolni a dologból. A K10 esetében meg nagyrészt igen (adjunk bele apait-anyait alapon 
-- bár azért ők is hagytak még 1-2 dolgot a K10.5-nek nevezett Shanghainak).
''Amennyire a Core2 eltér a NetBurst-től, a K10 annyira hasonlít a K8-ra. Olyan mint egy nagytestvér. Meglátjuk mi lesz belőle.''
Hmm, szerintem kisebb a különbség.
szerk: ja, közben rájöttem, félreértettelek. Akkor a válasz: hát igen, de a K8 eleve nem volt rossz, csak volt benne pár szűkebb keresztmetszet, amit igyekeztek kiszélesíteni.
''Az FMISC valószínűleg a VectorPath-os FP utasítások miatt ''egyéb'' dolgokat jelöli.
Pl. sinus, cosinus, integer műveletek, ...''
Talán az FDIV-t is ez csinálja, nem az ''FMUL'' egység, amire azért gyakrabban van szükség (bár az opt. guide szerint ajánlatos ahol csak lehet, szorzással helyettesíteni).
''A K8-ból IPC=3,000-t lehetett kicsikarni, nem többet. Egyébként kíváncsi vagyok hogy szerinted hogyan lehet elérni nagyobb értéket.''
Mint ahogy írtam: a 3 alap decoder mellett ott van 4.-ként az a uCode engine, ami látszólag párhuzamosan működik velük, és vélhetően az összetettebb utasításokon dolgozik (3 uOP vs. 1-2 uOP). Már ha jól értelmezem.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#620
üzenetére
Hát, azért csak számít valamit (és nem pedig PR-feature
), hogy a 3x8 elemes általános-kód scheduler mellett külön ott van az a 3x12 elemes fp scheduler, tehát összesen 24+36=60 elem (egy 72 elemes reorder buffer után), miközben Core2-ben egy közös, mindössze 32 elemes scheduler van (igaz, egy 96 elemes reorder buffer után, ha ez számít). Mondjuk egy fullos fp kód-részletnél ez vélhetően nem igazán számít. Viszont ott van a 256 vs. 128 bit I-cache elérés különbsége (ez szerintetek mennyit számít?). Hozzátehetjük még, hogy az AMD-s magok utasítás-dekódolása 3+2+2+2 rendszerű, miközben a Core2 4+1+1+1, azaz az AMD több összetettebb utasítást tud egyszerre kezelni.
szerk: ja, és még valami: K10-nél a 128 bites FADD és FMUL mellett van egy ugyancsak 128 bites FMISC, de ilyet nem látok Core2-nél.
Nem akarsz még kísérletezni a 3 fölötti IPC kihozásával? Elvileg K8-on is el lehet érni 3.0 fölötti értéket.
Raymond: ja, tényleg, köszi.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#559
üzenetére
Egy kicsit elmélyedtem a Core2 micro-architecture-ben, egyáltalán nem érzem rossz döntésnek, hogy az AMD ermékvonalán maradok egyelőre. Ezzel a kóddal elég sok szűk keresztmetszetet megtaláltál, de pont nem azt, amit írsz.
- Igaz, hogy négy decoder van, de csak az első tud több, mint egy micro-opból álló utasításokat fordítani, tehát 4-1-1-1 micro-opre forduló utasításszekcenviák tudják teljesen kihasználni a teljes decode-sávszélességet (...óhh, azok a boldog P2/P3 idők, csak ott még 3-1-1 volt a felállás. Minden OP reg, mem 2 micro-op-ra fordul le (op+load), szóval órajelenként csak egy XORPD reg,mem fordult le egyáltalán. Legalább a trace cache-t megtarthatták volna...
- minden load micro-op a LOAD (port2) exetucion unit-ba kerül, órajelenként egyet tud fogadni. A Data Cache is egy olvasás/órajel szélességű, szóval ha más miatt nem, akkor emiatt is órajelenként egy XORPD reg,mem indulhatna el, egy kapja meg a forrásadatát per cycle. (K8/K10-en 3 AGU van, és a cache 2 load/cycle szélességű). A Data Cache és az core között nincs más ideiglenes tár a Store Buffer-en kívül - az már L0 lenne -, tehát ha még ugyanazt az egyetlen értéket is olvasod be minden utasításnál, akkor is a cache-hez kell fordulni mindig. A Store Buffer meg a store-forwarding-ot tudja segíteni, a kódban viszont nincs store.
A 0.33 utasítás/cycle legfeljebb úgy érhető el, hogy XORPD reg1,reg2 alakokat használsz (úgy, hogy nincsenek függőségek, és reg1 != reg2, mert erre spec. gyorsítás van).
Azt hittem, register-es címzést használsz, XORPD xmm0,xmm1 ugyanakkora méretű, mint az XORPD xmm0,[esi] és a XORPD xmm0,[esi+10h] is csak egy byte-tal nagyobb, +/- 127 byte-os displacement-ig. De pont a 4-1-1-1 felállás miatt itt mindegy, hogy egy 16 byte-os sorba 2, 3 vagy 4 utasítás fér el.
[mod]: Dzsémi, ne rajtam hozzászólás-gyűjtögess!
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#557
üzenetére
Valóban nem figyeltem, hogy OP reg, mem utasításokat használtál, de ekkor nem a Data Cache a szűk keresztmetszet? Hányszor 128 bites az átvitele órajelenként?
A ''4/8 bájtos utasítás'' kifejezéseken mit értesz?
Core/Core2-ról csak nagyon óvatosan merek mondani bármit is, nem ismerem őket eléggé. Tegnap találtam egy nagyon jó dokumentációt róluk, annak áttanulmányozásáig inkább maradok a kérdéseknél velük kapcsolatban. (Most a Raymond által linkelt - köszönet érte - [link] anyagot próbálom összerakni egységes egésszé, picit darabos) . A P2/P3, Netburst és K7 micro-architecture-öket ismerem testközelből alkalmazásprogramozás szinten, mivel (nem klasszikus értelemben, de) irodai programokat készítek, ezekkel találkozom mindenfelé nap, mint nap, és nekem is ezek voltak eddig. A K8-on sem dolgoztam még, de megpróbálok képben lenni vele kapcsolatban. Remélhetőleg a dual K8 konfigom összeáll júniusra, de már ezt direkt úgy terveztem meg, hogy (a lehető legkisebb módosításokkal) K10 fogadására is alkalmas legyen.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#535
üzenetére
A végéről kezdve:
Az AGU-k generálják mindig a címet, legyen az load, store vagy load/store (utóbbi csak x86 integer utasításkészletben van). A betöltött adat rákerül a result bus-ra (a legelső képen nem ábrázolják teljesen, de a load/store queue-ból feletti, belőle kiinduló nyilak megfelelnek neki), innen kerül a megfelelő műveletekhez.
Igen, az ADD reg, mem két micro-opból áll, egy load és egy add. Van még store és load/store micro-op, utóbbi az ADD mem,reg hatékonyságát segíti elő, nem kell a címet kétszer kiszámolni (mint P3-mon, és úgy sejtem, Netburst-on, köszönhetően az Intel teljesen micro-op szintű megközelítésének).
x-utas csoportasszociatív cache: nem a kérelmek számát jelenti, hanem a cache leképezését a fizikai memóriára.
Ha teljesen asszociatív a cache, akkor a fizikai memória bármely területe kerülhet bármely cache-vonalra. Hozzáféréskor viszont keresni kell a teljes cache-ben, nagyon lassú, mert az összes vonalat meg kell vizsgálni.
Ha direct-mapped, akkor a fizikai memória annyi azonos méretű folytonos területre van felosztva, ahány cache-vonal van, és minden területről ugyanarra a cache-vonalra kerül az adat. Nagyon gyors, nem kell keresni, de nem hatékony, gondolom, nem kell mondanom, miért.
x-utas csoportasszociatív cache: a kettő keveréke. Adott fizikai cím a cache meghatározott x számú vonalának egyikén lehet, csak ezek között kell keresni. Ez általában a fizikai cím legfelső x bit-jének elfelejtésével generálják, ezért a folyamatos memóriaterületek hozzáférése is hatékony marad.
Raymond: köszönöm, akad itt egy-két egység belőle.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#530
üzenetére
Téged is megzavart, hogy magát a CPU-t és az execution unit-okat is pipe-nak nevezik (én is, de az össes dokumentácó ilyen). Megpróbálom leírni röviden az K7-en levezetve a microarchitecure-t. K7-en, mert alapvetően alig tér el a K8 és a K10-től, és ehhez nagyon részletes dokumentációt adott ki az AMD.
![[kép]](http://kepfeltoltes.hu/070510/K7arch_www.kepfeltoltes.hu_.jpg "[kép]")
Maga a teljes CPU egy pipeline, csak 3-way superscalar miatt órajelenként max. 3 ottani adategység léphet tovább a következő stage-re (minden ábrán minden szint között legalább 3 nyíl megy függőlegesen). A lépések, órajelenkénti bontásban:![[kép]](http://kepfeltoltes.hu/070510/K7decode_www.kepfeltoltes.hu_.jpg "[kép]")
cycle 1. FETCH: kiszámolja a következő utasításablak címét (+branch prediction, CALLs, RETs, ...), amit az L1-ből vagy a memóriából be kell tölteni.
cycle 2. SCAN: meghatározza az egyes utasítások elejét és végét, majd vagy a DirectPath-ra (legfejlebb 6 utasítás/órajel) és VectorPath-ra továbbítja őket (legfejlebb 1 utasátás/órajel).
cycle 3. ALIGN1 (DirectPath): 8-byte-os sorokban kapja az utasításokat, minden sorban legfejlebb 3 utasítás lehet (ekkor még minden 1 byte-os x86 utasítás VectorPath-ra került), 9 ilyen sort pufferel. Minden órajelben legfejlebb 3 utasítást megpróbál továbbítani az ALIGN2-be.
cycle 3. MECTL (VectorPath): a kapott VectorPath-utasításhoz meghatározza a microcode-ROM belépési címét.
cycle 4. ALIGN2 (DirectPath): prefix-ek, az opcode-, ModR/M- és SIB-byte-ok megkeresése, és ezen információk továbbítása.
cycle 4. MEROM (VectorPath): a microcode-ROM-ot megnyitja (indexeli, nem is tudom, hogy mondjam) az adott belépési pontnál.
cycle 5. EDEC (DirectPath): az ALIGN2-ből és a MEROM lépcsőtől kapott infomációk alapján macro-opokká dekódolja az utasításokat. Ezenkívül meghatározza az azonnal argumentumokat, register-pointereket és eltolásokat.
cycle 5. MEDEC/MESEQ: közvetlenül a microcode-ROM-ból jönnek a macro-opok (ezek saját különálló belső register-csoporton dolgoznak)
cycle 6. IDEC/Rename: a macro-opok elosztódnak a két ütemező között. Az összes macro-opnak, ami az FPU-egységbe kerül, a register-argumentumai leképeződnek a belső registerfile egy-egy elemére (itt fordul át pl. az 'XMM1' vagy 'MM6' a megfelelő sorszámú belső register sorszámára - 88- vagy 120-entry register file).
Innen az összes macro-op a Instruction Control Unit-ba (ICU) kerül. Innentől a pipe egy hurok, tehát tovább innen indulnak a macro-opok, és itt is fejezik be pályafutásukat (visszavonulás/retirement), vagy az machine state-nek (register-ek, flags, ...) eredményük szerinti felújításával, vagy kiléptetéssel (mert téves elágazási ágjóslat volt), illetve itt váltódnak ki a kivételek is. Ez osztja el a macro-opokat az integer és a FPU-egységek felé.![[kép]](http://kepfeltoltes.hu/070510/K7int_www.kepfeltoltes.hu_.jpg "[kép]")
Az integer egység:
cycle 7. SHED: az integer ütemező, itt várják meg a macro-opok, hogy megérkezzen az összes input adatuk. (És AMD-nél valóban megvárják, nem úgy, mint Netburst alatt.) Közvetlen kapcsolata van a result bus-sal, így az input adatok nem a véglegesített machine state-ből jönnek, hanem rögtön a kiszámolás után. Innentől az elemi egységek a macro-opok helyett micro-opok, ezekből egyszerre legfejlebb 6 léphet tovább órajelenként, 3-3 az ALU-kba és az AGU-kba.
cycle 8. EXEC: a micro-opok végrehajtódnak, az eredményüket kiteszik a result bus-ra. Ha egy macro-opban levő minden micro-op lefutott, akkor az ICU elindítja a visszavonulási (retirement) folyamatot.
cycle 9. ADDGEN, cycle 10. DCACC, cycle 11. RESP: address generation (effektív -> lineáris cím konverzió, az effekív címet számolják az AGU-k), Data Cache access, Response, load/store kapcsolat a Data Cache-sel.![[kép]](http://kepfeltoltes.hu/070510/K7float_www.kepfeltoltes.hu_.jpg "[kép]")
Az FPU-egység sokkal ''érdekesebb'':
cycle 7. STKREN: stack rename órajelenként legfeljebb 3 macro-opot fogad az ICU-ból, valamint x87 utasításoknál az ST(x) alakú stack-relatív formát fordítja a megfelelő sorszámú belső register sorszámára (88- vagy 120-entry register file)
cycle 8. REGREN: register-átnevezés. Minden művelet eredménye fizikailag más register-be íródik (tehát az ADDSS xmm0,xmm2 formában a bemeneti értékek mondjuk az fp15 és fp54 fizikai register-ek, de az eremény NEM az fp15-be fog íródni, hanem egy másik register-be.
cycle 9. SCHEDW: sheduler write, akkor íródnak a macro-opok az ütemező pufferébe, órajelenként 3.
cycle 10. SHED: maga az ütemező. Innentől megint a micro-op az elemi egység. Az ütemező folyamatosan scan-neli a puffer-ét, legfejlebb 3 olyan micro-opot keresve, amiknek már nem kell várniuk a bemeneti értékeikre, hogy továbbítsa ezeket az EXECUTION UNIT-ok felé. Minden micro-op csak bizonyos unit-ban indulhat el, néhány micro-op csak ''bizonyos időben'', mind a háromra keres egy-egy ezeknek megfelelőt. Azok még a következő órajelben a cycle 11. FREG stage-ben a register-ekből kiolvassák a bemeneti értékeiket (minden unit saját, belső register-eivel dolgozik, nem közvetlenül a register-file-ba), majd elindul a futtatásuk.
És ezek az execution unit-ok az FADD, FMUL és az FSTORE/FMISC. Órajelenként egy micro-opot tudnak fogadni, az ábrán megnézve a CPU 15 stage-es pipe-ja itt (megint, mint ahogy a két ütemező felé, vagy a 3 ALU/AGU esetében) elágazik, az FEXEC1-FEXEC4 az 12., 13., 14. és 15. stage-ek vertikálisan, de ezek 3 különálló pipe különböző szintjei. Valójában nem is három, mert egy-egy unit megintcsak többfelé ágazik, csak a port közös bennük. Ráadásul ezeknek az ágaknak nem is mindegyike teljesen pipe-olt (pl. az osztó), és nem is egyforma hosszúak (az MMX ALU csak 2 lépcsős, FEXEC12 és FEXEC 13 szintje van csak), de a leghosszabb ág is csak négy stage hosszú.
az FADD alágai: 3DNow!/SSE adder, MMX ALU/shifter, FP adder
az FMUL alágai: 3DNow!/MMX multiplier/reciprocal, MMX ALU, FP multiplier/divider/square root (ez utóbbi úgy pipe-olt, hogy négy lépcső hosszú, de az egyik lépcsőben mondjuk 30 órajelig marad az micro-op számolás közben).
Említettem, hogy a portok órajelenként tudnak egy micro-opot fogadni, viszont az alágak nem törvényszerűen. Ezért szokták megadni utasításszinten a latency mellett a throughput-ot mint legfontosabb adatot, azaz, hogy ugyanaz az ALÁG hány órajelenként tud új utasítást fogadni. Ha az alág pipe-olt, akkor órajelenként egyet, de ha nem, akkor meg kell várni majdnem a teljes lefutást. Például az lappangása K8-on DIVPD 37 órajel, és a következő DIVPD 34 órajel múlva indulhat el. Viszont ezen 34 órajel alatt az FMUL egység vígan tud fogadni és lefuttatni 34 szorzó micro-opot.
A másik lényeges dolog ezeknek az egységeknek a szélessége. Ha K8-ról beszélünk, akkor ott egy 64 bites összeadó van az FADD egyégben, ezért egy ADDPD macro-opja két összeadó micro-opot fog tartalmazni, ezek egymás utáni órajelekben lépnek be az FADD potján, egymás után mennek a pipe-stage-eken, a második 1 órajellel később fejeződik be, ezért programozói szinten ADDPD utasítás lappangása 5, átvitele 2. Tegyünk mellé még egy 64 bites összeadót, ekkor az ADDPD-hez csak egy micro-op kell, nem gyorsítunk semmit magukon az elemi összeadókon, és máris az ADDPD lappangása 4, átvitele 1 lesz.
Remélem, így már tisztább.
[Szerkesztve] -
Raymond
titán
válasz
#95904256
#530
üzenetére
''There are separate units for integer multiplication and floating point multiplication. The
integer multiplier on port 1 is fully pipelined with a latency of 3 and a throughput of 1 full
vector operation per clock cycle. The floating point multiplier on port 0 has a latency of 4 for
single precision and 5 for double and long double precision. The throughput of the floating
point multiplier is 1 operation per clock cycle, except for long double precision. The floating
point adder is connected to port 1. It has a latency of 3 and is fully pipelined.
Integer division uses the floating point division unit. This is the only unit that is not pipelined.''
Ebbol van: [link]
Ezekn kivul van meg ket erdekes az oldalon:
[link]
[link]
Mindegyik 2007-es update ugyhogy nem valami regi cuccok. Ami kicsit azert zavar az az hogy minden Core-rol szolo cikk kicsit mashogy irja le a belso architekturat. Apro de lenyeges kulombsegek. Pl. a portok felosztasan valahogy nem tudnak megegyezni -
#95904256
törölt tag
válasz
#95904256
#525
üzenetére
Core2:
ADDPD reg0-7,mem -> 1,1 órajel / utasítás
DIVPD reg0-7,mem -> 31,1 órajel / utasítás
MULPD reg0-7,mem -> 1,1 órajel / utasítás
XORPD reg0-7,mem -> 1,1 órajel / utasítás
SQRTPD reg0-7,mem -> 57,2 órajel / utasítás
K8:
ADDPD reg0-7,mem -> 2,1 órajel / utasítás -> 2 db 64 bites összeadó (FADD,FMISC?)
DIVPD reg0-7,mem -> 34,1 órajel / utasítás -> 1 db 64 bites osztó (FMISC)
MULPD reg0-7,mem -> 2,1 órajel / utasítás -> 2 db 64 bites szorzó (FMUL,FMISC?)
XORPD reg0-7,mem -> 2,1 órajel / utasítás -> 2 db 64 bites logika (ALU)
SQRTPD reg0-7,mem -> 48,1 órajel / utasítás -> 1 db 64 bites gyökvonó (FMISC)
Szóval a K8 is veri a Core2-t, gyökvonásban. -
P.H.
senior tag
válasz
#95904256
#525
üzenetére
Tökéletes pipe-olt futtatási eredmény. 1-1 2x64 bites adder (ADDPD), szorzó (MULPD) dolgozik. Minden órajelben egy utasítás indul folyamatosan, a 3. vagy 5. órajel után minden órajelben egy vonul vissza, tehát az egész 100000+2 és 100000+4 órajel alatt fut le elméletileg.
A DIVPD és SQRTPD nem pipe-olt.
Az XORPD-t nem értem inkább. Nem 2 vagy 3 SSE ALU van a Core2-ben? 2 esetén már 0.5 órajel/utasításnak kellett volna kijönni.
''Gondolom az 1,1 órajelből az 0,1 azért jött be mert nem volt egy 9. regiszter a további latency time átlapoláshoz.''
Nem, a register-rename működik, minden utasítás eredményének új register-be kell kerülnie, a programozói register-készlet nem szűk keresztmetszet.
[Szerkesztve]
(remélem a teljesítményre nem lesz panasz!!?)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
(Bár kérdés, mennyit számítanak majd.) Azért ezt meg kell néznem, hogy elhigyjem.
![[kép]](http://www.xbitlabs.com/images/cpu/intel-v8/multitasking.png "[kép]")
Új hozzászólás Aktív témák
Hirdetés
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.
- Azonnali VGA-s kérdések órája
- Víz- gáz- és fűtésszerelés
- Ismét a Honoré a legvékonyabb hajlítható
- Luck Dragon: Asszociációs játék. :)
- Mibe tegyem a megtakarításaimat?
- Xiaomi 13 - felnőni nehéz
- Battlefield 7
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- iPhone topik
- Hobby elektronika
- További aktív témák...
- 135 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4090 (ELKELT)
- Bomba ár! HP Elitebook 8570W - i7-QM I 16GB I 750GB I 15,6" HD+/FHD I Nvidia I W10 I Garancia
- Telefon felvásárlás!! Apple iPhone SE (2016), Apple iPhone SE2 (2020), Apple iPhone SE3 (2022)
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- BESZÁMÍTÁS! ASUS VivoBook X1504ZA notebook - i3 1215U 16GB DDR4 RAM 512GB SSD Intel UHD IGP WIN11
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest