- Intel Core i5-7640X / i7-7740X "Kaby Lake-X" és i9-7xxx "Skylake-X" (LGA2066)
- Samsung LCD és LED TV-k
- Androidos tablet topic
- Azonnali VGA-s kérdések órája
- Nem indul és mi a baja a gépemnek topik
- AMD Navi Radeon™ RX 7xxx sorozat
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Milyen HASZNÁLT notebookot vegyek?
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Xiaomi Pad 6 - kiapadhatatlan jóság
Hirdetés
-
Közönségkedvenc Galaxy vált One UI 6.1-re
ma Ezen a héten sem tétlenkedett a Samsung szoftverfejlesztő csapata.
-
Békésen legelészik a májusi hardvercsorda
ph Ezúttal monitorokat, processzorhűtőt, házat, routert, tápokat, egérpadot és akciókat tereltünk be a szombati karámba.
-
Sikeres volt a teszt, elpusztítja internetes műholdjait az Amazon
it Az Amazon szerint minden sikerrel zárult, ezért letéríti az internetes műholdprototípusokat a pályájukról a cég.
Új hozzászólás Aktív témák
-
Löncsi
őstag
Könnyed 131 oldal, az ember unalmas óráiban olvasgathatja.
Elvették a radírját, azt az egész élete egy nagy kompenzálás, hogy ő igenis kan és igenis 2 méteres a fallosza - by stranger28
-
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.
-
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).
-
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...
-
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.
Elvették a radírját, azt az egész élete egy nagy kompenzálás, hogy ő igenis kan és igenis 2 méteres a fallosza - by stranger28
-
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...
-
LordX
veterán
2012-ben C++0x-nek hívni a C++11 szabványt.. nem bölcs dolog.
-
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.
[ Szerkesztve ]
Elvették a radírját, azt az egész élete egy nagy kompenzálás, hogy ő igenis kan és igenis 2 méteres a fallosza - by stranger28
-
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.
[ Szerkesztve ]
-
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...
-
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.
[ Szerkesztve ]
-
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)
-
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..
-
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.
-
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 )...
-
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..
-
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...
-
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)?
-
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?
-
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.
[ Szerkesztve ]
-
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)
-
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.
-
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.
Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.
-
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.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
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.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
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.)
[ Szerkesztve ]
-
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 -
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).
-
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.
-
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
Új hozzászólás Aktív témák
- Intel Core i5-7640X / i7-7740X "Kaby Lake-X" és i9-7xxx "Skylake-X" (LGA2066)
- Kínai, és egyéb olcsó órák topikja
- OnePlus 7 - magabiztos folytatás
- Robot fűnyírók
- Genshin Impact (PC, PS4, Android, iOS)
- Samsung LCD és LED TV-k
- Milyen program, ami...?
- Androidos tablet topic
- Politika
- Ukrajnai háború
- További aktív témák...
- Sapphire Pure Radeon 7700 XT AMD 12GB GDDR6
- Asus V8460 Ultra ( Geforce 4 Ti 4600 )
- ASUS TUF Gaming GeForce RTX 4070 Ti 12GB
- ASUS RTX 4090 24GB GDDR6X TUF Gaming OC Edition - Új, bontatlan - Eladó! 650.000.-
- BESZÁMÍTÁS! Gainward Phoenix RTX 3090 24GB GDDR6X videokártya garanciával hibátlan működéssel
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen