Új hozzászólás Aktív témák
-
#34
Tybee000
aktív tag
killerjohn
#6
Tybee000
aktív tag
válasz
killerjohn
#6
üzenetére
profin átírtunk több ezer sor kódot, trükkös adatkezeléssel, stb, hogy alkalmas legyen a kód párhuzamosításra. 100x átnéztük, hogy ne legyenek deadlockok, sőt ha lehet akkor lockok se legyenek, minden szál saját maga melózik, stb stb stb. Na, szóval rászántuk az időt, nem csak egy for ciklust akartunk átírni paraller.for-rá..... ennek ellenére az eredmény annyira elkeserítő lett, hogy néztünk mint maci a moziban. Adtunk neki időd, rászántunk még egy hetet, finomítgattuk, próbálkoztunk "hátha most jobb lesz" alapon. Nope. Nothing. SVN revert. Aztán volt hogy 4 magon 50%-al volt gyorsabb 400% helyett.
Itt az utolsó mondatot tényleg komolyan gondoltad? Az 50% neked kevés? Amdahl törvényét ismered?
https://sites.google.com/site/szgarch/jegyzet/multiprocesszoros-rendszerek
3.2es fejezet -
ddekany
veterán
Annak alapján amit ebből minden utánaolvasás nélkül levettem, ezek a megszorítások csak a párhuzamosan futó szálak közti viszonyra vonatkoznak, azaz a szálon belül (mint pl. a parallel_for_each-nál az egy elem feldolgozásáért felelős programrészen belül) akármilyen elágazást/feltételes ugrást használhatsz.
-
LordX
veterán
Az ok, de még mindig nagyságrendekkel nagyobb büntetés egy elágazás egy GPU-nak, mint egy CPU-nak SSE kóddal.
Kb. az egyetlen "GPU" amire ez "nem" igaz, az a Larrabee lenne, mivel abban gyakorlatilag Atom magok a végrehajtó egységek, ott is csak "nem" igaz, mert egy full-feature (pl. SandyBridge) CPU-ban jobb elágazásbecslés van, tehát jóval kisebb az elágazások negatív hatása. Az AMD GCN-je is egy lépés ez irányába, de mivel 1 db branch unit van egy CU-ban, erősen gyanítom, hogy az is csak kisebb hatékonysággal tud becsülni (ha egyáltalán becsül, mert nem találtam erről cikket).
-
flugi
tag
a conditional move elég jó megoldás, mert úgyis mindkét elágazásoldalt érdemes kiértékelni, lévén a feltételes utasításvégrehajtások is pont annyi ideig futnak mindkét esetben, és így nem kell megbontani a pipeline-t (sőt, kevés szálnál képes átfedésre az NVidia, ha az egymást követő utasítások nincsenek egymásra hatással, tehát ha van egy klasszikus
ha X akkor
A1
A2
A3
A4
különben
B1
B2
B3
ha_végekódod, akkor az optimális GPU kód az, hogy
A1
B1
A2
B2
A3
B3
A4
predikátum := X
@X eredmény = A4|B3 eredménye -
dezz
nagyúr
Volt egy ideig, de egyre kevésbé, hiszen a minél hatékonyabb GPGPU-s felhasználás az egyik fő cél évek óta (nem csak szavakban).
(#28) P.H.: Én nem látom, hogy a C++ AMP a HSA ellenfele lenne. (Sőt még talán a DirectCompute sem.) A HSA egy hw szintű specifikáció, aminek széles körű támogatása a hw gyártók részéről az egységes hw-kialakítás (már azon a szinten, amit a sw-ek és driverek látnak belőle) által elősegíti a sw gyártók heterogén/GPGPU irányba történő elmozdulását és megkönnyíti a MS dolgát is. Nem gondolom, hogy a HSA ilyen tekintetben akár az OpenCL-nek kedvezne, inkább talán fordítva, elősegítheti a C++ AMP egyszerűbb és zökkenőmentesebb alkalmazhatóságát, miáltal a "hétköznapi" programozók, akik amúgy is idegenkednek az OpenCL-től, jobban rákaphatnak a másikra. Az OpenCL meg megmaradhat az elszántabbaknak, akik kevésbé akarnak a compilerre hagyatkozni. (Inkább talán az a kérdés, hogy a HSA és a CUDA összeférhet-e valahogy egymással.)
-
P.H.
senior tag
Ehhez nagyban hozzájárul a feltételes utasításvégrehajtás is. De pl. azon GPU-architektúrák, amelyek nem támogatják ezt, ott bonyolódik a helyzet. Két példa:
NV PTX ISA: "Instructions are formed from an instruction opcode followed by a comma-separated list of zero or more operands, and terminated with a semicolon. Operands may be register variables, constant expressions, address expressions, or label names. Instructions have an optional guard predicate which controls conditional execution. The guard predicate follows the optional label and precedes the opcode, and is written as @p, where p is a predicate register. The guard predicate may be optionally negated, written as @!p."
Az ARM is ismeri az alap utasítások jó részében a feltételes végrehajtást, azaz csak akkor hajt végre valamilyen (predicate-bit által) megjelölt utasítást, ha az előző valamelyik utasítás eredménye pl. 0 vagy negatív, stb.
AMD GCN:
Scalar ALU operations:
Compare (integer, bit, min/max), move and conditional move (select operations based on SCC)
A GCN ismeri a feltételes utasításvégrehajtást? Vagy csak azt a megközelítést, ami x86/x64-en is van?Mindegyik gyártó a saját alapjai felé dolgozik, a C++ AMP viszont gyártófüggetlen szoftveres megközelítés, nyilvánvaló érdeke, hogy elterjedjen mindenhol és mindenen. Ezzel lenne (nem csak az OpenCL, hanem) a CUDA és a HSA ellenfele is.
-
P.H.
senior tag
Correctly Synchronized C++ AMP Programs alatt:
All the threads that are launched by a parallel_for_each are potentially concurrent. Unless barriers are used, an implementation is free to schedule these threads in any order. In addition, the memory model for normal memory accesses is weak; that is, operations can be arbitrarily reordered as long as each thread executes in its original program 2808 order. Therefore, any two memory operations from any two threads in a parallel_for_each are by default concurrent, unless the application has explicitly enforced an order between these two operations by using atomic operations, fences, or barriers.
Conversely, an implementation may also schedule only one logical thread at a time, in a non-cooperative manner; that is, without letting any other threads make any progress except for hitting a tile barrier or terminating. When a thread encounters a tile barrier, an implementation must wrest control from that thread and provide progress to some other thread in the tile until they all have reached the barrier. Similarly, when a thread finishes execution, the system is obligated to execute steps from some other thread. Therefore, an implementation is obligated to switch context between threads only when a thread has hit a barrier (barriers pertain just to the tiled parallel_for_each), or is finished. An implementation does not have to admit any concurrency at a finer level than that which is dictated by barriers and thread termination. All implementations, however, are obligated to ensure that progress is continually made, until all threads that are launched by a parallel_for_each are completed.
An immediate corollary is that C++ AMP does not provide a mechanism that a thread could use, without using tile barriers, to poll for a change that has to be effected by another thread. In particular, C++ AMP does not support locks that are implemented by using atomic operations and fences, because a thread could end up polling forever, while waiting for a lock to become available. The usage of tile barriers enables the creation of a limited form of locking that is scoped to a thread tile.
Nem nagyon szeretem a negatív hozzállást egy-egy megvalósuló témához, de ez "szép": több, egymást követő parallel_for_each közt nem tud kükönbséget tenni, ezt programban kell külön lekezelni... (Tile barrier vagy egy thread-finished számláló alkalmazása) már rég rossz, ha a programozási környezet nem szinkronizál automatikusan egy-egy "ciklus" lefutása után.
Informative: More often than not, such non-deterministic locking within a tile is not really necessary, because a static schedule of the threads that is based on integer thread IDs is possible, and results in more efficient and more maintainable code. But we bring this example here for completeness and to illustrate a valid form of polling.
Informative: This requirement, however, is typically not sufficient to allow for efficient implementations. For example, it allows for the call stack of threads to differ, when they hit a barrier. To be able to generate good quality code for vector targets, much stronger constraints should be placed on the usage of barriers, as explained later.
Later:
C++ AMP requires that, when a barrier is encountered by one thread:
1. That the same barrier will be encountered by all other threads in the tile.
2. That the sequence of active control flow statements and/or expressions be identical for all threads when they reach the barrier.
3. That each of the correspondng control expressions be tile-uniform (which is defined below).
4. That any active control flow statement or expression has not been departed (necessarily in a non-uniform fashion) by a break, continue, or return statement. That is, any breaking statement that instructs the program to leave an active scope must in itself behave as if it was a barrier; that is, it must adhere to the four preceding rules.Leírták pl. az SSE (Streaming SIMD Extensions értelmi) lényegét: nincs elágazás, nincs feltételes ugrás (= nincs kódátlépés-és-folytatás), csak ugyanazon kód lefutása minden elemre.
Ez így eléggé konzervatív és CPU-központú megközelítés. -
#24
Alchemist
addikt
killerjohn
#22
Alchemist
addikt
válasz
killerjohn
#22
üzenetére
Nekem is hasonló tapasztalataim vannak... vagy van egy eleve párhuzamos feldolgozásra optimális algoritmus, rendszerkörnyezettel támogatva... vagy lehet próbálkozni kőből vizet facsarni.
-
#23
flugi
tag
killerjohn
#22
flugi
tag
válasz
killerjohn
#22
üzenetére
ez nem bug, ez egy feature hiánya. Bug az lett volna, ha tönkrefagytok a le nem védett versenyhelyzetben.
-
#22
killerjohn
addikt
flugi
#21
killerjohn
addikt
kösz szépen, aranyos vagy.
amíg a hasonló volumenű bugokat, problémákat nem oldják meg, addig mit is akarnak a párhuzamosítással? tessék előbb "belül" párhuzamosítani, aztán majd ha a keretrendszer belseje gyors és szép, és bizonyítja, hogy van helye a "hétköznapi" szoftverfejelsztésben is a technológiának, na AKKOR fogunk párhuzamosítani. Addig meg egyszerűen üzletileg, stratégialig nem érdemes még csak beszélni sem róla. (legalábbis nálunk)
-
#21
flugi
tag
killerjohn
#6
flugi
tag
válasz
killerjohn
#6
üzenetére
mégsem volt profi az átírás
Ezért szeretem azokat a nyelveket, amik dokumentáció nélkül is lekövethetőek, mint a C++, ahol nincs ilyen gond az STL esetében.
-
#19
lenox
veterán
killerjohn
#15
lenox
veterán
válasz
killerjohn
#15
üzenetére
Nem tudom, mit csinaltok pontosan, de nem lehetne olyan ojjektumot hasznalni, aminek nem kozos poolja van? Pl. threadenkent egy map-et?
-
#18
ddekany
veterán
killerjohn
#15
ddekany
veterán
válasz
killerjohn
#15
üzenetére
"de maga a linq, mint iteratorokra alapuló, lassú szemétkupac annyival lassabb, mint egy rendesen megírt kód"
Egy adatbázis csesztetésre készült cuccban az iterátorokon alapulás a szűk keresztmetszet (vagy bármi, ami a CLR-en belül fut)?
-
#17
oO7
őstag
killerjohn
#15
oO7
őstag
válasz
killerjohn
#15
üzenetére
nem kell 100GB RAM mert valójában párhuzamosan (mondjuk géptől függően) a processzorok / processzormagok számának mondjuk 2-4x -ese mennyiségű szál fog futni egy időben... attól még, hogy van egy 10000 elemből álló adathalmazod amit párhuzamosan szeretnél feldolgzoni, a rendszer nem fog neked 10000 szálat indítani, hanem a hardver képességeihez igazítva, egy sima desktopon 2-4-8 vagy kb max 16 osával fog végigosonni párhuzamosan az adathalmazon...
-
#16
LordX
veterán
killerjohn
#15
LordX
veterán
válasz
killerjohn
#15
üzenetére
Most lehet hülye kérdés, de biztos, hogy stringeket akartok ti összehasonlítani? Van egy olyan érzésem, hogy valójában nem..
-
#15
killerjohn
addikt
LordX
#13
killerjohn
addikt
mondtam én hogy nem? köszi hogy elmagyaráztátok ketten is az intern-t
viszont ennyi erővel kb fújhatom az egészet, mivel intern nélkül kellene még 100 GB RAM
biztos vagyok benne hogy meg tudnák oldani ez hatékonyabban is... (mármint az intern belső mechanizmusát)a plinq-et meg inkább hagyjuk, mert oké hogy párhuzamosított, de maga a linq, mint iteratorokra alapuló, lassú szemétkupac annyival lassabb, mint egy rendesen megírt kód, hogy szvsz a párhuzamosítás miatt sem éri meg használni. ha nálunk valakinek a kódjában meglátom a linq szót, vagy a foreach-et, akkor első, majd második figyelmeztetés, aztán fired (idáig még senki sem merészkedett
)... -
ddekany
veterán
"a párhuzamosságnak két verziója van... a Task Parralell (amit a TPL lefed) és a Data Parallel (amit a C++ AMP nyújt)"
Nem tudom érdemes-e erre így nézni. Az OpenCL pl. már igencsak eltávolodott a Data Parallel megközelítéstől. Sokkal inkább olyan, mintha ha lenne sok pici CPU-d, mindegyiken fut egy kernel (nem az OS-es értelemben). Más kérdés hogy általában valami tömb szeletit osztod ki nekik ledarálásra.
-
#13
LordX
veterán
killerjohn
#10
LordX
veterán
válasz
killerjohn
#10
üzenetére
Err? (Java?) Most hülyéskedsz? Az intern függvény pont arról szól, hogy minden string ami a programban (package-ben) van közös poolt használjon - ha nincs benne, akkor belerakja, és visszaadja a referenciát a pool-beli okbjektumra. Innentől ez triviális, hogy globális zárolást okoz. Ha közös poolt használsz (bármire) párhuzamos kódból, akkor ne lepődj már meg, hogy szar lesz a teljesítmény..
-
#12
oO7
őstag
killerjohn
#6
oO7
őstag
válasz
killerjohn
#6
üzenetére
"azt nem értem, miért nem építik be a .NET nyelvekbe. Pl C#-ban ez killer feature lenne. A task parallel library-t meg inkább hagyjuk, mert rengetek esetben lassabb 4 magon futtatni a kódot, mint 1 magon..."
a párhuzamosságnak két verziója van... a Task Parralell (amit a TPL lefed) és a Data Parallel (amit a C++ AMP nyújt)...
az egyik esetben teljesen különböző feladatokat futtatsz párhuzamosan jó esetben egymástól teljesen függetlenül, a másik esetben pedig egészen pontosan ugyanazt a műveletet futtatod rengeteg magon (GPGPU) csak épp mindegyik mag más adaton dolgozik...
másképpen megfogalmazva, az egyik csak egyszerűen több szál párhuzamos futtatása, lényegében a Thread utódja (a Task), a másik pedig egy SIMD működési elv...a TPL-t használni DPL feladatokra nem mondom, hogy nem lehet, hiszen nem véletlenül van ott a PLINQ sem meg egy Parallel For / Foreach működésében már egészen hasonlít egy DPL-re, de a lényeg, hogy a szálkezelés költséges dolog és rengeteg overhead-el jár... ha nagyon pici számításod van, akkor lehet, hogy a szálkezeléssel járó feladatok több ideig fognak tartani mint a lényegi kód végrehajtása, és hiába dolgozod fel párhuzamosan a nagy adathalmazt, ha ennek az overheadnek a mértéke meghaladja a lényegi kód mértékét (időben / mennyiségben ha IL kódot nézegetsz)
-
#11
ddekany
veterán
killerjohn
#10
ddekany
veterán
válasz
killerjohn
#10
üzenetére
Ezek szerint mégiscsak meglett a bottleneck. Elvégre az intern lényege, hogy a VM-en belül minden, és így mind szál is, ugyan azt a példányt használja több egyforma tartalmú String helyett. Persze ha nem használsz internt, akkor meg meglehet azért lesz lassabb, elvégre az inten sem viccből van (pl. gyorsíthatja az összehasonlításokat). Azaz, a feladat esetleg eredendően nem párhuzamosítható hatékonyan.
-
#10
killerjohn
addikt
lenox
#9
killerjohn
addikt
nincs bottleneck, sokkal magasabb mértékű gyorsulás volt várható, tekintettel arra hogy a szálak egymáshoz nem is nyúlnak, csak a munka (99.999% munka) befejeztével kivágják egy közös listába az eredményeket (0.001% munka). string feldolgozásról volt szó, és gyanúnk szerint a string.Intern() funkció (dokumentálatlanul) valami globális zárolást alkalmaz - funkciója szerint ez még akár indokolt is lehet, de akkor legalább ledokumentálnák, mert így gyakorlatilag az ezt hívó kódrészletek nem párhuzamosíthatók. na erre varrjak gombot...
-
lenox
veterán
Ezen a ponton a legjobb megoldást az APU-k képzik
Mondjuk ezt eleg meresz kijelenteni, igy feladattol fuggetlenul. Csak van azert olyan feladat, amire nem apu a legjobb, meg egyelore eleg kicsi az apuk aranya, szoval fura lenne, ha csak azokra lenne kihegyezve a c++ amp.
#6: Az mondjuk fura, ha ugy irtatok at, hogy nem voltatok tisztaban vele, hogy mik a bottleneckek, es milyen gyorsulas varhato.
-
#8
Löncsi
őstag
killerjohn
#6
Löncsi
őstag
válasz
killerjohn
#6
üzenetére
Nem vagyok szál-szakértő, de több esetben is hallottam a "nagyoktól" nyilatkozatokat, hogy csak ott érdemes szálasítani ahol előnyösebb mint 1 szálon futtatni. Nyilván itt is ilyesmi lehet majd a dolog, ahol sok egyszerű, párhuzamosítható feladat van, arra jól jön a GPU, nyomsz egy restrict(amp)-t és mehet a buli.
-
#6
killerjohn
addikt
Löncsi
#5
killerjohn
addikt
profin átírtunk több ezer sor kódot, trükkös adatkezeléssel, stb, hogy alkalmas legyen a kód párhuzamosításra. 100x átnéztük, hogy ne legyenek deadlockok, sőt ha lehet akkor lockok se legyenek, minden szál saját maga melózik, stb stb stb. Na, szóval rászántuk az időt, nem csak egy for ciklust akartunk átírni paraller.for-rá..... ennek ellenére az eredmény annyira elkeserítő lett, hogy néztünk mint maci a moziban. Adtunk neki időd, rászántunk még egy hetet, finomítgattuk, próbálkoztunk "hátha most jobb lesz" alapon. Nope. Nothing. SVN revert. Aztán volt hogy 4 magon 50%-al volt gyorsabb 400% helyett. Na, azért annyire nem olcsó a vas, hogy más szolgáltatások alól zabáljuk ki az erőforrást, szóval ott is SVN revert. Most ha belegondolok, hogy ebbe bevonják a GPU-t, akkor SEM tudom elképzelni, hogy pár számításintenzív, kifejezetten, dúrván erre optimalizált alkalmazás (videófeldolgozás, stb) kivételével értelme lenne. Félreértés ne essék, nem flameelni akarom a technológiát - én lennék a legboldogabb ha ez közel líneárisan skálázódna... -
#5
Löncsi
őstag
killerjohn
#4
Löncsi
őstag
válasz
killerjohn
#4
üzenetére
mert rengetek esetben lassabb 4 magon futtatni a kódot, mint 1 magon...
Doesn't matter, had massive-parallel computing.
-
#4
killerjohn
addikt
killerjohn
addikt
azt nem értem, miért nem építik be a .NET nyelvekbe. Pl C#-ban ez killer feature lenne. A task parallel library-t meg inkább hagyjuk, mert rengetek esetben lassabb 4 magon futtatni a kódot, mint 1 magon...
-
#3
Jhonny06
veterán
Meteorhead
#2
Jhonny06
veterán
válasz
Meteorhead
#2
üzenetére
Khronos? Are you fucking kidding me? Az OpenCL specifikációja legalább ennyire tele van szemetelve, nem olvashatóbb, mint ez (hozzáteszem, hogy ezzel sincs semmi probléma szerintem, ha nem tudod olvasni, az user error).
-
#2
Meteorhead
aktív tag
Meteorhead
aktív tag
Nem azért, de elég trágya specifikáció ez. Nemigen találkoztam még olyan dokumentummal, amit teleszemeteltek volna magával az interfésszel kód formátumban. Ha legalább a végén lenne az egész, és minden fejezetben egy rá mutató link...
Engem érdekelne a cucc, de olvashatatlan. Tanulhattak volna a fiúk a Khronosoktól, ők legalább tudnak doksit írni.
biztos vagyok benne hogy meg tudnák oldani ez hatékonyabban is... (mármint az intern belső mechanizmusát)
profin átírtunk több ezer sor kódot, trükkös adatkezeléssel, stb, hogy alkalmas legyen a kód párhuzamosításra. 100x átnéztük, hogy ne legyenek deadlockok, sőt ha lehet akkor lockok se legyenek, minden szál saját maga melózik, stb stb stb. Na, szóval rászántuk az időt, nem csak egy for ciklust akartunk átírni paraller.for-rá..... ennek ellenére az eredmény annyira elkeserítő lett, hogy néztünk mint maci a moziban. Adtunk neki időd, rászántunk még egy hetet, finomítgattuk, próbálkoztunk "hátha most jobb lesz" alapon. Nope. Nothing. SVN revert. Aztán volt hogy 4 magon 50%-al volt gyorsabb 400% helyett. Na, azért annyire nem olcsó a vas, hogy más szolgáltatások alól zabáljuk ki az erőforrást, szóval ott is SVN revert. Most ha belegondolok, hogy ebbe bevonják a GPU-t, akkor SEM tudom elképzelni, hogy pár számításintenzív, kifejezetten, dúrván erre optimalizált alkalmazás (videófeldolgozás, stb) kivételével értelme lenne. Félreértés ne essék, nem flameelni akarom a technológiát - én lennék a legboldogabb ha ez közel líneárisan skálázódna...
Új hozzászólás Aktív témák
ph Az új platform a Visual Studio 11-ben lesz hivatalosan elérhető.
- Kezdő fotósok digitális fényképei
- Assassin’s Creed Shadows teszt
- Apple asztali gépek
- Tesla topik
- Vezetékes FEJhallgatók
- Mr Dini: Mindent a StreamSharkról!
- Melyik tápegységet vegyem?
- Milyen videókártyát?
- Meggyi001: Telefonjaim a kezdetektől máig, avagy: My phone's antology
- Apple MacBook
- További aktív témák...
- Csere-Beszámítás! MSI Ventus 3X RTX 4070Super 12GB GDDR6X Videokártya!
- ASRock RX 6950 XT 16GB GDDR6 Phantom Gaming OC - Gari 2026.05.02. -ig - Eladó!
- MSI GTX 1080 ARMOR
- ASUS RX 6800 16GB GDDR6 TUF GAMING OC - Dobozos, Újszerű - Eladó!
- ASRock RX 7800 XT 16GB GDDR6 Challenger OC - Új, bontatlan, 3 év garancia - Eladó!
- Csere-Beszámítás! RTX Számítógép játékra! I9 13900K / RTX 4080 / 32GB RAM / 1 TB SSD
- iKing.Hu - Apple MacBook Pro 13 M1 Touch Bar 2020 Használt, karcmentes 3 hónap garanciával
- Beszámítás! Xiaomi Redmi 9 64GB mobiltelefon garanciával hibátlan működéssel
- BESZÁMÍTÁS! Gigabyte H610M i5 12400F 16GB DDR4 512GB SSD RX 6700XT 12GB Zalman S2 TG Seasonic 650W
- Hp USB-C/Thunderbolt 3 dokkolók: USB-C Universal, G2, G4, G5, Hp Elite/Zbook- Thunderbolt 4 G4
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest