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

• #76 Pikari veterán LordX #75

  Új Válasz 2013-05-19 17:21:01 #76

  Ú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

  

  Pikari

  veterán

  válasz LordX #75 üzenetére

  már rég nem arról beszélünk, jóreggelt

• #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.

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