-
PROHARDVER!
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
#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] -
-
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] -
-
#95904256
törölt tag
Mivel jómagam nem szoktam videokódolást csinálni, ezért kíváncsiságból elővettem az egyik Prohardver!-es tesztet hogy megnézzem mennyivel is marad el a Core2 az előző arhitektúrára való duplázástól. [link]
Nos itt ilyesmi áll hogy:
MainConcept AVI -> MPEG2
C2D E6300 1866MHz: 119s
PD 925 3000MHz: 140s
Órajellel arányos gyorsulás: 1,89
Windows Media Encoder 9 MPEG2 -> WMV
C2D E6300 1866MHz: 104s
PD 925 3000MHz: 124s
Órajellel arányos gyorsulás: 1,92
Auto Gordian Knot... MPEG2 -> AVI
C2D E6300 1866MHz: 142s
PD 925 3000MHz: 177s
Órajellel arányos gyorsulás: 2,00
XMpeg v5.03 ... MPEG2 -> AVI
C2D E6300 1866MHz: 89s
PD 925 3000MHz: 108s
Órajellel arányos gyorsulás: 1,95
Ezek alapján valóban nem éri el a kétszeres sebességet, de azért nincs messze.
Ráadásul kétséges hogy ezek a programok C2D optimalizált kódot futtattak.
Valamint ne felejtsük hogy ezeket az eredményeket más is korlátozta (pl:memória).
Szerk.: Tehát ez a 128 bites SSE / 64 bites adatút nem duplázott dolog cáfolva.
[Szerkesztve] -
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] -
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]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
Hihi, akosf megtalálta a legjobb számokat.
C2D@~3GHz (FSB 1700) vs. P-D@3GHz (FSB 800): 1,79...1.92 - C2D@1866MHz (FSB 1066) vs. P-D@3,9GHz (FSB 1040): 1,8...1,95.
Amúgy, hát igen, a Core Duo-hoz kellene hasonlítani.
(#1109) akosf: ''A linkelt tesztben az L2 a Pentium-D-ben és Core2-ben is 2-2 MB magonként.''
De az utóbbiban közösített, ami egy kétszálas kódolásnál számíthat.
''Ezt a P-D 2x-es gyorsulás P4-hez dolog, ezt hogy kell értenem? Ezt senki nem állította. Arról volt szó hogy a 128 bites SSE hozott-e kétszeres gyorsulást vagy sem.''
Azért hoztam fel, mert ugye magonként kellene hasonlítani, azonban a P-D nem 2x gyorsabb, mint a megegyező órajelű P4, így talán a C2D-nek nem nehéz jóval gyorsabbnak lennie, pl. a közösített L2 és FSB által, kétszálas alkalmazásban...
[Szerkesztve] -
-
Raymond
félisten
''Azért hoztam fel, mert ugye magonként kellene hasonlítani, azonban a P-D nem 2x gyorsabb, mint a megegyező órajelű P4,''
Nem is lehet, mert a P4 HT-vel, a PD pedig anelkul volt merve. Igy nem egy mag versus ket mag a teszt hanem 1+ versus 2.Privat velemeny - keretik nem megkovezni...
-
#95904256
törölt tag
válasz
Raymond
#1113
üzenetére
Szerintem az E4300-asom is megfelel. Ha gondolod, írhatok egy kis programocskát amely meghajtja a 128 bites SSE engine-t és kiírja a futáshoz szükséges órajelek számát a képernyőre. Ez jóval pontosabb eredményt szolgáltat mint a videokódolás, ugyanis az még jelentősen függhet más dolgoktól is ( FSB, RAM, cache méret, ... ).
Sőt, ha ez a ciklusmag megfelel:
cycle:
addps xmm0,[esi+00h]
addps xmm1,[esi+10h]
addps xmm2,[esi+20h]
addps xmm3,[esi+30h]
dec ebp
addps xmm4,[esi+40h]
addps xmm5,[esi+50h]
addps xmm6,[esi+60h]
addps xmm7,[esi+70h]
jnz cycle
Akkor letöltheted innen: [link]
Ez 125 milliószor futtatja le a fenti ciklusmagot, vagyis 1 milliárd 128 bites SSE összeadást végez. Az eredmény a végrehajtáshoz szükséges órajelek száma.
E4300/Win2000: 1.000.792.422 -
#95904256
törölt tag
akosf: ''A linkelt tesztben az L2 a Pentium-D-ben és Core2-ben is 2-2 MB magonként.''
dezz: De az utóbbiban közösített, ami egy kétszálas kódolásnál számíthat.
Ez elvileg lehetséges!
Jó lenne látni egy tesztet, erre a megosztott cache-s dologra...
Itt a Prohardveres! tesztben használt programoknál azonban kétséges hogy a Pentium-D illetve Core2-őn futtatva más-más kód futott volna. Valószínűleg épp azért futtaták ugyanazt a programot hogy összehasonlítható eredményeket kapjanak. A megosztott cache használatra egyébként kikell okosítani a programokat, ezt az oprendszer nem képes automatikusan lekezelni. Ez nem egyszerű feladat. Másfelől videokódolásnál nagyon nem is látom túl nagy hasznát, ugyanis itt folyamatosan változik a bemenő adat. Ennek a megosztott cache-nek akkor lehet jelentős szerepe ha pl. egy méretes Look-Up Táblát (LUT) használ az ember. Szerintem... -
Raymond
félisten
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]Privat velemeny - keretik nem megkovezni...
-
#95904256
törölt tag
válasz
Raymond
#1117
üzenetére
Oh, elnézést, másféle cache megosztásra gondoltam.
Arra gondoltam hogy a két szál egyszerre dolgozik ugyanazokkal az adatokkal ugyanarról az adatterületről. A C2D hardveres cache megosztásnak a videokódolás szempontjából még kevesebb jelentősége van, ugyanis ebben az esetben mindkét mag teljes gőzzel dolgozik, így nem nagyon tud egyik szál sem profitálni abból hogy a másik mag kevésbé használja a cache-t... -
dezz
nagyúr
válasz
Raymond
#1117
üzenetére
''mivel stream-elt adatok feldolgozasarol van szo''
Azért arra is gondoljunk, hogy nem csak pl. összeadni kell itt a számokat, és már lehet is kiírni, hanem blokkonként elég bonyolult műveleteket kell végezni. Tehát a blokk rel. sokáig a cache-ben lehet.
A megosztással/közösítéssel kapcsolatban arra gondoltam, hogy talán adatok is utazhatnak a L2-n keresztül a két mag között. (Nem tudom, a C2D tud-e egyátalán ilyet.) Az persze nem valószínű, hogy már tavaly így optimizált kodekek lettek volna, de szándékosság nélkül is kijöhet ilyen helyzet. -
#95904256
törölt tag
Ez az L2-n keresztüli adat utaztatás csak úgy működik ha az egyik szál számára lefoglalsz egy adatterületet az OS-től, majd elérhetővé teszed ezt a területet a másik magon futó szál számára is. Ekkor egy memóriacímről olvashat a két szál. Ha szerencséd van, akkor ez a memóriaterület az L2-be is bekerül...
-
Raymond
félisten
Hidd el lenyegtelen. Akkora bemeno es kimeno adatmennyiseggel dolgozol hogy a cache nem jatszik szerepet. A videokodolas a stream processing egyik legregebben mainstreamesitett peldaja. De hogy ne csak beszeljek rola: [link] 4MB->1MB L2 csokkenes alig hoz valtozast.
Privat velemeny - keretik nem megkovezni...
-
-
-
dezz
nagyúr
Én is mértem egyet, csak úgy poénból: s.754 Sempron (E6) 2800+@2.2GHz: 2.018.005.391
Futtattam úgy is, hogy közben néztem a PerfMonitorral (ismeritek?), 0.6-nak írta az IPC-t. Gondolom, ezen lehetne javítani, jobban dolgoztatva az említett részeket.
Ja, A64-es megjegyzésre: ja, látom, ha más is fut, akár ''passzívan'', az eléggé befolyásolja az eredményt. Azért nem egészen tökéletes a WinXP multitaskja.
[Szerkesztve] -
Raymond
félisten
''Ja, A64-es megjegyzésre: ja, látom, ha más is fut, akár ''passzívan'', az eléggé befolyásolja az eredményt. Azért nem egészen tökéletes a WinXP multitaskja.''
Masrol lehet szo, mert a PM-es gepen semmi nincs a Win-en kivul. A PD-s eredmenyeken pedig latszik hogy OS-tol nem fugg a dolog. Tobbszor futtattam a programot egy kornyezetben es az elteresek csak nagyon kicsik voltak a futasok kozt.Privat velemeny - keretik nem megkovezni...
-
#95904256
törölt tag
A PerfMonitorral méret IPC=0.6 jó értéknek tűnik. Elméletileg IPC=0.5 a maximumum az E6-os Sempronon, hisz a 128 bites SSE összeadás műveleteket 2 egymást követő 64 bites összead-s műveletként futtatja, és ebből egyszere egy órajelre csak egyet tud indítani. Az IPC=0.5 feletti érték azért jött ki mert van ott a ciklusmagban két integer utasítás is, a ciklusszervezés miatt. A PerfMonitor minden bizonnyal ezt is belemérte.
Elvileg 2.000.000.000 órajel szükséges hogy 64 bites SSE enginnel lefusson a kód. A többi órajel többmindenből adódik össze, egyrész az TimeStampCountert kezelő programrészlet illetve az első ciklusban az adatok cache-be tárolása igényel néhány száz órajelet. A többi a megszakításokból és az azokat lekezelő windows rutinok futásidejéből adódik.
Természetesen lehet olyan kódot is írni ami a fetch/dekóder részt is leterheli, de itt most arról volt szó hogy a 128 bites SSE engine-t valóban megfojtja-e az adatutak szűkössége vagy sem. Egyébként a fetch/dekóder részt szerintem meglehet fojtani hosszú SSE(2) utasításokkal, de ekkor még lazábban fogja tenni az SSE műveletvégző a dolgát, vagyis épp az ellenkezőjét érjük el mint amit szerettünk volna... -
-
-
P.H.
senior tag
Ahogy mondod. Nem ingatta meg azon hitemet, hogy teljesen független utasítások esetén (akosf kódja 8 SSE-utasítás, max. 5 latency mellett, tehát abszolút in-order ütemezés, egy execution unit-ra) kétszeres a növekedés, (by throughput), teljesen függőség esetén legfeljebb 25% (by latency).
Akosf: cseréld ki az összes célregister-t xmm0-ra, így láthatjuk, lesz-e 25%-os növekedés.
Az user-kódok valahol a kettő között vannak. Hétvégén kiollózok egy ilyen '''user-kódot'' (lesz benne egy 3+1 szálas JPEG_decode_to_YUV + YUV->32bitBMP + stretch_to_screen - a'la Irfanview, csak lassabb és jobb eredményt ad - 4x4MB-os pufferekkel kommunikálva (csak SSE), egy amúgy is ''állatorvosi ló'' (SSE2, SSE és x87 implementációval) és egy brute-force (SSE2 és x87), ha lesztek partnerek, meglátjuk az eredményt ott is.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
-
#95904256
törölt tag
Na, kicseréltem az összes helyen a célregisztert xmm0-ra. Várható hogy ez esetben az SSE egység pipe-jai majdnem hogy üresek lesznek, hisz mindegyik utasítás kénytelen megvárni az előzőt. Elvileg ha a 64 bites rendszerek képesek arra hogy az 1 órajellel előbb rendelkezésre alló 64 bites adattal rögtön műveletet indítsanak, akkor 0% (1 órajel) különbséget kellene tudni kimérni.
Megjegyezném hogy a Core2Duo az SSE összeadást 3 órajel alatt hajtva végre, így felreaktam egy MULPS és egy MULPD verziót is, ugyanis ez eleve 25% előnyt adna a Core2-nek.
ADDPS (C2D 3 órajel):[link] E4300: 3.000.808.746
MULPS (C2D 4 órajel):[link] E4300: 4.001.011.497
MULPD (C2D 5 órajel):[link] E4300: 5.004.196.407
[Szerkesztve] -
Raymond
félisten
válasz
#95904256
#1138
üzenetére
PD930 WXP32bit:
ADDPS 7.101.775.640
MULPS 7.008.616.718
MULPD 7.007.502.285
Egyebkent az ADDPS-nel (SSEADDTEST2.ZIP) az eredmenybol hianyzik egy szam, ezert tettem egy nullat a vegere. Gondoltam nem futott le 700 millio ciklus alattPrivat velemeny - keretik nem megkovezni...
-
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] -
#95904256
törölt tag
válasz
Raymond
#1139
üzenetére
Más a baj. A MULPS és MULPD tesztek 35 bites eredményt írnak ki, míg az ADDPS csak 32 bitest. Túlcsordulásos hiba a programban. Erre még reggel rájöttem, ki is javítottam, de úgy tűnik mégis rossz kódot töltöttem fel a szerverre. Bocs..
A pontos eredményt úgy kapod meg hogy X=N+4.294.967.296.
Vagyis PD930 WXP32bit ADDPS: 5.005.144.860.
Amint hazaértem feltöltöm a javított fájlt. -
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]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Ha így nézzük tovább, akkor 3->2 33%, 2->1 50%, pedig utóbbi esetben azonos idő alatt kétszer annyi utasítás fut le. De soha nem voltam erős matekból.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
-
Raymond
félisten
válasz
#95904256
#1149
üzenetére
No problem
Itt az elsonel (PM) eleg sok marhasag fut a hatterben, de a lenyeg latszik.
PM750 WXP32bit
ADDPS 3.505.824.405
MULPS 4.560.721.958
MULPD 5.682.555.488
AXP@2083Mhz WXP32bit
ADDPS 4.029.464.198
MULPS 4.024.577.784
MULPD Error
[Szerkesztve]Privat velemeny - keretik nem megkovezni...
C2D@~3GHz (FSB 1700) vs. P-D@3GHz (FSB 800): 1,79...1.92 - C2D@1866MHz (FSB 1066) vs. P-D@3,9GHz (FSB 1040): 1,8...1,95.
Ú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.
Állásajánlatok
Cég: HC Pointer Kft.
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest