Aktív témák
-
BadGe
aktív tag
Üdv. programozó vagyok. és öreg. és már 2 napja nem ittam
(nem bélám, nem félredugásról beszélek...)
a címben javasolt beszélgetős témakör a legkevésbé sem triviális több szálas program végrehajtásról szól.... aki ért hozzá valószinűleg tudja miről beszélek.. akár csinálta (és szeretettel látjuk a javaslatait) akár csinálná (és akkor pedig a kérdéseinek örülük nagyon).
A témakör nagyon tág...
rögtön vitaindítónak egy saját sete-suta tapasztalat:
akkor érdemes valamit többszálúvá tenni ha a feldolgozás ideje emberi érzékszervekkel is mérhető.... (tizedmásodperces nagyságrend) viszont pl teljes mérékben érthetetlen számomra, hogy pl egy frame based játékban hogyan használhatunk több magot... oké megy +1 a fizikának.. és a többi?
ge.
<<< majd postolgatok, de mivel egyfelől ritkán hasznos a téma, másfelől nem is értek hozzá igazán, így nem igérem hogy ez önmagában érdekes "thread"-et eredményez majd. America needs YOU! >>>
-
BadGe
aktív tag
Gyönyörű firma vagyok, de TI sem panaszkodhatok. Mi a fenére kell az a sok proci ha senki nem használja? Bár a témával nem elsősorban ez volt a célom de a magok használatára algoritmusok szintjén alkalmas az úgynevezett OpenMP
természetesen el kell olvasnotok, és ha nem lenne egyértelmű akkor itt egy egyszerű példa:
#include <omp.h>
...
#pragma omp parallel for
for ( i = 0 ; i < ndxHeader; i++ )
{
NormalizeLine2( i, treshold, mincount );
}a fenti kód N x gyorsabblesz ha több proc-ot haszál a géped. A feladat szétosztása hatékonyabban történik mintha az oprendszer thread kezelő rutinjait használnánk. kicsit izés...
a példa nagyon egyszerűnek tűnhet, de kb ez volt az első ami tényelg működött. pl egy sima tömb feltöltés adatokkal nem igazán ad meggyőző eredményt. aztán pl nem lehet kiugrani a ciklusból, szóval minél egyszerűbb a végrehajtás annál jobb.
működés: a ciklusból a háttér rendszer annyi kis ciklust készít amennyi procod van és ezeket külön-külön elindítgatja. pl egy 1000000 ciklus esetén (szándékosan nagy a szám) lesz pl 4 ciklusod: 0..249999, 250000..499999 stb...
persze ennél kifinomultabb a dolog és bizonyos szinten szabályozható is.
stb.
de igazából engem egy platform független thread kezelő környezet érdekelne...
[ Szerkesztve ]
-
BadGe
aktív tag
fuck multithreading. 54 sec vs 2 sec, és nem 2 processzortól gyorsult 27szeresre a végrehajtás. (mióta két maggal gazdálkodok, a nyers erő bedőlése után mindíg rájövök, hogy dualcore nélkül is lehet gyorsítani).
vegyük ki a képletből hogy esetleg szar kóder vagyok. elvégre ha valami tud 27x gyorsabb lenni akkor elég szar lehetett az alap, de nem, az eset egyáltalán nem nyilvánvaló:
két egymásba ágyazott ciklus, kb 53000x53000 lefutással. (önállóan ez kb 2,5 mp valami kamu tevékenységgel)
a neheze természetesen a ciklusmagokon belül kezdődik, itt durva poligon/poligon tartalmazás vizsgálatok következnek ami poligononként sokezer pont esetén tényleg nem piskóta. Ez kb magyarázza is az 54 mp-es végrehajtást, végülis kivárható. (oké, durvább esetben volt ez 14 perc is, de azt most nem tudtam mérni, a lényeg hogy a lassúságot megmagyaráztam a feladat számításigényével (tényleg az))
az OMP kapcsán viszont elég gyorsan kiderül ha valami nem túl hatékony:
esetembem kis varázslás után elkezdett mindkét mag dolgozni, fasza, 50 helyett 100% proc terhelés, nézzük a futásidőt: 54 sec. basszameg.
ezután a ciklust annyira levágdostam hogy a végén már csak a két egymásba ágyazott 53000-es ciklus futott, szintén 54 másodpercig. pedig a durva poligonos műveleteket még el sem kezdte... (fent már írtam , hogy a nyers ciklus csak 2,5mp-ig futott volna)
kiderült, hogy az adatstruktúrák miatt kb 167GB adatot mozgatok (tulajdonképpen sima tömb[x].val tömb[y].val műveletek). 167 GB már sok szerintem a DDR-nek. nem számoltam nagyon pontosan utána. Maga a tömb 3,5 megás vagyis nem túl cache barát...
megoldás: szétdobáltam a végrehajtást egy 4x4 (később 6x6)-os mátrixba így egyszerre csak kisebb területek kevesebb (cache barát) adatmennyiségét kell feldolgoznom, egyébként pontosanugyanúgy mint eddig.
eszméletlen.
ezek után akkor most nekifoghatnék ismét egy kis többszálasításnak, de egyelőre minek most gyorsult 27x-re a program. a maradék 2-őt elteszem jövőre, hátha még akkor is tart a válság és már csak izomból gyorsíthatok
ge.
tehát tanulság: a cache csodákra képes. (a lefutás szám is csökkent, de mint írtam pusztán a ciklus végrehajtások önmagukban nem lettek volna ennyire lassúak, ha nem kell várakozniuk a memóriából becsordogáló adatokra).
ez azért fontos kérdés, mert mert a processzorok és a memóriák nem 27x gyorsabbak, nem lehet a végtelenségig szarul megírt programokkal újabb hardverekre várni.
persze ha nem lett volna a duplamag akkor még mindíg azt hinném, hogy a poligonok miatt lassú a végrehajtás.
Aktív témák
- MasterDeeJay: Volta a bányából azaz CMP 100-210 kisteszt (Tesla V100 mining)
- Telekom mobilszolgáltatások
- Kertészet, mezőgazdaság topik
- exHWSW - Értünk mindenhez IS
- Facebook és Messenger
- EAFC 24
- Házimozi haladó szinten
- OLED TV topic
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Vicces képek
- További aktív témák...
- Philips 58PUS8545/12 1 ÉV GARANCIA Játék üzemmód
- Tyű-ha! HP EliteBook 850 G7 Fémházas Szuper Strapabíró Laptop 15,6" -65% i7-10610U 32/512 FHD HUN
- Bomba ár! HP EliteBook 840 G5 - i5-8G I 8GB I 128GB SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- The Last of Us Part I Ps5
- Bomba ár! HP EliteBook 830 G6 - i7-8G I 8GB I 256GB SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!