2. Fórumok
  3. Szoftverfejlesztés
  4. multi-threading avagy: használjuk magvainkat!
  5. (téma lezárva)

Aktív témák

  • #5 proof88 addikt BadGe #4
    #5
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    proof88

    addikt

    válasz BadGe #4 üzenetére

    és a mátrixokat jó irányba járod be? mert ugye az is számít, hogy soronként vagy oszloponként haladsz. :K

  • #4 BadGe aktív tag
    #4
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    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.

  • #3 Jester01 veterán BadGe #2
    #3
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Jester01

    veterán

    válasz BadGe #2 üzenetére

    Rengeteg platform független thread könyvtár van. De nem olyan mint az említett OpenMP, a szálakat neked kell kezelni.

  • #2 BadGe aktív tag BadGe #1
    #2
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    BadGe

    aktív tag

    válasz BadGe #1 üzenetére

    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...

  • #1 BadGe aktív tag
    #1
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    BadGe

    aktív tag

    Üdv. programozó vagyok. és öreg. és már 2 napja nem ittam :K

    (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! >>>

Aktív témák