Új hozzászólás Aktív témák
-
MaUser
addikt
A parallel.for-ral, cilk_for-ral, parfor-ral megmondod a fordítónak, hogy légyszíves csinálj nekem egyszerűen thread-eket amennyit bírsz és érdemes az erőforrások függvényében és végezd el ugyanazon műveletek az egyes thread-ekben. Ezt nem hiszem, hogy két perc alatt kódolod le, még ha snippetből dolgozol is vagy baromi gyorsan gépelsz, ráadásul itt egyből kapsz visszajelzést is gépelés közben, mert a környezetek ezt támogatják. HA olyan egyszerűek a műveleteid, hogy érdemes GPU-ra váltanod, akkor goto CUDA, az erre való.
Amiről te beszélsz az a szálak szinkronizálása, de ebben semmi új nincs, a szinkronizálás meg egy szál esetén is meg volt (pl. IRQ v. port figyelés, stb.). Ezt az életben nem fogod tudni elkerülni, mert a fordító soha nem fogja kitálni, hogy egymástól függő dolgokat, hol és hogyan akarsz te, mint programozó összefűzni és ennek semmi köze a CUDA-hoz.
-
pakriksz
őstag
parallel for az pont ugyan az az mintha csinálnál külön threadeket, csak rövidebben leírva.
Egyébként java-nál ugyan ezt lehet elérni egy sima forral, és egy executorservice-el.
De ez semmit nem old meg, amire ezt lehet használni, azt amúgy is 2 perc alatt lehet párhuzamosítani, szóval halottnak a csók effekt.Igen a szinkronizálással szívnak, de ez is a többszálúsítás legnagyobb mumusa.
-
MaUser
addikt
Most akkor dobjak fel egy fotót arról, hogy az adatbányászati alogritmusaim 4 szálon, gyakorlatilag 90% környékén használják a négymagos procit sima parforban PCT-vel?
A .net-es for párhuzamosításra meg MS-es előadást is tudsz találni, ha nem akarsz kézzel méricskélni.
Egyébként rálátok egy .net-es (jelenleg 3.0-ás verzióval van fordítva) játék játék fejlesztésére és sok profi programozó keményen megküzd a többszálúsítással, ami még így sem olyan amilyennek szeretnék bár ez részben a hulladék direct3d korlátainak köszönhető.
És ők mivel szívnak konkrétan? Gondolom nem azzal, hogy egyszerre négy szálon egymástól független adatokat feldolgozzanak, hanem azzal, hogy szinkronizálják a szálakat.
Gyanítom hogy ha ugyan ezt az xml-es cuccot kipróbálnám .net-ben, és 1 szálra írnám, a for ciklusban bambán egymás után dolgozná fel mindet, ahogy a java, és semmit sem ismerne fel.
Próbáld ki és kiderül. Ha nem vagy elégedett a kapott eredménnyel v. nem akarsz beállításokkal molyolni, akkor ott a Parallel.For utasítás és öröm boldogság egyből. Igaz, ez ha jól rémlik .net 3.5-től van, ellőtte külön kellett feltenni és talán nem is volt hivatalosan release-elve.
-
LordX
veterán
Ne keverjétek össze a task alapú párhuzamosítást és az adatpárhuzamosítást. Amit a .NET / Java / akármelyik mainstream programnyelv fordítója tud, az task és short vector (SIMD) párhuzamosságot, a CUDA meg adatpárhuzamosítást használja ki. A kettőnek azon kívül, hogy "párhuzamosítás", túl sok köze nincs egymáshoz. A CUDA felépítése miatt majdhogynem triviális azokat az optimizációkat automatikusan elvégezni, amiből ez a szál kiindult, nyugodtan elhiheted, hogy képes a fordító rá. És az is igaz, hogy nem ősrégi fordító (.NET 3.0 már annak számít) alapján kéne végső igazságokat kijelenteni, bár annyira nem eszik forrón a kását, a mai fordítók nem jól dolgoznak, hanem csak elfogadhatóan..
-
pakriksz
őstag
Hát már bocs de ezt nem hiszem el... Nem is nagyon létezhet olyan algoritmus ami felismer olyat amit egy embernek sem könnyű...
Ha ez igaz lenne, minden program gyönyörűen skálázódnak akárhány magra, de messze nem így van.
Egyébként rálátok egy .net-es (jelenleg 3.0-ás verzióval van fordítva) játék játék fejlesztésére és sok profi programozó keményen megküzd a többszálúsítással, ami még így sem olyan amilyennek szeretnék bár ez részben a hulladék direct3d korlátainak köszönhető.Java pedig kb csak abban a linkben van lemaradva kb (amire még mindig nem jöttem rá mi értelme (1 lépés előre 1 lépés hátra)), meg pár hasonló jelentéktelen dologban, engem csak az unsigned számok hiánya zavar.
Gyanítom hogy ha ugyan ezt az xml-es cuccot kipróbálnám .net-ben, és 1 szálra írnám, a for ciklusban bambán egymás után dolgozná fel mindet, ahogy a java, és semmit sem ismerne fel.
-
MaUser
addikt
A xlm-es példádra pont jók a modern fordítók, amit most batch-ként futtatsz, azt felismerik, ha van megkötés azt meg megtalálod a dokumentációban. Javával nem tudom mi a helyzet, már .net 2.0 idején is le volt már maradva, azóta szerencsére nem dolgozom vele, de ismerősök szerint az olló csak nyílik és nyílik.
A másik példánál, ha jól értem, arra kéne a több szál, hogy az interakció minél inkább real-time legyen. Ez tudományos/mérnöki életben nagyon ritka. Nyilván customer programnál ez kell, itt nincs mese, ezt kézzel kell. Azonban egy szálon is ugyanez volt a helyzet, itt nincs difi, csak most nem a programfutási szálat szakítgatod meg kézzel a bement kedvéért, hanem még kiegészül azzal, hogy a programfutási szálát a kívánt interakció mértékében több szálra szedheted szét.
-
pakriksz
őstag
mert ezzel a többszálúsítás kb 30%-át lehet megoldani. a többit szálkezeléssel kell.
Pl csináltam egy programot ami bazi nagy xml-eket módosít javaban. Bár az xml feldolgozó libek tényleg több szálúak, de 1 xml feldolgozása maximum 1,7 magot tudott leherhelni a 4 ből. És ilyenkor jön az hogy "batch"-ban indítom a feldolgozást, több szálon, így 1 helyett mondjuk 4 xml-el dolgozik párhuzamosan, így garantáltan kihasználódik mind a 2 mag.
Vagy megírsz egy játékot threading nélkül szinte semmit sem fog érni hogy néhány alaplib többszálú. Semmi sem fogja azt szétszedni több szálra a lényeget, neked kell szépen külön szálba rakni a rendert, a fizikát, a betöltést, a hangot.
-
MaUser
addikt
Már miért lenne édeskevés
Ezzel az esetek jó része megoldható. A gond ott van ha szálak között kell adatokat kezelned. Itt is két eset van, ha ritkán vannak ilyen esetek, akkor írtsz rá kézzel valami ütemezőt, ha meg gyakran kell szálak között adatokat átadni, akkor nyilván bukta. Ez esetben viszon goto másik algoritmust nézni, mert az esetek túlnyomó többségében lesz olyan, aminek a vége egymástól független vektor és/vagy mátrixművelet lesz. Nyilván lesz egy nagy overhead-ed, de párhuzamosítás miatt mégis jóval gyorsabb leszel. És főleg nem kézzel optimalizálgatsz és csinálsz a végén ugyan valamivel gyorsabb, de 10x nagyobb kódot 10x több hibával. -
MaUser
addikt
Az összes modernebb fordító tudja pl ma már azt, ha egy for ciklus nem függ a ciklusváltozótól/előző elemtől, akkor pl. több magra szét tudja dobni a ciklus lépéseit. Nyilván ez nagyon buta példa, de matlab már 1000 éve tudja, ha manuálisan parfor-t használsz akkor megfelelő számú worker-en fog futni a for ciklus. Nyilván innen egy lépés lenne, hogy a PCT méltóztasson ne csak futtatás közben felismerni, ha van ciklusfüggő változó, hanem már a kód írása közben. MS viszont már .net 3.0-át ezzel is hirdette, ott ráadásul sima for-t is szétdob a fordító több magra automatikusan, ha úgy látja, hogy megteheti. Jacket alatt meg ott van a gfor, ami megpróbál vektorizálni pl.
Nyilván a nem erőforrás igényes részeknek meg tökmindegy hány magon futnak.
Nyilván nem az lesz, hogy a fordító felismeri a gányolt fft-t és 4 magra csinál belőle egy olyan binárist mintha cilk fft-t használtál volna tökéletesen.
-
Fiery
veterán
-
Fiery
veterán
"Lásd jobb c/c#/c++ coding guide-ok mindig úgy kezdik, hogy ne akarj okosabb lenni a fordítónál"
Az a baj, hogy a C forditokkal ellentetben az OpenCL es CUDA forditok eleg butak tudnak neha lenni, nem art nekik egy kis segitseg. A CUDA 6 unified memory "varazslata" meg max. akkor mukodhet a gyakorlatban kielegitoen, ha relative keves masolasi muveletre jut egy csomo GPU szamolgatas (computing). Ellenkezo esetben ugyanolyan sz** lesz, mint egy nem atlapolt kezzel valo memoria masolasi megoldas. Teny, hogy a lusta programozoknak jol johet ez a kis segitseg; de aki lusta GPGPU fejleszto, es nem kotik a kezet guzsba (azaz valaszthat AMD es nVIDIA hardver kozul), az inkabb a HSA kornyeken fog nezelodni, ott legalabb valoban nincs szukseg memoria masolgatasra.
-
MaUser
addikt
Na ja, de ha ránézel egy .net vagy java kézzel párhuzamosított vs. automatikusan párhuzamosított kódra, rájössz miért fontos, mindez automatikusan történjen. 100-ból 99 programozónak lövése sincs az adott technológiához az api-k hívásán kívül.
Lásd jobb c/c#/c++ coding guide-ok mindig úgy kezdik, hogy ne akarj okosabb lenni a fordítónál, ha úgy hiszed többet tudsz, mint azok a srácok, akik azt írták, akkor szólj nekik és 10x-es pénzért fogsz náluk dolgozni.
-
Abu85
HÁZIGAZDA
Nem biztos. Ha azt feltételezed, hogy az adott program tényleg a végletekig le van optimalizálva, akkor nyilván az új CUDA semmit sem ér, de a valóság az, hogy a fejlesztők egy idő után feladják, mert aránytalanul sok munkát igényel a további extra teljesítmény kisajtolása, és ilyenkor bőven előfordulhat, hogy az új CUDA hatékonyabb lesz, mint az előző.
-
#11
polika
senior tag
Kotomicuki
#9
polika
senior tag
válasz
Kotomicuki
#9
üzenetére
Igazából én is már a reramot várnám, ahol a sleep/boot meg a mostani memória/háttértár paradigmák értelmüket vesztenék...
-
polika
senior tag
Tovább is mehetünk, egy általános automatizált copy mechanizmus sosem lesz olyan hatékony mint az egyénileg megírt kód. Azaz erős csúsztatás hogy csak minimális hátrányokat okoz.
Én inkább ennek az egésznek az értelmét abban látom hogy a CUDA 6-ot felkészítették az új egységes címteret címző arm/gpu párosra, miközben nem kell ugyanazt a progit egy másik régebbi hardverre újraírni. Az hogy ez a valóságban mennyire életszerű az más kérdés...CUDA5-öst nem éri meg portolni 6-ra régi hardveren mert nem lesz tőle jobb a teljesítmény, sőt valószínű csak roszabb...
-
#9
Kotomicuki
senior tag
Abu85
#6
Kotomicuki
senior tag
"Ami szarul fut az ezután is szarul fog futni, csak nem kell beleölnöd annyi munkaórát." - Ez, vhogy kifejezi az elmúlt évek poshadt állóvizét, ami a PC-t eddig jellemezte, de lassan, talán megmozdul vmi. No, nem teljesen a SW-esektől várom a megoldást, mert megfelelő "vas" nélkül csak az ehhez hasonló, fából vaskarikát megoldások születhetnek.
Majd, ha a közös RAM fizikailag is közös lesz, netán eltűnik a háttértár-RAM különállósága is, és az olyan szintű haszonelvűség, amit a (kis) kékek és mikrof*s bemutatott az utóbbi évtizedekben, kiveszik az iparágból, majd akkor jön el a látványos fejlődés kora, majd akkor láthatunk csudákat. -
-
Abu85
HÁZIGAZDA
A memóriák közötti szinkronizálást nem szünteti meg a CUDA 6, csak leveszi a terhet a válladról. Ami szarul fut az ezután is szarul fog futni, csak nem kell beleölnöd annyi munkaórát. De erre az NV-nek is megvan az integrációja, ami első körben a Maxwell és az ARMv8 párosítása. De ugye az IBM-mel dolgoznak a Poweren is, így a Maxwellt ahhoz is áttervezhetik.
(#7) Kopi31415: A hardver szintjén nem közös a címtér. A CUDA 6 csak annyit csinál, hogy amit eddig a programozó optimalizált, azt a háttérben megcsinálja helyette. Ettől függetlenül a memóriamásolás megtörténik. A beleölt munkaórában vagy előrébb.
-
MaUser
addikt
CUDA-ra vannak létező komoly rendszerek. Egyetemeken, fejlesztőcégeknél (mármint akik ténylegesen dolgoznak velük) 99%-ban CUDA van. Két nagy hátránya volt eddig, az egyik, hogy nV-only, ami annyira nem gond, mert AMD is hasonló áron van lényegesen. Ha jönnek a filléres kínai 3rd party-k akkor AMD-nek sem lesz esélye amúgy sem.
A másik pedig, hogy CPU-GPU közös műveletek nagyon lassúak voltak (futásidőben és fejlesztési időben is) a memóriák közötti állandó szinkornizálgatás miatt. Ez utóbbi most megszűnt. HSA "méregfogát" ezzel kihúzták gyakorlatilag, eddig ha valaki gondolkozott a migráláson, ezzel valszeg letesz róla. -
polika
senior tag
A HSA/hUMA-hoz képest ez az NV saját megoldása miben lesz más? Ahogy nézem hardveresen egy irányba konvergál a történet, hogy legyen egységes címtérben dolgozó CPU ill GPU. Annyira különbözik az alatta levő hardver hogy az nem lenne optimális NV-nek beállni a HSA mögé vagy ez inkább csak üzletpolitikai döntés?
)
Ezzel az esetek jó része megoldható. A gond ott van ha szálak között kell adatokat kezelned. Itt is két eset van, ha ritkán vannak ilyen esetek, akkor írtsz rá kézzel valami ütemezőt, ha meg gyakran kell szálak között adatokat átadni, akkor nyilván bukta. Ez esetben viszon goto másik algoritmust nézni, mert az esetek túlnyomó többségében lesz olyan, aminek a vége egymástól független vektor és/vagy mátrixművelet lesz. Nyilván lesz egy nagy overhead-ed, de párhuzamosítás miatt mégis jóval gyorsabb leszel. És főleg nem kézzel optimalizálgatsz és csinálsz a végén ugyan valamivel gyorsabb, de 10x nagyobb kódot 10x több hibával. 
Új hozzászólás Aktív témák
Hirdetés
ph Látszólag egységes memóriát kínál az NVIDIA a programozónak.
- AKCIÓ! ASUS PRO WS W790E-SAGE SE alaplap garanciával hibátlan működéssel
- Telefon felvásárlás!! Xiaomi Redmi 9, Xiaomi Redmi 9AT, Xiaomi Redmi 10, Xiaomi Redmi 10 2022
- Bomba ár! Lenovo ThinkPad T470 - i5-G6 I 8GB I 256GB SSD I 14" FHD I HDMI I Cam I W10 I Garancia!
- Azonnali készpénzes Microsoft XBOX Series S és Series X felvásárlás személyesen/csomagküldéssel
- AKCIÓ! Gigabyte AORUS 16X (2024) Gamer notebook - i7 14650HX 16GB RAM 1TB SSD RTX 4070 8GBWin11
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest