- Fotók, videók mobillal
- MIUI / HyperOS topik
- 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
- iPhone topik
Hirdetés
-
Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
gp Továbbra is szeptemberi premierrel számolnak a fejlesztők, reméljük több halasztásra már nem kell számítanunk.
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
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
-
Raymond
félisten
válasz
#95904256
#440
üzenetére
''Ez versenyben van a Core2-vel.''
Azt hiszem valos alkalmazasokban le fogja korozni a C2D-t.
[link]
A C2-nek 3 darab egyciklusos 128bit-es SSE egysege van a K10-nek csak 2 de a C2-nel a frontend a szuk keresztmetszet igy eleg nehez neki orajelenkent 3 utasitasal ellatni az egysegeket. Ezert is nem alazza jobban a K8-at sem azonos orajelen. Az egyetlen teszt ahol tenyleg komolyan megmutatkozik hogy ott vannak azok az SSE egysegek a Sandra fraktal tesztje. Meg a durvan SSE-re optimalizalt render programoknal sincs akkora elonye a K8-hoz kepest mint amilyenre az ember szamitana csak az feldolgozo egysegek osszehasonlitasaval.
A linkelt abran nagyon latszik mennyire sovanyka a P4 a C2-hoz kepest
[Szerkesztve]Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
-
dezz
nagyúr
válasz
#95904256
#465
üzenetére
Nem tudom, én csak Rajmond hozzászólása alapján mondtam.
(Az ugyancsak Rajmond által linkelt (#445) mag-részegység azonosítási képek, és P.H. #437-es hsz-ének alsó részén írottak alapján itt már nincs is olyan, hogy külön FPU egyég, hanem ugyanazokat az egyégeket használják, sőt ugyanarra a micro-op-ra fordítódik át.) -
Raymond
félisten
válasz
#95904256
#469
üzenetére
Tul fogom elni
Persze hogy ott vannak 64bit-es Windows alatt, a 32bit-es alkalmazasok hogy mukodnenek nelkuluk? A nativ 64bit-es alkalmazasokrol volt szo, ahol teljesen le akartak tiltani a hasznalatot. Az igazsag az hogy az egeszbol annyi maradt a vegere hogy kernel mode kodban tilos a hasznalata es mindenki (MS, AMD, Intel) evek ota lebeszeli a embereket a hasznalatukor es az SSE fele nyomjak oket.Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
válasz
#95904256
#473
üzenetére
Nem kell egyelore eloasnod
[link]
Itt a kernel mode info. Az egesz tiltasbol mara ennyi maradt. Az MS OS es VS megjeleneseig nyitott maradt hogy mi lesz a helyzet. Linux alatt nincs es nem is volt semmilyen lekotes. Ez csak az MS jateka volt. De az AMD64 (IA64) hasznalatanal az AMD es az Intel ajanlasa most is az SSE hasznalata. Egy pelda: [link]Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
válasz
#95904256
#476
üzenetére
K8 vs. Core2 SSE = 2x64bit vs. 3x128bit (2 symetrical) exec unit.
A Core2 a foldbe dongoli a K8-at (foled 128bit) SSE teren.
Elnezest hogy Anandtech-et linkelek, de itt egy oldalon szepen attekinthetoen vannak az abrak: [link]Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
válasz
#95904256
#478
üzenetére
''Tehát nem értem hogy miért hoztad fel hogy az eredmény az exec unitok száma miatt jött ki.''
Szama es tipusa. Van kulombseg a 64bit es a128bit teszteredmenyeid kozott?
''Tévedtem, az átlapolás nem úgy működik ahogy azt eddig gondoltam.''
Es mire jutottal?
Egyebkent kulon orommel tolt el hogy nem a ''CL2 DDR900-on'', ''az en tulhajtott konroom szetszedi a K10-et'' es hasonlo stilusu hsz-ek vannak itt az utolso par napbanPrivat velemeny - keretik nem megkovezni...
-
#95904256
törölt tag
válasz
#95904256
#490
üzenetére
Eddig ennyit sikerült találnom:
The Core microarchitecture also substantially improves on the floating point and SSE capabilities of its predecessors. Although Core’s 3 SSE units are not fully symmetric, the differences are relatively minor (shifting and multiplication resources).
Vagyis majdnem minden a három azonos. -
Raymond
félisten
válasz
#95904256
#491
üzenetére
A harom SSE egysegbol csak ketto vegez ''komoly'' munkat. A harmadik nem. Ezt a teszt eredmenyek is alatamasztjak amik tiszta SSE teljesitmenyre mennek ki. Pl. a Sandra fraktal test. Ugyanazon az orajelen DP-ben kb. ketszer, SP-ben pedig kb. negyszer gyorsabb egy Core2 proci mint egy A64 X2 ugyanazon az orajelen. Keresek valami linket is.
Privat velemeny - keretik nem megkovezni...
-
P.H.
senior tag
válasz
#95904256
#506
üzenetére
Arra tudnál (közelítő) értéket mondani, hogy mennyivel lassul? Nem teljesen titsza, hogy a fenti idézett mondatot hogyan kell értelmezni.
És ha nem áll le teljesen, akkor főleg az nem tiszta, hogy milyen jellegű microcode fut változó ciklushosszú VectorPath esetében.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
-
-
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]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
#95904256
törölt tag
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. -
Raymond
félisten
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 megegyezniPrivat velemeny - keretik nem megkovezni...
-
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]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
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]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
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]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
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]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
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] -
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
#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
#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] -
Raymond
félisten
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.
Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
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]Privat velemeny - keretik nem megkovezni...
-
#804
VaniliásRönk
nagyúr
#95904256
#803
VaniliásRönk
nagyúr
válasz
#95904256
#803
üzenetére
Valóban, viszont nem pusztult volna ki a 3DNow!, és az Intel most is csak pislogna az x64-re... persze akkor lehet máshogy alakultak volna a dolgok, kár ezen filózni.
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
-
#807
VaniliásRönk
nagyúr
#95904256
#805
VaniliásRönk
nagyúr
válasz
#95904256
#805
üzenetére
Ezt én is így hallottam, csakhogy mivel az AMD CPU-i is támogatják az SSE-t, mindent arra írnak, 2000 környékén láttam 1-2 3DNow! logós programot utoljára.
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
-
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]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
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]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
Raymond
félisten
válasz
#95904256
#836
üzenetére
Nincs osszefuggesben. A core es az IMC feszultseg ellatasa eleve szet vont valasztva. Arrol van csak szo hogy valami bug visszafogta a chipet es nem lehetett elerni a tervezett orajelet. Megtalaltak, javitottak rajta es most 500-al magasabb a max.
Privat velemeny - keretik nem megkovezni...
-
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]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
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]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
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] -
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
#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). -
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]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
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
#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]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
), 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.
![[kép]](http://www.xbitlabs.com/images/cpu/intel-v8/multitasking.png "[kép]")
Ú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.
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Hosszú idő után újabb előzetest kapott a Gothic Remake
- Xbox tulajok OFF topicja
- exHWSW - Értünk mindenhez IS
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- Hivatalosan is bemutatkozott a Kingdom Come Deliverance 2
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Rövid teaser trailert kapott a Dragon Age: Dreadwolf
- Fotók, videók mobillal
- További aktív témák...
- Újszerű - INTEL Core i5-14600KF 14mag 20 szál 5.3GHz CPU - bolti garanciával
- Beszámítás! Intel Core i7 6700K 4 mag 8 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
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Garanciális Intel Core i5-13600K