Hirdetés

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

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

Aktív témák