Új hozzászólás Aktív témák
-
#356
hugo chávez
aktív tag
dezz
#355
hugo chávez
aktív tag
Hehe, szép, nagyon szép
Az Intelnek nagyon fel kell kötnie a gatyáját, ha az Ivy IGP-jével meg szeretné közelíteni ezeket az eredményeket.Ja, még visszatérve kicsit a Sandy-khez, azért az sem rossz, hogy a 600$-os Xeon E3-1280 (és a 300$-os i7 2600) lebegőpontos teljesítményben elpicsázza a Xeon vonal csúcsán lévő 4600$-os, 10 magos E7-8870-et
-
-
#354
Coccer
tag
hugo chávez
#352
Coccer
tag
válasz
hugo chávez
#352
üzenetére
Egyetértek, legyen kicsi, könnyű, erős (GPU is) és sokáig bírja. Remélem hamarosan valóra válik ez is...
-
dezz
nagyúr
Erm, bocs, hogy mindezt így "leírattam" veled, ráadásul nagyrészt feleslegesen, mert azért valamennyire tisztában vagyok vele, csak tegnap-tegnapelőtt este 11 után már kicsit fáradt voltam.
Igen, igazad van, a 2 mat. művelet + 1 loaddal nincs gond.Ugyanez viszont már nem mondható el a store-ról. Bár azok általában ritkásabban vannak a kódokban. De pl. a te kódodban is vannak sűrűbb részek...
-
#352
hugo chávez
aktív tag
Coccer
#343
hugo chávez
aktív tag
Á, nem vagyok én egyedi ízlésű, csak tudomásom szerint jelenleg ezen cégek termékei a kategóriájukban a legjobb ár-érték arányúak.
"Nézz utána, hogyan működik, az oldalakon elvileg található GY.I.K."
Utánanéztem, nem nagyon írnak a külföldről történő garanciaérvényesítésről, csak annyit, hogy a szervizbe történő szállítást a vevőnek kell intéznie és költsége a vevőt terheli.
"Vagy választasz olyan márkát, ami megtalálható kishazánkban is."
Mindenképpen ezt fogom tenni és itthon is fogom megvenni, mert semmi kedvem kínlódni a külföldi cuccokkal. Meg közben eszembe jutott, hogy van szállítási költség, meg, ha balszerencsés vagyok, akkor vám is, tehát, amennyiben nem tudom ismerőssel/rokonnal elhozatni, akkor ez rárakódna az árra és úgy már nem is biztos, hogy olyan jó vétel lenne
Úgyhogy inkább megvárom a 28 nm-es mobil GPU-kat és jó lesz nekem egy itthon kapható Acer, Dell, Asus; stb. is, csak annyi a feltételem, hogy a videókártya legalább olyan erős legyen, mint egy GTX 470M
-
P.H.
senior tag
"Így mégis ciklusonként esne 1-1 load, csak ugye a várakozás miatt ez nem történik meg."
"Kényelmesen megtörténik, ..."
Nem véletlenül használtam mindkétszer az "indítani" kifejezést. Az ütemező feladata arra terjed ki, hogy megvárja a memóriahozzáférések címszámításához szükséges register-értékeket, majd órajelenként elindít legfejlebb kettőt az AGU-kba; nem érdekli, hogy 2 load-ról, 2 store-ról vagy 1 load + 1 store-ról van szó, az ő hatásköre csak eddig terjed. Gondolj a K10-re, ahol 3 független ütemező van a 3 AGU-ra, egyiknek sincs fogalma, hogy a másik épp mit indított el abban az órajelben, ők is indíthatnak 3 load-ot vagy akár 3 store-t egy órajel alatt.
Az AGU-k alatti memory subsystem egy önálló, független OoO-rendszert alkot, ami fizikai címekkel/átfedésekkel és L1D hit/miss-ekkel dolgozva kezeli a 2 load + 1 store L1D-portot, valamit a Load és a Store Buffer-t. Ehhez az uop-ok indításakor mindenképp kiszámolják a címet, rákeresnek a TLB-ben és ellenőrzik a találatot az L1D-ben, illetve a cím és a programsorrend ismeretében ellenőrzik, hogy az L1-hez kell fordulni, vagy egy függőben levő korábbi tárolásból kell beolvasni az adatot; mindebből órajelenként kettőt.
Ezekkel az állapotokkal ellátva bekerülnek a request-ek a Load Buffer-be (azok ezeket tárolják, nem a beolvasott adatokat) és L1-miss esetén az L2-vezérlőhöz, vagy a Store Buffer-be (ahol bevárják a tárolandó adatot, amit egy másik uop szolgáltat, majd szükség - Store-to-Load Fordarding - esetén továbbítják azt az azonos címre érkező load-hoz és/vagy tárolják az L1D-be; de maga az adat nem befolyásolja a memory subsystem OoO-működését).
Ezekből a pufferekből órajelenként 2 128 bites olvasási és 1 128 bites írási műveletet kap az L1D, nem program- és nem ROB-ütemezés szerinti sorrendben.Így nincs "várakozás", órajelenként 1x 256 bitet vagy 2 órajelenként 2x 256 bitet tud folyamatosan szolgáltatni a végrehajtó egységek felé (hacsak be nem telik a Load Buffer, pl. sorozatos L1-missek miatt). "Így az effektív érték 256 bit/cycle, "tehát órajelenként 1x256 bit nem gond neki." Azaz amelyik algoritmussal "el lehet érni a 2 op/1 load egészséges szintet", azt nem korlátozza semmi, hogy kifussa magát.
-
dezz
nagyúr
Nem tud. Az idézett részben éppen azt írják, hogy 1-1 256-bites adatbetöltés is 2 ciklust vesz igénybe, mert 1-1 AGU egyszerre csak egy 128-bites beolvasást tud eszközölni load bufferbe. A 2 AGU 2 ilyet tud eszközölni párhuzamosan, így az effektív érték 256 bit/cycle. (Az írás pedig 128 bit/cycle.)
-
P.H.
senior tag
Kényelmesen megtörténik, mivel a 2 általános célú AGU van (nem 1 load + 1 store), azaz szükség esetén akár 2 256 bites load uop-ot is tud indítani per cycle; tehát órajelenként 1x256 bit nem gond neki.
According to Intel, 256-bit memory accesses execute as a single uop, thus they only use one entry in the ROB, PRF and memory order buffers. However the actual data accesses are 128-bits wide, so a clever appraoch is needed to have a 256-bit load execute as a single uop. The most likely technique is described in an Intel patent application and suggests using the 1 cycle bypass delay to guarantee that both halves of a 256-bit load complete in the same cycle. The high half would be initiated in the first cycle, doing address calculation, a TLB lookup and checking the cache tags for a hit, and the 128-bit high half would reach the FP execution stack 5 cycles later. The low half would subtract 16B from the address of the high half and start in the second cycle, with the result reaching the SIMD execution stack 4 cycles later. Thus both 128-bit accesses would arrive in the same cycle and complete together as a single 256-bit uop.
Ebből tud kettőt indítani órajelenként.
Most azért nem, mert 32 bites a program, ahol csak 8 XMM register használható (illetve AVX esetén 8 YMM) a 16-ból. Ha átírom (majd, évek múlva) AVX-re, akkor viszont már csak 64 bites változatot fogok készíteni. Addig is ez PIII-tól kezdve mindenen jól teljesít, és azt is könnyű észrevenni, hogy a Bulldozer milyen sokat fog rajta dobni (2x annyi ADD/SUB van benne, mint MUL, illetve a register-to-register másolásokat 0 órajel alatt elintézi).
-
dezz
nagyúr
Ha nincs dependencia, akkor azok az ADD-ok és MUL-ok egyszerre hajtódhatnak végre, nemde? Így mégis ciklusonként esne 1-1 load, csak ugye a várakozás miatt ez nem történik meg.
"de 7-8 konstans értéket előre betöltenék registerbe"
Most amúgy miért nem?
(#347) lenox: Ja, tényleg, elfelejtettem, hogy azok ott FMAC-(o)k. Bár FMA-nál, ami gyakori "vendég" GPU-knál, nem két független ADD és MUL van, hanem a MUL eredményét adja hozzá valamihez, és az a valami általában egy regiszter tartalma.
"Az lds 128 byte szeles, tehat orajelenkent 128 byte-ot tud adni, a 64-es es a 80-as esetben is."
Nos, akkor itt még rosszabb is az arány. Csak nagyon nem mindegy, hány regiszter áll rendelkezésre és osztozhatnak-e rajtuk a superscalar "magocskák" SIMD blokkon belül. Gondolom, igen és többszáz regiszterről hallottam, ami már igencsak olyan, mint egy nem kicsi L0D cache.
"Szoval ha jol ertem az az erv, hogy biztos nem veletlenul van benne?"
Inkább az, hogy a GPU-k evidensen sokkal inkább a throughputra mennek, amihez nem nagyon passzolnának a szűkös adatutak.
-
lenox
veterán
"mig az sb eseteben egy core-on csak 8-at"
16-ot.Tolem lehet 16-ot, csak akkor a masik 2 esetben sem 64 vagy 80 kell, hanem 128 vagy 160 ha hasonlo adatmennyiseget varunk el. Nyilvan akkor egyforma, ha 1 flopra vetitve ugyanakkora a mennyiseg, vagyis ha 8 osszeadasra es 8 szorzasra te 16 uj adatot akarsz (en meg 8-at), akkor 80 osszeadasra es 80 szorzasra te 160 at akarj (en meg 80-at).
Az lds 128 byte szeles, tehat orajelenkent 128 byte-ot tud adni, a 64-es es a 80-as esetben is.
Csak tudod, vagy egy olyan dolog, hogy a GPU-kban sosem dísznek van ott az a sok számolóegység.
Szoval ha jol ertem az az erv, hogy biztos nem veletlenul van benne?
-
P.H.
senior tag
Feltételezve, hogy hosszú távon átlagosan 1 művelethez 1 load szükséges. Azonban számos esetben az algoritmus sok reg,reg számítást használhat; minél többet, annál kevésbé korlátoz a load.
Nyilván mivel az AVX 256 bites és non-destruktív, ezért nagyban tömörödik a kód az SSE/SSE2-höz képest (kb. feleannyi utasítás, sok register-to-register másolás kiesik), de azért könnyen el lehet érni a 2 op/1 load egészséges szintet.
Például itt a JPEG-ekhez használt SP SSE-kódom, megjelöltem a load/load+op és store utasításokat: [link]. Ha átírnám AVX-re, a kód fele kiesik, mivel 4x32 bit helyett 8x32 biten dolgozik minden utasítás, de még úgy is megmaradna nagyjából 1 reg,reg : 1 reg,mem műveleti arány (de 7-8 konstans értéket előre betöltenék registerbe, úgy megintcsak kiesne a lefutásonkénti load-ok kb. 50%-a). -
dezz
nagyúr
"Igen, csak lehet, hogy nem gondoltad vegig, hogy pl. a vliw4 eseten egy simd-ben 64 32bites float feldolgozot kell etetni"
Értelemszerűen saját magához képest értettem, hogy nem fele-negyede a kívánatosnak. Egyébként a Llanoban Evergreen alapú IGP van, azaz vliw5-ről beszélünk. Nos igen, ez 32x80=2560 bit, ami nem kevés (bár ez talán 4-felé oszlik, mert 4 texture unit van SIMD blokkonként-> 640 bit), viszont a GPU-k kimondottan erre a feladatra vannak kihegyezve, így talán "elfér". De tegyük fel, nem. Szerintem a GPU-kban 1-1 FMAC-ra több regiszter jut. Sőt, valószínűleg SIMD blokkon belül osztoznak is, így sok-sok felesleges adatbetöltést lehet megspórolni.
"mig az sb eseteben egy core-on csak 8-at"
16-ot.
"LLano-t nem tudom, de pl. a Cayman eseten 2 orajel alatt tud az lds-bol 1 float eljutni minden feldolgozohoz (tehat egy vliw4-hez 4 float), es azt irtak, hogy gyengebb gpuknal 2-szer ennyi ido kell hozza, tehat mig sb-nel egy orajel alatt atjohet egy-egy adat, llano-nal valoszinuleg 4 ciklus kell hozza."
Itt véletlenül nem data-latencyről van szó?
"Szerintem a mai gpu-k joval bonyolultabbak annal, hogy olyannal lehessen ervelni, hogy mert biztos tobb, mint 128 bit szeles a cache. Ennel sokkal reszletesebb meg kene nezni, ha meg nem, akkor szerintem a peak-et a peak-kel erdemes osszehasonlitani"
Csak tudod, vagy egy olyan dolog, hogy a GPU-kban sosem dísznek van ott az a sok számolóegység. Egy CPU esetén bocsánatosabb bűnnek számít (főleg x86 vonalon), ha a gyakorlatban az elméleti floating-point számítási teljesítmény pl. max. felét lehet hozni. (Lásd pl. az SSE2 [asszem] esetét, amit eleinte 64 bitenként hajotottak végre.)
"de az altalad kedvelt architectura peak-jet a nem kedvelt gyakorlatban elert eredmenyevel osszehasonlitani az tuti, hogy hibas."
Eredetileg az SB-nél is az elméleti peaket akartam venni, nem tudtam, hogy egyszerre mehet az FADD és FMUL. Miután megtudtam, bonyolódott a helyzet, de az ugyancsak nem fer, hogy az elméleti peaket sustain(ed)nek vesszük, mint ez a Kanter. Legjobb lenne, ha a GPU-kon is szokássá válna SPEC teszteket futtatni. (Egyébként az SB-vel nincs különösebb gondom, esetleg a gyártójával. Különösebben a Radeonokat sem kedvelem.)
"Nyilvan nem jol van akkor irva, 8-as sorozattol kezdve megy az opencl."
Mondjuk a másik lapon sincs odaírva az 1.0 a HD4000-esekhez.
"HPC-nel ecc is kell, nem? Abban mintha gyenge lenne az amd, vagy ez mar valtozott?"
Passz.
-
lenox
veterán
Már volt róla szó: bizonyos, hogy ott nem csak 128-, illetve 256-bites az összeköttetés a cache-ek felé!
Igen, csak lehet, hogy nem gondoltad vegig, hogy pl. a vliw4 eseten egy simd-ben 64 32bites float feldolgozot kell etetni, mig az sb eseteben egy core-on csak 8-at. LLano-t nem tudom, de pl. a Cayman eseten 2 orajel alatt tud az lds-bol 1 float eljutni minden feldolgozohoz (tehat egy vliw4-hez 4 float), es azt irtak, hogy gyengebb gpuknal 2-szer ennyi ido kell hozza, tehat mig sb-nel egy orajel alatt atjohet egy-egy adat, llano-nal valoszinuleg 4 ciklus kell hozza.
Szerintem a mai gpu-k joval bonyolultabbak annal, hogy olyannal lehessen ervelni, hogy mert biztos tobb, mint 128 bit szeles a cache. Ennel sokkal reszletesebb meg kene nezni, ha meg nem, akkor szerintem a peak-et a peak-kel erdemes osszehasonlitani, de az altalad kedvelt architectura peak-jet a nem kedvelt gyakorlatban elert eredmenyevel osszehasonlitani az tuti, hogy hibas.
Itt csak a DX11-esektől, azaz a GF400-asoktól vagy feltüntetve egyátalán az OpenCL, nagyrészt 1.0-ával, mivel:
Nyilvan nem jol van akkor irva, 8-as sorozattol kezdve megy az opencl.
DP-t eddig meg csak tesztben hasznaltam, amugy nem volt ra szukseg, ugyhogy sajna nem tudom, hogy mi supportalja, mi nem, de ha a 8-as sorozattol nincs kiirva az opencl, akkor a DP kiirasanak hianya semmit nem jelent, de gondolnam, hogy csak par gpu supportalja egyaltalan, azok is jo lassan, tesla vagy quadro kell a rendes sebessegu DP-hez gondolom.
HPC-nel ecc is kell, nem? Abban mintha gyenge lenne az amd, vagy ez mar valtozott?
-
#343
Coccer
tag
hugo chávez
#308
Coccer
tag
válasz
hugo chávez
#308
üzenetére
Oké, rendben! Nem tudtam, hogy ilyen egyedi ízlésű vagy...
Viszont, ha ezen három márka termékeit preferálod, akkor szinte sosem lesz ilyen laposod, amíg nem lesz hazai képviseletük.
Nézz utána, hogyan működik, az oldalakon elvileg található GY.I.K.-is, helyi nyelvi megfelelőséggel leírva, ahol szépen elmagyarázzák a nemzetközi garancia ismérveit, feltételeit, szolgáltatásait.
Vagy választasz olyan márkát, ami megtalálható kishazánkban is. Probléma megoldva.
Dönts okosan... a bank nélkül!
Szép napokat.
-
dezz
nagyúr
"Ugyanazzal, mint amivel a llano-bol 500 GFLOPS-t. Vagy ott szerinted ez nem erdekes?"
Már volt róla szó: bizonyos, hogy ott nem csak 128-, illetve 256-bites az összeköttetés a cache-ek felé!
"Szerintem egyebkent peak performance osszehasonlitasahoz nem."
Amennyiben tök mindegy, mennyire elméleti az a peak...
"Feltetelezom ott a Llano is megtalalhato 500-zal, ugye?"
"mikor kijott az 1.1 specifikacio a khronostol nekem mar volt nvidia 1.1-es driverem, es nem tunt fel, hogy valamin nem futott volna, amin probaltam."
Itt csak a DX11-esektől, azaz a GF400-asoktól vagy feltüntetve egyátalán az OpenCL, nagyrészt 1.0-ával, mivel:
"Although all 400-series GPUs are architecturally capable of providing Open CL 1.1 support, drivers are not yet available for all models (as at 03/05/2011). For those models with Open CL 1.1 driver support, this is a beta driver only (v258.19 from June 2010)."
Az 500-asok jelenleg végig 1.0-ával szerepelnek, mivel:
"Although all 500-series GPUs are architecturally capable of providing Open CL 1.1 support, drivers are not yet available (as at 03/05/2011). Current drivers support Open CL 1.0 only."
(Az AMD-nél tavaly nyár óta van 1.1-es public driver, ami az összes 5000 és 6000-essel megy. A 4000-esek az 1.0-át viszik.)
BTW, azt esetleg tudod, hogy a fenti táblázatokban miért nincs feltüntetve a DP teljesítmény?
(#341) hugo chávez: Nos, Intel prociknál rendszerint többet előlegez meg, AMD-seknél pedig kevesebbet... (Van az a pénz...
)"Amúgy az mennyire lenne hátrány az OpenCL kódok szempontjából, ha nem tudna DP FP-t?"
A HPC szektorban bajos lenne, de hétköznapibb kódok SP-t használnak.
-
#341
hugo chávez
aktív tag
dezz
#339
hugo chávez
aktív tag
"a RealWorldTechen az elméleti peaket írták sustainednek."
Biztos megelőlegezte az extrabizalmat Szandikának a cikkíró, vagy csak túl sok N2O-t tolt a cikkírás közben
"DP-t elvileg nem tud.
Ha esetleg mégis tudna, akkor ugye az Evergreen-ekből kiindulva 1/5-e lenne a DP FLOPS a SP FLOPS-nak, azaz a peak 100 GFLOPS körül lenne, ami kb. annyi, mint amennyit a 4 magos 3.4 GHz-es Sandy tud, viszont itt lenne igazán érdekes, hogy mennyivel lenne kevesebb a sustained FLOPS a peak-nél. Amúgy az mennyire lenne hátrány az OpenCL kódok szempontjából, ha nem tudna DP FP-t?
(#342) dezz:
Abu szerint a Quadro-khoz van OpenCL 1.1 driver, csak a GeForce-okhoz nincs:[link]
-
lenox
veterán
Milyen hasznos algoritmussal lehet ebből kihozni 200 GFLOPS sustained rátát?
Ugyanazzal, mint amivel a llano-bol 500 GFLOPS-t
. Vagy ott szerinted ez nem erdekes? Szerintem egyebkent peak performance osszehasonlitasahoz nem.De elmélkedés helyett inkább szét kellene nézni a spec.org-on vagy máshol, gyakorlati eredményekért.
Feltetelezom ott a Llano is megtalalhato 500-zal, ugye?
Tudom, ez neked fájó pont, mert csak a legújabb Nvidia kártyák támogatják...
Szerintem rosszul tudod, mikor kijott az 1.1 specifikacio a khronostol nekem mar volt nvidia 1.1-es driverem, es nem tunt fel, hogy valamin nem futott volna, amin probaltam. Az igaz, hogy nem volt publikus (nem tudom, most az-e), de mondjuk ezert nem szomorkodtam.
-
#339
dezz
nagyúr
hugo chávez
#337
dezz
nagyúr
válasz
hugo chávez
#337
üzenetére
Jó, de a RealWorldTechen az elméleti peaket írták sustainednek.
400 sp @ ~600 MHz -> 480 SP GFLOPS. DP-t elvileg nem tud.
-
#337
hugo chávez
aktív tag
dezz
#336
hugo chávez
aktív tag
Persze, hogy alacsonyabb, mint a peak, de azért a 80% elég jó szerintem, különösen, hogy valós alkalmazásról van szó
Igen, olvastam, az egyértelmű, hogy a pontosságon javítani fog, de a sebességnövekedés valós mértéke csak akkor fog kiderülni, ha tesztelik majd a Bull-lal, szóval, majd meglátjuk...
"Megjegyzem, a Llanoba került IGP is FMA-s."
Csak, hogy kötekedjek egy kicsit, a Llano IGP-jének várhatóan mennyi is lesz a peak DP FP teljesítménye (a sustained-ről már nem is beszélve)?
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#336
dezz
nagyúr
hugo chávez
#335
dezz
nagyúr
válasz
hugo chávez
#335
üzenetére
Nem rossz, de 3,5 GHz-en 112 lenne az elméleti max., azaz a sustained mindenképpen alacsonyabb. Itt pl. 80%.
Ezt is nézted amúgy a végén?
"Finally, let us mention the future improvement of our
implementation. The performance of our N-body code will
be higher when Fused Multiply-Add (FMA) instructions
are introduced. Using the FMA instructions which com-
pute the product of two numbers and add the result to an-
other number in one step, we will be able to improve the
performance and the accuracy of the code, especially accu-
mulation of jerks in the force loop. The FMA instructions
will be available in the next-generation CPU named ”Bull-
dozer” by AMD Corporation, and ”Haswell” by Intel Cor-
poration, which are scheduled to be released in mid-2011,
and in 2013, respectively."Megjegyzem, a Llanoba került IGP is FMA-s.
"A SPECfp2006 támogatja az AVX-et?"
Ezek nem ASM-ben vannak írva, hanem gondolom valamilyen vektoros C-kiterjesztéssel, így fordítási optimizáció-beállítás kérdése. Egyébként igen, AVX-esre fordították őket, mint a részletes eredményeket tartalmazó lap alján látható.
-
#335
hugo chávez
aktív tag
dezz
#332
-
dezz
nagyúr
Jó, de az a peak, nem a sustained.
Nézd, 16db 256-bites YMM regiszter van, azaz 16db vec8-cal dolgozhatsz "pörgősebben", és az eredményeket is ezekben kell tárolni. Ehhez ciklusonként 1db vec8-at hozhatsz még be a L1D-ből és felet írhatsz ki (ill. 2 ciklusonként egyet). Persze magonként. Milyen hasznos algoritmussal lehet ebből kihozni 200 GFLOPS sustained rátát?
De elmélkedés helyett inkább szét kellene nézni a spec.org-on vagy máshol, gyakorlati eredményekért.
"akkor szerintem valoszinuleg valamit mashogy erdemes csinalni."
Igen, pl. OpenCL 1.1-et kell használni...
Tudom, ez neked fájó pont, mert csak a legújabb Nvidia kártyák támogatják... -
-
lenox
veterán
Erm, akkor viszont rossz az a szám ott, a sustain társaságában.
Nem hinnem, mashol is 200-at irnak.
És mi értelme lenne a regiszterekben elférő számokon hosszabban "csámcsogni"?
Pl. mi ertelme iteralni? Lehet, hogy semmi, de szoktak
.Viccelsz? A main memória és a VGA kártyán lévő memória között PCIe 2.0 x16-on 8 GB/s a sávszél irányonként. Main memórián belül "mennyivel" is lehet másolni? Már ha egyátalán szükség van rá, mert ugye meg lehet osztani a buffereket az OpenCL device-ok között.
Sokkal gyorsabban main memoryn belul sem lehet, ha ez lenne a bottleneck valahol, akkor szerintem valoszinuleg valamit mashogy erdemes csinalni. De ezt mar sokszor kitargyaltuk szerintem, en tovabbra sem vagyok rajongoja az integralt gyenge gpu-nak, az osztott kis savszelessegu memoriara kotve. De mondjuk nekem nincs is megkotve a kezem, mint a gyartoknak.
-
-
P.H.
senior tag
"Igen, de csak pár utasítás hosszon."
Ez peak; és itt jön képbe a HT keményen (az AMD is ezzel játszik a Bulldozer FPU-n: ha kimerül 1 szál futtathatósága pár órajel alatt, akkor bejön a 2. szál;ezért volt - feleslegesen pazarló - a K10 FPU-ja; ezt az Intel időben észrevette); bár Intel-nél ugyanazokra a portokra mennek az FP- és integer-utasítások is, ezzel némileg kitöltve a "lyukakat".
Nyilván elméletileg ha pl. minden AVX utasítás pl. 4 órajeles késleltetésű, akkor (legjobb esetben) 4 vagy (legrosszabb esetben) 8 szál kihasználja a teljes FPU-kapacitást. Ekkor vagyunk kb. ott, amiről a GPU-k legjobb esete szól -
dezz
nagyúr
"Akkor miért nem?"
Igen, de csak pár utasítás hosszon.
(#326) lenox: Erm, akkor viszont rossz az a szám ott, a sustain társaságában.
Egyébként FLOPS, mert a Hz-ben benne van a /s.
"A cache-ek szelessege nem tudom, miert erdekes, hasznalhatsz regisztereket"
És mi értelme lenne a regiszterekben elférő számokon hosszabban "csámcsogni"?
"a LLano IGP-nel sem gondolnam, hogy a data path-eket vegigszamoltad volna"
Annak még nem ismerjük a belső felépítését, de kötve hiszem, hogy mindössze 256-bites (írásra ráadásul csak 128) lenne az IGP összeköttetése a belső cache-jeivel.
"Ezt mar mashol is targyaltuk, biztos lehet olyan alkalmazast talalni, ahol jobb main memoryn belul masolni, pl, benchmarknal"
Viccelsz? A main memória és a VGA kártyán lévő memória között PCIe 2.0 x16-on 8 GB/s a sávszél irányonként. Main memórián belül "mennyivel" is lehet másolni? Már ha egyátalán szükség van rá, mert ugye meg lehet osztani a buffereket az OpenCL device-ok között.
"de valos alkalmazasnal ez csak egy a sok tenyezo kozul"
Elég fontos tényező...
"de ahol meg ezen mulik minden, ott jobban jarsz egy avx implementacioval masolas nelkul."
Ha nem kell másolás, akkor nem.
-
lenox
veterán
Ezt fejtsd mar ki bovebben, szerintem 16 flop/cycle * 4 mag * 3 GHz = 192 GFLOP.
A cache-ek szelessege nem tudom, miert erdekes, hasznalhatsz regisztereket, a LLano IGP-nel sem gondolnam, hogy a data path-eket vegigszamoltad volna, csak elmeleti peak performance van ott is, szoval nem latom, hogy az sb-nel miert kellene mashogy szamolni.
Ezt mar mashol is targyaltuk, biztos lehet olyan alkalmazast talalni, ahol jobb main memoryn belul masolni, pl, benchmarknal
, de valos alkalmazasnal ez csak egy a sok tenyezo kozul, de ahol meg ezen mulik minden, ott jobban jarsz egy avx implementacioval masolas nelkul. -
P.H.
senior tag
Az hogy jon a kepbe, hogy teljes-e az utasitaskeszlet? SSE2-bol jo sok mindent hianyoltam annak idejen, aztan azota javitottak.
Mivel az alkalmazási körében minden korábbi egyszerű utasítás lecserélhető a 256 bites megfelelőjére (ami megvolt 32->64 MMX-nél, ->32bit FPU SSE-nél, ->64bit FPU SSE2-nél)
Mi az a sok minden, amit hiányoltál és javítottak?Az SSE2 és az AVX között nagyjából annyi a különbség, hogy 2x annyi adatot dolgoz fel ugyanannyi utasítással. Mit kellene az alap alkalmazáson fejleszteni?
Nyilván ha a CUDA-ra vagy SSE(2)-re portolás egyszerre, egy időben jött szóba nálad, akkor egyszerűbb GPU-ra és gyorsabb a végeredmény. Viszont igen sok kész SSE-kód van a piacon (sokkal több, mint GPU-s), aminek csak egy újrafordítás kell.
dezz: beidézted, hogy egyidőben 2 (igazából 3, de a shuffle/pack bytesorrent-átrendezést általában nem számításként számolják) 256 bites utasítás futhat/indulhat egyszerre Sandy Bridge-en. Akkor miért nem?
-
dezz
nagyúr
Nem.
"Sandy Bridge can sustain a full 16 single precision FLOP/cycle or 8 double precision FLOP/cycle – double the capabilities of Nehalem."
"As Figure 5 above indicates, Sandy Bridge can execute a 256-bit FP multiply, a 256-bit FP add and a 256-bit shuffle every cycle. However, the floating point data paths were not expanded and are still 128-bits wide; instead the SIMD integer data paths are enlisted to assist with AVX operations."
"Instead of widening the data paths to 256-bits, the Sandy Bridge architects moved the integer SIMD stacks to slightly different issue ports and cleverly re-use the existing 128-bit SIMD and 128-bit FP data paths ganged together to execute 256-bit uops. For example, a 256-bit multiply can issue to port 0 and simultaneously use the 128-bit SIMD data path for the low half and the 128-bit FP data path for the high half." [link]
A L1D cache-ből való olvasás 2x128-bites, a L1D-L2 között is 256-bites az összeköttetés. [link]
Szóval, a max. sustained throughput ~108 GFLOPS.
(#318): Pl. a "Sub-buffer objects to distribute regions of a buffer across multiple OpenCL devices"? Nem tudom konkrétan és már nem tudom, hol olvastam. De ha mindenképpen másolgatásra is lenne szükség, nagy előny egy APU esetén, hogy a main memórián belül kell adatot másolni.
-
lenox
veterán
Nyilvan megfelelo library hasznalataval meg gyorsabban lehet 'atfejleszteni'. Az atforditas gondolom legtobb esetben hozhat teljesitmenyjavulast, de valoszinuleg nem a legoptimalisabb eredmenyt produkalja, nem? Csak mert a max teljesitmeny valoszinuleg az eleve avx-re fejlesztett koddal lehetne elerni, es ilyen fejlesztes sokkal kevesebb lesz, mint annak idejen sse volt.
AVX-et meg nem probaltam, mert meg nem jottek ki az sb-s dual cpu-s workstationok, de mindenesetre a cudara portalas joval egyszerubb volt, mint annak idejen az sse/sse2, opencl meg megint konnyu, szoval szerintem a gpus irany joval konnyebb, mint az avx-es irany, de aztan biztos van olyan feladat, vagy fejleszto, akinek az avx jobb.Az hogy jon a kepbe, hogy teljes-e az utasitaskeszlet? SSE2-bol jo sok mindent hianyoltam annak idejen, aztan azota javitottak.
-
#95904256
törölt tag
Na, akkor valóban 200GFlops-ra képes.
GPU-val olyan feladatokat érdemes számoltatni, ahol egyszerre nagymennyiségű adaton kell elvégezni az adott műveletsort és kevésbé érdekes a késleltetés. Épp ezért az SSE kód kiváltása cseppet sem biztos, hogy megoldható GPU-val... AVX-szel viszont igen.
-
P.H.
senior tag
Most a leggyorsabb módja az AVX kihasználásának a meglevő SSE2 kódok AVX-re fordítása: a kódszerkezet ugyanaz marad, sok esetben csak egy fordítási opció.
GPU-ra/OpenCL-re újra kell szervezni a kódot, és elsősorban a már többszálú alkalmazásokban tud pluszt felmutatni, míg az AVX egy szál esetében is.Az AVX ugyanúgy teljes utasításkészlet, mint az MMX, az SSE és (utoljára) az SSE2 volt.
-
lenox
veterán
válasz
#95904256
#317
üzenetére
De osszeadast meg szorzast egyszerre tud, szoval 2 flop/clock.
Szerintem nem, mivel az sse idejen az volt a gyorsitas legkonyebb modja, ha sse-t haszanlsz, ma viszont mezei ember gpu-val jobban jar. Valamilyen specko alkalmazashoz szerver kornyezetben jobb lehet az avx, de szerintem alig lesz valaki, aki hasznalni fogja az sse-hez kepest.
-
lenox
veterán
Úgy tudom egyébként, hogy az OpenCL 1.1 egyik újítása, hogy segít ezt felgyorsítani (nem kell minden adatcserekor mindent kiírni a main ramba, vagy ilyesmi).
Melyik lenne ez a feature? Utoljara mikor neztem (es akkor mar reg volt 1.1) ugy mukodott az amd szerint, hogy cpu bufferbol at kellett masolni gpu bufferbe az adatot, hiaba mindketto ugyanugy a fo memoriaban volt lefoglalva amugy...
-
lenox
veterán
4 magos sb-nel nem 200 gflops? Amugy egy cpu-s 200 gflops es gpu-s 500 gflops eseten konkret alkalmazasnal mar nagyon keteselyes, hogy melyik lesz gyorsabb, tekintve a latencykre, bandwidth-ekre meg cache-ekre. Persze mas kerdes, hogy ki ir annyira optimalis kodot, ami ezeket ki is hasznalja, pl. ki ir egyaltalan avx kodot.
-
#315
hugo chávez
aktív tag
Abu85
#309
hugo chávez
aktív tag
Értem, köszi. Remélem, hogy az Ivy-knál tényleg javítanak ezen.
(#310) dezz:
"Te a IB-t hasonlítottad az elődhöz -- azt hittem, logikus, hogy én is így tettem a Trinity esetén és hogy erre jól utal a "mint ahogy" is. Főleg mivel érdekes lett volna tényként állítani olyat, hogy sokkal erősebb lesz az SB-nél.
"Na, csak sikerült letisztázni, bár belekerült pár száz karakterbe, de megérte, most már végre kristálytiszta
Amúgy én személy szerint mindig próbálok arra törekedni, hogy, amennyire csak lehet, egyértelműen fogalmazzak, mert a múltban már volt néhány kellemetlen tapasztalatom ezzel kapcsolatban (ami számomra logikus volt, az másnak nem) "Az eddigi információk ismeretében eléggé valószínűsíthető, hogy..."nem lesz gyenge".
"Nos, én maximálisan drukkolok a Bull-nak.
-
#310
dezz
nagyúr
hugo chávez
#308
dezz
nagyúr
válasz
hugo chávez
#308
üzenetére
"Oké, de ugye az lenne a kérdés, hogy ettől a programok a gyakorlatban mennyivel gyorsulnának."
Majd meglátjuk, mindenesetre ez csak az egyik (lehetséges) előny.
"mert én sajnos nem vagyok gondolatolvasó"
Te a IB-t hasonlítottad az elődhöz -- azt hittem, logikus, hogy én is így tettem a Trinity esetén és hogy erre jól utal a "mint ahogy" is. Főleg mivel érdekes lett volna tényként állítani olyat, hogy sokkal erősebb lesz az SB-nél.
"de amíg meg nem jelennek a konkrét procik, addig igazság szerint csak találgathatunk, szóval még bármi lehet..."
Az eddigi információk ismeretében eléggé valószínűsíthető, hogy -- hacsak nem szúrnak el nagyon valamit -- "nem lesz gyenge".
-
#309
Abu85
HÁZIGAZDA
hugo chávez
#308
Abu85
HÁZIGAZDA
válasz
hugo chávez
#308
üzenetére
Ha kevés a függőség a kódban, akkor teljesen jó az Intel megvalósítása. A Sandy IGP-je más hiányosságok miatt nem képes az OpenCL normális támogatására. Majd az Ivy ezen javít.
A Sandy IGP legnagyobb gondja a lokális adatmegosztás tejes hiánya. Ez ugyan nem kötelező az OpenCL 1.0-hoz, de ha nincs meg, akkor brutálisan esik a teljesítmény. -
#308
hugo chávez
aktív tag
dezz
#287
hugo chávez
aktív tag
"Nem tudok konkrét sebesség teszteredményeket...
Találtam két doksit: [link] és [link] (13-14. oldalon az összehasonlítás)
"mert valószínűleg eléggé mikroarchitektúrafüggő a dolog."
Amennyiben így van, akkor a Bulldozer és a támogatott programok megjelenéséig nem nagyon leszünk okosabbak.
"De olvastam olyat is, hogy ez akár a 2x-re növelheti a dependens FMUL+FADD utasításpárosok végrehajtását"
Oké, de ugye az lenne a kérdés, hogy ettől a programok a gyakorlatban mennyivel gyorsulnának.
"Nem. Talán SB magokat cserélnek Enhanced Bulldozer magokra a Trinitynél?
"Jaj, hát akkor talán oda kellett volna írni, valahogy így: Mint ahogy a Trinity CPU része is (sokkal) erősebb lesz a Llano-nál, akár az IB-nél is, mert én sajnos nem vagyok gondolatolvasó
és mivel nem beszéltem a Llano-ról, csak a Sandy-ről és az Ivy-ról, te pedig erre válaszoltál, ezért nem tudhattam, hogy a Llano-ra gondolsz."A Bulldozer viszont egy teljesen új kialakítású mikroarchitektúra, aminek lehetnek még gyermekbetegségei, ki nem használt lehetőségei. Elemzők szerint vannak is."
Én nagyon örülnék, ha tényleg sok lenne a Bull-ban, jó lenne már, ha teljesítményben is valós konkurenciája lenne az Intel-nek (már csak azért is, mert ez gyorsítaná a fejlődést), de amíg meg nem jelennek a konkrét procik, addig igazság szerint csak találgathatunk, szóval még bármi lehet...
(#289) Coccer:
Nem tudom, hogy pontosan hogyan működik ez a "világgarancia", de feltételezem, hogy, ha nincs hazai márkaképviselet, akkor külföldről nem fognak futárt küldeni. És sajnos az általam preferált, árban is elfogadható termékű gyártóknak, pl. Sager, Eurocom, Avadirect, nincs hazai képviseletük.
(#290) Abu85:
Arról lehet tudni, hogy az Intel féle vektorprocik az OpenCL-es progik futtatása esetén hatékonyabbak, vagy kevésbé hatékonyak lesznek, mint a másik két gyártó megoldásai?
#305) RyanGiggs:
Naná, hogy számít minden fillér, de azért várd meg a Bull-okat, mert még az is lehet, hogy a 6 magosak az i7 2600-al lesznek egy szinten teljesítményben, akkor pedig már nem olyan rossz az a 240$-os ár.
-
dezz
nagyúr
Az Intel kb. ott tart GPU-ban, mint az Nvidia vagy az ATI vagy 5 éve... Az utóbbiak azóta éppen hogy eltávolodtak a komplex shaderektől, hogy minél több ALU lehessen a chipekben. A szálak végrehajtását központosított threadkezelő vezényli. Ez így jóval hatékonyabb és gazdaságosabb. (Ennyit a Chip magazinról...)
(#295) DraXoN: Ja bocs, értem. Viszont ne felejtsd el, hogy a Bulldozer mikroarchnál 2 mag nem sokkal nagyobb helyet foglal, mint korábban egyetlen egy... Így azonos magszám mellett jóval több hely jut majd az IGP-nek a Trinitynél.
-
#305
RyanGiggs
őstag
hugo chávez
#278
RyanGiggs
őstag
válasz
hugo chávez
#278
üzenetére
A 6magos lesz 50k?? (240$)
Nos ha az az i5-2500K val lesz egyenértékű, akkor marad az Intel, 45k-ért!!
Minden fillér számít!
Főleg nekem, aki nem áll egyik pártján se!
Az Intelnek nagyon fel kell kötnie a gatyáját, ha az Ivy IGP-jével meg szeretné közelíteni ezeket az eredményeket.
Igen, igazad van, a 2 mat. művelet + 1 loaddal nincs gond.
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Milyen autót vegyek?
- Fejhallgató erősítő és DAC topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- bitblueduck: RTX 50-es széria PhysX támogatás nélkül. Tényleg akkora probléma?
- Konzol Screenshot
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Nvidia Quadro M2000/ P2000/ P4000/ RTX 4000/ RTX 5000/ RTX A2000
- ÁRGARANCIA!Épített KomPhone i5 14400F 32/64GB RAM RX 9060 XT 8GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! MSI Z87-G43 GAMING Z87 chipset alaplap garanciával hibátlan működéssel
- GYÖNYÖRŰ iPhone 13 128GB Red -1 ÉV GARANCIA - Kártyafüggetlen, MS2931, 100% Akkumulátor
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest