Hirdetés

  2. Fórumok
  3. Szoftverfejlesztés
  4. Hogyan / Hogyan ne programozzunk?
  5. (téma lezárva)
Keresés

Aktív témák

  • #168 P.H. senior tag
    #168
    Ö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

    P.H.

    senior tag

    Protezis #163 és #166

    A "túlmisztifikálás" kicsit erős volt, nem tagadom, de nem sokkal több az elméleti háttere, mint amit leírtam, az alkalmazása az adott szituációtól függ (és jó úton indultál el #166-ban: képzeld mondjuk ezt el egy 3x3 helyett 3000x3000-es mátrixra, egy vs. több szálon). Elméleti síkon (oktatásban) arra lehet elmenni nagyon messzire, hogy critical section-ök, összehangolás (amik közösadat-elérésnél mindig előjönnek, lásd adatbázisok), de tervezési fázisban ezek száraz tények, megvalósítási megközelítésben sem annyira fontos annyira ez, csak az OS-adta segítségek ismeretéig.

    Egy példa:
    A korábbiakban felmerült ebben a topikban a Dijkstra-algorimus. A legtöbb idő és energia azzal megy el, hogy megtaláld ezt és az ehhez kellő adatábrázolást, mint ideális megoldást az adott problémára. Magát az alapalgoritmust épeszű embernek nem jutna eszébe párhuzamosítani, mert többet veszt vele, mint nélküle. Viszont ha a - kapcsolatokra - alkalmazandó dinamizmus sokkal összetettebb és időigényesebb, mint amennyit a leírt alapadminisztráció megkövetel, akkor érdemes lehet elgondolkodni azon, hogy az épp feldolgozott ponthoz csatlakozó élek végleges súlyát ne párhuzamosan számoltassuk-e ki (a tárolás mellett többek között ezért fontos a listás gráfmegközelítésnél, hogy a lehetséges maximális kapcsolatszám egy ponthoz ismert-e).

    (Emlékszem persze - 0 amúgy :) -, de nem akarok se szembemenni, se megerősíteni azt az oktatási nézőpontot, amiben én voltam: sok jót tudok mondani róla, de sok rosszat is; egyrészt a tanultak legalább 80%-át hasznosítottam azóta - mégha azt is gondoltam akkor, hogy erre nekem semmi szükségem nem lesz soha -, másrészt megtanított arra, hogy csak a specifikációknak higgyek, bármiről is legyen szó). Minden algoritmus megoldható egy szálon, maga a "programozás" talán arról szól, hogy a probléma és annak megoldása adott és kézzelfogható legyen. Hogy hogyan lehet »hatékonyabban«, az más megközelítés :).

    dabadab #165 és #167:

    Szál és process összehasonlítás SZVSZ nem ilyen egyszerű. Több szál azonos virtuális címtartományban fut egy process-en belül, ergo közös memóriájuk van, azonos adatterületen - főleg forrásadatoknál fontos ez - dolgozhatnak nagyjából kis ráfizetéssel (#166), de tényleg sok hibalehetőséggel (ezen a téren a CPU-gyártók is követettek el hibákak). A process-ek közti adatáramlás sokkal költségesebb, bonyolultabb (jellemzően file-alapú), viszont úgy látom, a világ mégis az előbbi felé halad (de leszögezem, a Linux lelki világát nem ismerem). Erről a Windows-os urban legend-ről még nem hallottam (de erről lehet szó itt is), de mégis arra haladnak a CPU-k, hogy azonos process-ben futó szálaknak minél kevesebb felesleges hátráltatást okozzanak task-váltáskor (gondolok itt AMD TLB-k esetén az Address Space Number-re, és Intel-nél a Hyperthreading-re és a speciálisan erre - nem csak alap több processor-ra - felkészített/optimalizált programokra is); pl. egyre fontosabb, hogy azonos process-hez tartozó szálak ne dobják ki a TLB-k és így az L1 cache-ek teljes tartalmát (amit tényleges process-váltásnál valóban meg kell tenni).

  • #162 P.H. senior tag Protezis #160
    #162
    Ö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

    P.H.

    senior tag

    válasz Protezis #160 üzenetére

    "Bar volt ilyen szakiranyos tantargyam, szerintem a jelentosegehez viszonyitva keveset foglalkoznak vele egyetemen."

    A párhuzamosítást nem kell túlmisztifikálni, inkább csak megvalósítási, mint tervezési szemlélet, az algoritmus természetén múlik, hogy lehet-e egyáltalán, illetve ha lehet, hogyan lehet így megközelíteni.
    Alapvetően két szemlélet lehetséges:
    - a feladat több, egymástól független részfeladatra bontása: pl. ha egy kép átméretezése a feladat, akárhány részre (~szálra) bontva meg lehet tenni, a darabok függetlenek egymástól, lehetőség van közvetlen forrásmemóriából célmemóriába való feldolgozásra.
    - több soros feldolgozási lépés van (kb. így működnek a médialejátszók), gyakorlatilag egy pipeline-on mennek keresztül az adatok: pl. adatkitömörítés->dekódolás->szín-hang konverzió->átméretezés. Egy-egy szálon egy-egy ilyen lépcsőfok fut, amelyek között ideiglenes bufferek (vagy ezek rendszere) tartják a kapcsolatot.
    Lehet még beszélni a szinkronizációk elvéről, közös adatterületek elérési szabályairól, de sokkal több nincs benne.

    Amire nem lehet ráhúzni valamelyiket, azt nem lehet párhuzamosítani; és algoritmuselméleti szempontból az ilyen párhuzamosítás csak konstans lineáris gyorsulást hoz, tehát elméleti megközelítésben "meglehetősen unalmas" (soha nem okoz pl. NP->polinomiális vagy polinomiális->logaritmikus időigény-csökkenést), bár bír gyakorlati jelentőséggel (mivel irreális időigényű algoritmusokat úgysem programoznak le általánosan közzétéve).

  • #140 P.H. senior tag kicsitomi88 #139
    #140
    Ö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

    P.H.

    senior tag

    válasz kicsitomi88 #139 üzenetére

    "Miert is erzem ugy, hogy ezt elobb tanulni(tanitani) kene mint csinalni(feladni otthonra)..."

    Ez azért árulkodó: nehogy túlbonyolítsd! Ebbe a hibába sokan beleesnek. Csak azt oldd meg, ami a feladat. :)
    Ha ez túlmutat azon, amit eddig tudsz/tudnod kellene, érdemes megkérdezni még egyszer, hogyan értették; lehet, hogy nem is az a feladat, amit gondolsz.

    Bár az olvasgatás nem árthat meg :)

  • #138 P.H. senior tag kicsitomi88 #134
    #138
    Ö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

    P.H.

    senior tag

    válasz kicsitomi88 #134 üzenetére

    Szegedre jársz - ha nem tévedek -, gondolom, az Algoritmusok és adatszerkezetek tárgy ismerős (lesz, másodév). Oda az azonos című, részben helyi szerkesztésű könyv alapvető (nagy, fekete az a kiadása, ami nekem is megvan), abban nézz körül pl.

    Ahogy írták is, a két alapvető gráftárolási megközelítés a mátrixos és a listás. Pár pro és kontra mindkettőre:
    Mátrix-alapú:
    - az adatszerkezet mérete exponenciális a pontok számával, mivel minden pont-pont kapcsolat helye - ha nem is lézetik ilyen - szerepel benne, ezért sűrű gráfok esetén érdemes alkalmazni
    - Ha a kapcsolatoknak/éleknek több tulajdonsága is van (nem csak a hossza), akkor több, párhuzamos mátrix vagy nagyobb elemi mátrixelem-méret szükséges
    - nagyon hatékony algoritmusok vannak a legrövidebb utak meghatározására (ebből érdemes kiindulni amúgy, az összes lehetséges még könnyű, a többi eléggé elbonyolítható), de nehéz dinamikussá tenni.

    Lista-alapú:
    - nagyon hatékony adattárolási forma ritka mátrixokra: felsorolod a pontok mellé, hogy mely pontokkal állnak kapcsolatban
    - viszont általános megoldásokban egyik kulcsjellemzője az egy ponthoz tartozó maximális (előre látott) lehetséges kapcsolatok száma, ennek változásával a hozzá tartozó algoritmusok is jelentősan változhatnak
    - kézbentarthatóan (= lineárisan) skálázódik az erőforrásigénye (memória, file) a pontok számának növekedésével
    - 'elég' hatékony algoritmusok vannak a legrövidebb utak meghatározására, de kis innovációval az eredetiekhez képest mindenképpen szükséges
    - a tulajdonséggal rendelkező kapcsolatok adott szituációban való kiértékelése nagyon egyszerű, akár tiltással, akár helyzetenkénti eltérő súlyozással, stb.

    A buszjárat-feladat (a megállókkal) nagyon ritka gráfnak fogható fel, viszont rendelkezik jó pár további - dinamikus - kapcsolattulajdonsággal (várakozási idő, a célútvonal időintervalluma (reggel-délben-este), átszállás stb.), ezért - főleg nagyszámú pontnál - alkalmasabb a listás megközelítés, mint a mátrixos. Erre nagyon jó kiindulópont az előbbiekben linkelt Dijkstra-algoritmus.

  • #97 P.H. senior tag bambano #96
    #97
    Ö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

    P.H.

    senior tag

    válasz bambano #96 üzenetére

    Az lehet árulkodó jel, hogy az K10-es TLB-hiba Linux patch-e azt csinálja, hogy a lapozásból felhozott vagy újonnan allokált/feltöltött lapot a kernel automatikusan megjelöli Accessed-ként - ha csak olvasható a lap - vagy Dirty-ként - ha írható is az (ebből gondolom, eddig nem tette). Tehát eszerint a Linux lapoz csak olvasható memóriaterületeket is, ami lehet konstans-tábla vagy kód, más nem nagyon. Illetve még egy eset lehetséges: Linux és Windows egyaránt használ bizonyos spekulatív prefetch-algoritmusokat a HDD-re tárolt lapokra (más esetben kizárt, hogy visszaolvasott lap ne legyen legalább Accessed). Linux-ban nem vagyok járatos, a Windows nem különbözteti meg ezeket (sőt, a verem és a - dinamikus - adatterület is futtatható, én pl. használom is, futás közben létrehozott kódok - timer - esetén).

    Továbbá az x86/x64 csak a fenti szinten nyújt hardware-es segítséget (Accessed+Dirty, DEB/NX ill. nem 'Present' lap esetén egy-egy megszakítás kiváltása), tehát ha ez így van, akkor az mégis külön táblázatok és software-es háttéradminisztráció létét feltételezi.

    #92: az mmap()-et hogyan kell kiadni futtatható kódokra? (nézegetem pl. itt, méret is szükséges hozzá; a fordítók adják ezt?)

    akosf: mindkét korábbi kód (@TRUNC és @ROUND) külön hívott belső Delphi eljárás, Delphi 4-ben kiírtam a disassembly-ablakból (a Delphi Enterprise Edition-ok mellé adják gyárilag a teljes fordítási forráskódot - VCL és runtime libraries -, a 4-es verzió felett még komplexebb a @TRUNC). Ha jól meggondoljuk, akkor gyorsabb truncate-sorozat a
    Set8087CW($xxxx); + ...round() hívások sorozata
    de ha valaki FPU control word-ot módosítgat, akkor már teheti assembly-ben is az egészet. De magas szinten is van gyorsabb 4-esben is, de ez meg ellentmond(?) a C-s szabványnak, hogy int_a=float_b mindig a kerekített értéket adja.

  • #48 P.H. senior tag #95904256 #46
    #48
    Ö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

    P.H.

    senior tag

    válasz #95904256 #46 üzenetére

    Round()-ot nem hoztam fel példának, mert az összes Opt. Manual-ban az hozzák fel érvként, hogy a kerekítés az alapértelmezett FPU konvertálás integer-be (a 'la C).

    i:=16;
    atemp:=round(i);

    Delphi:

    mov eax,$00000010
    mov [ebp-$08],esi
    fild dword ptr [ebp-$08]
    call @ROUND

    ...

    @ROUND:
    sub esp,08h
    fistp qword ptr [esp]
    pop eax
    pop edx
    ret

    FLD/FILD Q[ESP]: float -> integer lenne a mondandó, ez pedig nem az.

    Lehet hogy a trunc() nem a legjobb példa, mert én SSE3-as FISTTP-et használok in-line, ellenben a szintén in-line ( és valóban nem funkcióhívás ) Delphi / C trunc() megoldással. Ennek ellenére a FISTTP kontra FSTCW+FLDCW+FISTP(+FLDCW) kombó sebességbeli különbsége elég látványos. Ezzel csak az a baj, hogy én nem sűrűn találkoztam SSE3-képes géppel a célközönségünkben. És holnap annak fogok nekiülni, hogy egy virtualizált, 32 vagy 64 MB memóriával ellátott Linux alatti Wine-s környezet normálisan futtassa a programomat.
    Én »jelenleg« SSE2 felett nem szoktam programot írni nagyközönségnek, mert nincs arra képes hardware (csak itthon).

  • #44 P.H. senior tag #95904256 #40
    #44
    Ö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

    P.H.

    senior tag

    válasz #95904256 #40 üzenetére

    Csak egy egyszerű példa: egyszer nézz bele, hogy egy Delphi hogy oldja ezt (truncate float -> int; Delphiben trunc() ) :)

    fld dword ptr [value]
    call @TRUNC
    ...

    @TRUNC:
    sub esp,0Ch
    fstcw word ptr [esp+00h]
    fldcw word ptr [cwChop]
    fistp word ptr [esp+04h]
    fldcw word ptr [esp+00h]
    pop ecx
    pop eax
    pop edx
    ret

    Ez mindennapos. Egy 1000-es nagyságrendű, trunc() eljárást hívó ciklus vagy sima rutin esetén is ez van. Nem adna gyorsabb kódot ezt egy InitTrunc() (fstcw+fldcw) - 1000-es ciklus (fld - fistp) vagy rutin - EndTrunc() (fldcw) három makróval megoldani?
    Tudom, van Set8087CW Delphi-ben. Vajon megváltozik ettől a trunc() működése?

    Persze itt nem erről beszélünk, ez az Opt. Manual-ok témája inkább.

  • #39 P.H. senior tag #95904256 #38
    #39
    Ö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

    P.H.

    senior tag

    válasz #95904256 #38 üzenetére

    "Vagy úgy gondolta hogy annyiszor bepötyögi?"
    Legtöbben ezt alkalmazzák, néhány munkatársam is (sajnos). Nagyban függhet ez attól is, hogy az adott nyelv támogatja-e a makrózást (pl. Delphi tudtommal nem).

  • #37 P.H. senior tag P.H. #36
    #37
    Ö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

    P.H.

    senior tag

    válasz P.H. #36 üzenetére

    (talán itt a legnagyobb különbség a kettő között; és az előbbit nem hiszem, hogy csoportos fejlesztésnél meg lehetne tenni komoly kompromisszumok nélkül)

    sorry, utóbbit, nem "előbbit"

  • #36 P.H. senior tag #95904256 #35
    #36
    Ö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

    P.H.

    senior tag

    válasz #95904256 #35 üzenetére

    SZVSZ elbeszéltek kissé egymás mellett.

    shev7 azt mondja, hogy egy kódot azért nem érdemes egynél több helyen felhasználni közvetlenül, mert »ha« a kód hibás (vagy később módosítani, fejleszteni kell), akkor egyszerűbb egy helyen azt megtenni. Te azt mondod, hogy ha az a (matematikailag ellenőrzött, letesztelt, esetleg valamire kihegyezett stb.) végleges kód, akkor lehet többször is alkalmazni (ez hatékonyabb is), mert ha mégsem az, akkor úgyis újra kell az egészet írni, esetleg tervezni is.

    A témához - és amivé vált - hozzászólva: egy jól megírt (hatékony, jól karbantartható) kód eljárásalapú kód előbb-utóbb az OOP-szemlélettel hasonló tulajdonságokkal fog rendelkezni (pl. teljesen mindegy, hogy valamit object.procedure(...) vagy procedure(object,...) alakban írunk, ha a végeredmény ugyanaz lesz; az öröklődés még inkább ilyen, ez szinte megkerülhetetlen; nem véletlen lett kidolgozva az OOP elmélete). Ez csak azon múlik, kinek mi áll közelebb a gondolkodásához. Az első dolog mindenképp az kell, hogy legyen, hogy megértsük a lényegét, azt, hogy mire jó, és mit várunk el tőle. Enélkül üres szövegelés a pro és kontra érv-felsorolás mindkét (OOP és POP) oldalról.

    Én pl. nem fognék neki még ma sem OOP-programnak, egyszerűen képtelen vagyok úgy tervezni valamit, hogy annak a központja a feldolgozandó adat struktúrája legyen, ehhez igazítva a kódot, inkább a kódhoz igazítom az adatszerkezetet (talán itt a legnagyobb különbség a kettő között; és az előbbit nem hiszem, hogy csoportos fejlesztésnél meg lehetne tenni komoly kompromisszumok nélkül). De szinte az összes végeredményem teljesíti az objektum-orientáltság követelményeit. És innen visszanézve őket nem mondhatom azt, hogy bonyolultabb lett volna alapból objektumokra alapozva tervezni.

    Ez csak szemléletbeli különbség SZVSZ. Van, aki azonnal nekiugrik leprogramozni egy problémát, van, aki hosszú órákat/napokat tud ülni felette, végiggondolva a lehetséges következő elvárásokat, továbblépéseket, a kód jövőbeli életét.

Aktív témák

Hirdetés