- Crypto Trade
- Az iPadOS-re írt appokra is díjat vet ki az Apple
- Milyen NAS-t vegyek?
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- A franciáknak elege van abból, hogy minden gyerek mobilozik
- A pápa egyre jobban tart a romlott AI veszélyeitől
- Letartóztatták a bitcoin-Jézust
- SkyShowtime
- WLAN, WiFi, vezeték nélküli hálózat
- foobar2000
- gban: Ingyen kellene, de tegnapra
- Szevam: Érzelmi magabiztosság/biztonság - miért megyünk sokan külföldre valójában?
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
Új hozzászólás Aktív témák
-
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?
-
freeapro
senior tag
Érdekes, hogy az AMD mennyivel jobban tudja tematizálni a technológiai híreket az OpenCl-el vagy a Mantle-vel mint az Nvidia a Cuda-val, pedig nagy vonalakban ugyanazt a célt követik.
-
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.''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#06658560
törölt tag
-
Crytek
veterán
És milyen jó is lenne nekünk játékosoknak ha ne adj isten összefognának és lenne egy brutális egységes rendszer ami a kenyérpiriton is elmegy nem csak akkor ha x és y VGA-d van!
Next PC Upgrade: 2022
-
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.A regisztrációdat véglegesen kitiltottuk a következő ok miatt: III.10.8 Üdvözlettel: PROHARDVER!
-
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...
-
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...
-
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ő.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
pakriksz
őstag
Micsoda? automatikusan párhuzamosított kód? Azt hogy?
[ Szerkesztve ]
Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
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.
[ Szerkesztve ]
-
pakriksz
őstag
gondolom alap java libes függvényeket átírnak gpu-ra is. De ettől még nem fog egy programot párhuzamosítani, csak pár részfeladatát.
Igazi működő automatikus párhuzamosítás CPU-ra sincs.Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
Fiery
veterán
A legtobb szoftvernel eleg csupan reszfeladatokat, meghozza a leginkabb teljesitmeny-erzekeny reszfeladatokat parhuzamositani. Ha azt meg tudja oldani akár a CUDA, akár a HSA, akár barmi mas hatekonyan es egyszeruen, az mar eleg jo lesz a legtobb fejlesztonek.
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
pakriksz
őstag
Ez édeskevés, tehát marad továbbra is a szenvedés a többszálúsítással.
[ Szerkesztve ]
Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
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.
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
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.
[ Szerkesztve ]
Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
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.
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
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.
[ Szerkesztve ]
Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
Jack@l
veterán
Lehet át kéne térni .net 4.5-re, me a 3-as má ölég régi jószág... (meglepődnél mik nem vannak benne többszálúsításhoz )
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
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..
-
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.
[ Szerkesztve ]
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
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.
Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
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.
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
Új hozzászólás Aktív témák
- Hibátlan - PALIT GTX 1650 StormX 4GB GDDR5 VGA videókártya - tápcsatlakozó nélküli !!!
- ASUS ProArt GeForce RTX 4080 SUPER 16GB GDDR6X OC (ASUS-VC-PRO-RT4080S-O16G) Bontatlan új 3 év gar!
- BESZÁMÍTÁS! GIGABYTE WindForce 2X GTX 960 4GB GDDR5 videokártya garanciával hibátlan működéssel
- Legújabb Nvidia Quadro RTX 4000 Ada Generation 20 GB új garis eladó
- XFX RX 6600 XT SPEEDSTER SWFT 210
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest