Keresés: - [Re:] Jönnek az új Xeon Phi gyorsítók

Legfrissebb anyagok

Mobilarena témák

PROHARDVER! témák

IT café témák

GAMEPOD témák

LOGOUT témák

Keresés

Új hozzászólás Aktív témák

#63 tocsa senior tag Abu85 #54

Új Válasz 2013-05-18 04:11:22 #63
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

tocsa

senior tag

válasz Abu85 #54 üzenetére

Igaz, sajnos a skalazodas az problema lehet. Ezen javithat az, hogyha a feladat szerencses, es nagy CPU de keves memoria mozgatasi igenyu. De ez ritka. x86-nal Intel eseteben a QPI segitene (bizonyos feladatoknal), de a Phi-ben nincsen QPI.
A savszelesseg a GPU-knal is problema amugy, az nVidia cross-bar memoriat tervezett az AMD pedig ring buszt. (javitsd ki ha forditva van), mindkettonek megvan a maga elonye es hatranya.
#62 tocsa senior tag LordX #53

Új Válasz 2013-05-18 04:08:18 #62
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

tocsa

senior tag

válasz LordX #53 üzenetére

Koszi egyebkent a "vitat", eszmecseret.
Szandekosan helyezkedtem egy kicsit a kartya oldalara, es probaltam felhozni erveket mellette. Vegul ugyos a piac dont. A CUDA miatt meg amugy is at kell strukturalni kicsit a programot. Ami architekturalisan az elonyere is valik, hogyha nem olyan bonyolult az akernel es nem include-ol be foloslegesen dolgokat.
#52 tocsa senior tag LordX #51

Új Válasz 2013-05-16 05:21:41 #52
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

tocsa

senior tag

válasz LordX #51 üzenetére

2.) Pont azt magyarazod, hogy miert lehet letjogosultsaga egy ilyen many-core x86-os architekturanak. A 32-es warp size miatt ha a thread-ek futasi ideje nagyon kulonbozo, akkor az nagyon betehet az ossz teljesitmenynek a GPU-nal. Vegyunk peldaul egy kepfeldolgozasi algoritmust, ami maszkolt, azaz a kep csak bizonyos reszeire kell lefuttatni, es ezek a reszek amorfak. Namost egy data parallel algoritmust siman raszabaditok 8 magra, ugy ahogy van, ezek szepen kiszamolnak minden, ha valamelyik pixel es kornyezete hatarertek alatti, akkor nyomul a kovetkezore. Ellenben a GPU nagyon megszivhatja. Most csak emiatt strukturaljam at az adatot? De az egesz tili-tolival nagyon elmegy az ido. Mar az adat mozgatas a GPU es a rendszer kozott is problema, es ezt meg meg kene fejelni megegyszer annyival, hogy atrendezgessek, hogy a GPU-nak kegyeskedjen jo lenni a bemenet.
(Azt is tegyuk hozza, hogy a legujabb generacios nVidia GPU-knak mar fejletteb utemezoje van es ilyen kiegyensulyozatlan feladatok eseten jobban teljesitenek, de nekem meg nincs ilyen kartyam).
(Meg azt is tegyuk hozza, hogy az AMD legujabb tervezett APU-inal pedig az adat mozgatas a CPU es a GPU kozott nem lesz gond, mivel nem lesz szukseg ra, mert mindketto ugyanazt a kozos cimteret es GDDR5 memoriat latja majd.)
3.) Varjunk azert. Egy darab string tipusu valtozo, karakter halmaz egy fajlon belul != maga a text fajl. Az a C++ text fajl az IDE-ben megnyitva syntax highlight-olt, debuggolod, sorokra ugrassz, stb. Mig egy stringbe belehanyva az egesz source... hat... nem kis kulonbseg van. Pl a syntax highlight esetleg felesleges funkcionak tunhet, de valojaban nagyon sokat jelent ahhoz, hogy jobban atlassad a kodot es konnyebben eszrevedd a hibakat. Majdnem erre megy ki az egesz jatek, hogy kikuszoboljuk a hibakat, amiket vetunk! Minden lepes szamit ehhez.
#49 tocsa senior tag LordX #46

Új Válasz 2013-05-15 16:14:30 #49
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

tocsa

senior tag

válasz LordX #46 üzenetére

1. Ki a loturo akarna C++ "szeru" programnyelven data parallel programozni, ha lehetne C++-ban is?
2. Mar miert ne lehetne data parallel programot irno C++ SMP architecturara??? Pont errol szol a Xeon Phi is, olvasd el amit irtam. Eredetileg pl dupla pontossagu lebego pontos teljesitmenye osszemerheto volt a GPGPU FLOP-javal. Igen is van (volt?) letjogosultsaga. Persze a piac majd eldonti vegul. Meg nemtom akkor vegul mennyire butitottak le. Az Atom magok kicsit lelomboznak.
Az OpenCL-ben pedig jo, hogy platform fuggetlen (AMD vs nVidia vs others), nade az egesz kerneled egy stringben van? (igy kuldod el leforditani, mondjuk tudom, hogy a leforditott kernel cache-elheto. Nade egy stringben van a kernel????)
C++ AMP-tol annyira nem vagyok felvillanyozva eddig meg, habar nem probaltam. Pont ezaz, hogy merni szeretnek majd, hogy mennyit tud a nativ CUDA-hoz kepest.
Van itt meg hova fejlodni.
#45 tocsa senior tag LordX #41

Új Válasz 2013-05-15 08:32:20 #45
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

tocsa

senior tag

válasz LordX #41 üzenetére

Hat az nem volt meg nekem, hogy ezek ennyire buta in-order magok. En egy korabbi tervre emlekeztem, ahol Pentium magokat hasznaltak (volna).
Felizgulas a C++ kodra: pedig te is peddzegeted a dolgot. "teljesen más szemantikájú fejléckészletet kell használni" - namost ha x86-os magok lennenek, akkor a meglevo x86-os kompilerek miatt nem lennenek ilyen korlatozasok. _Tenylegesen_, _valoban_ azt futtathatnal, amit akarsz, mert a kompiler le tudna forditani.
Ez igenis tenyezo lehet olyan esetben, ha mar van egy eleve multi-thread-es programod egy masszivan parhuzamosithato feladatra (tehat a kododat korlatozza az, hogy pl csak 8 szalon futhat, futhatna akar 200-on is). Viszont a kodod hasznal ilyen-olyan konyvtarakat. Tehat igazabol van egy kerneled, de nem felel meg meg a CUDA kovetelmenyeknek sem. Nem feltetlenul egyszeru megfosztani ezt a kodot a konyvtaraktol. (Gyakorlatilag implementalod a konyvtar azon reszet, amit hasznalsz).
240 vagy 1000 szal nagy feladatoknal, adatmennyisegnem nem gond, megvan az.
Itt a task parallel dolgot nem kevernem most ide. A lenyeg, hogy van egy kerneled, de az komplex.
Mondjuk itt most eppen nem is mesterseges intelligenci algoritmusokra gondolok, azok esetleg bonyolultabbak lehetnek. Bar nyilvan ott sem lehetetlen, lattam en olyan implementaciot, amit Python-ban irtak, a Python-hoz van olyan konyvtar, amivel CUDA-t is meg tudsz hajtani.
Az STL-t csak peldakent irtam.
C++ AMP-hez ovatosan allok hozza, meg nem probaltam ki, nyar vege fele lesz idom talan. Azt orommel hallom, hogy Linux-on is dolgoznak rajta. Van meg mas hasonlo szoftveres megoldas is egyebkent.
#38 tocsa senior tag Abu85 #25

Új Válasz 2013-05-14 06:05:31 #38
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

tocsa

senior tag

válasz Abu85 #25 üzenetére

Azert nem mindegy, hogy mennyire "nativ" az a C++ kod! Peldaul a CUDA kernelbe nem lehet STL konyvtarakat beinclude-olni (ergo a compiler ami a CUDA magok assembly-jere fordit nem kepes meg boldogulni mindazzal a generikus es egyeb nyelvi dologgal, ami ezzel jarna). Jol izolalt es jol korulhatarolt kerneleket tud futtatni. AMi szoftver architekturalisan nem feltetlenul gond.
Ha az Intel nem butitja el tulzottan az x86 architecturatol az MIC magokat, akkor annak pont az lehet az elonye, hogy a meglevo C++ compiler-ek optimalizalni tudnak rajuk meg mindig, es valoban _barmilyen_ (szo szerint) C++ kodot kepes futtatni.
Xeon Phi-nek ket esetben latom ertelmet:
1. Nagyon eros dupla lebego pontos szamitasu massziv parhuzamos feladatoknal. Az nVidia es az AMD is probal itt feljebb kapaszkodni, de mivel az MIC magok Pentium magok, es annak azert nem olyan rossz az FPU-ja, ezert a Xeon Phi-nek viszonylag jo DP FP teljesitmenye van. Nem veletlenul lattam valahol, hogy a marketing anyagokban ezt domboritjak ki.
2. Olyan parhuzamos feladatoknal, amiknel egy thread is meglehetosen komplex, azaz profitalhat a nagy cache-bol, Out-of-Order vegrehajtasbol, elagazas becslesbol es minden okossagbol, es az egyes vegrehajto egysegeknek kommunikalniuk is kell egymassal. Pl mesterseges intelligencia algoritmusok. Vagy minden olyan algoritmus, ami ugyan parhuzamosithato, de kicsit nyogve-nyelosen, es a GPUGPU architekturanal az MIC jobban fekszik neki.