eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming › [mt] few points (kilka uwag)
Ilość wypowiedzi w tym wątku: 5

  • 1. Data: 2011-09-04 05:21:52
    Temat: [mt] few points (kilka uwag)
    Od: "fir" <p...@p...onet.pl>

    troche pozastanawialem sie nad mt kontynuujac
    to co juz sobie ustalilem pare czy parenascie miesiecy
    temu (mam nadzieje ze rozwazania nie zawieraja bledow)

    wyglada mi na to ze o ile bezkolizyjnosc mozna by
    implementowac tylko na rozdrobnionym poziomie
    dostepu do poszczegolnych floatow czy intow to
    nie jest to zbyt realistyczne bo raczej nie wystarczy

    potrzebne sa bitowe klucze (loki) zamykajace na raz
    spojnie cale struktury; mozna by probowac pokusic sie
    by lokowac wrecz 'sprzetowo' (cos jak odpowiednik
    hardware'owych przerwan) wszystkie struktury i
    tablice hurtem
    (co byc moze wogole nie wymagaloby ingerencji
    programisty w sensie pisania jakiegokolwiek kodu -
    acz musialby miec swiadomosc ze watki beda mu
    sprzetowo zwisaly przy konkurencyjnym dostepie
    do struktur i tablic
    - nie wiem dokladnie co by z tego wyszlo ale
    pojawily by sie wydaje obecne problemy z
    zakleszczeniami i race'ami, byc moze jednek udaloby sie
    je rozwiazac na tym sprzetowym poziomie a moze nie
    - ten model bylby podobny chyba do obecnego sposobu
    zakladania lokow (znanego mi osobiscie glownie
    z przeczytania 'pthreads primer' bo sam nie
    pisalem prawie nic wielowatkowych programow) -
    z tym ze nie byloby kodu bo loki zakladalyby sie
    automatycznie


    --
    Wysłano z serwisu OnetNiusy: http://niusy.onet.pl


  • 2. Data: 2011-09-04 05:37:35
    Temat: Re: [mt] few points (kilka uwag)
    Od: p...@p...onet.pl

    > troche pozastanawialem sie nad mt kontynuujac
    > to co juz sobie ustalilem pare czy parenascie miesiecy
    > temu (mam nadzieje ze rozwazania nie zawieraja bledow)
    >
    > wyglada mi na to ze o ile bezkolizyjnosc mozna by
    > implementowac tylko na rozdrobnionym poziomie
    > dostepu do poszczegolnych floatow czy intow to
    > nie jest to zbyt realistyczne bo raczej nie wystarczy
    >
    > potrzebne sa bitowe klucze (loki) zamykajace na raz
    > spojnie cale struktury; mozna by probowac pokusic sie
    > by lokowac wrecz 'sprzetowo' (cos jak odpowiednik
    > hardware'owych przerwan) wszystkie struktury i
    > tablice hurtem
    > (co byc moze wogole nie wymagaloby ingerencji
    > programisty w sensie pisania jakiegokolwiek kodu -
    > acz musialby miec swiadomosc ze watki beda mu
    > sprzetowo zwisaly przy konkurencyjnym dostepie
    > do struktur i tablic
    > - nie wiem dokladnie co by z tego wyszlo ale
    > pojawily by sie wydaje obecne problemy z
    > zakleszczeniami i race'ami, byc moze jednek udaloby sie
    > je rozwiazac na tym sprzetowym poziomie a moze nie
    > - ten model bylby podobny chyba do obecnego sposobu
    > zakladania lokow (znanego mi osobiscie glownie
    > z przeczytania 'pthreads primer' bo sam nie
    > pisalem prawie nic wielowatkowych programow) -
    > z tym ze nie byloby kodu bo loki zakladalyby sie
    > automatycznie

    problemem jest tez to ze cala duza tablica lokowala by
    sie hurtem (podzial na stale kawalki ktore mozna
    by polokowac osobno tez byc moze nie rozwiazuje problemu)


    ogolnie wydaje mi sie ze zakladanie bitowych kluczykow
    wybranym kawalkom danych jest byc moze bardziej wygodnym
    rozwiazaniem, np mozna pomyslec o lokowaniu danych
    calego modulu - to by sklanialo do dzielania danych
    na moduly w zwiazku z potrzebami wielowatkowosci
    i/ale trudno mi powiedziec czy byloby to moze dobrze
    czy zle

    jeszcze jedna uwaga: ten bitowy kluczyk lokujacy jakas
    strukture danych nie powinien byc raczej z musu blokiem
    (na ktorym zwisa odczyt czy przypisnie) czesto powinien
    on byc raczej informacja czy dane sa zalokowane czy nie
    tak by mozna to bylo podlaczyc do normalnego watkowego
    ifa, druga rzecz ten bitowy kluczyk powinien raczej
    dawac oddzielnie ijnformacje o tym czy dane sa przez
    kogos obcego obecnie zajete tylko do read tylko do write
    czy do obu

    trzebaby sie zastanowic teraz jak ew wygladaloby
    programowanie przy takim ukladzie i jak by bylo




    --
    Wysłano z serwisu OnetNiusy: http://niusy.onet.pl


  • 3. Data: 2011-09-04 07:50:49
    Temat: Re: [mt] few points (kilka uwag)
    Od: "fir" <p...@p...onet.pl>

    > > troche pozastanawialem sie nad mt kontynuujac

    > > to co juz sobie ustalilem pare czy parenascie miesiecy

    > > temu (mam nadzieje ze rozwazania nie zawieraja bledow)

    > >

    > > wyglada mi na to ze o ile bezkolizyjnosc mozna by

    > > implementowac tylko na rozdrobnionym poziomie

    > > dostepu do poszczegolnych floatow czy intow to

    > > nie jest to zbyt realistyczne bo raczej nie wystarczy

    > >

    > > potrzebne sa bitowe klucze (loki) zamykajace na raz

    > > spojnie cale struktury; mozna by probowac pokusic sie

    > > by lokowac wrecz 'sprzetowo' (cos jak odpowiednik

    > > hardware'owych przerwan) wszystkie struktury i

    > > tablice hurtem

    > > (co byc moze wogole nie wymagaloby ingerencji

    > > programisty w sensie pisania jakiegokolwiek kodu -

    > > acz musialby miec swiadomosc ze watki beda mu

    > > sprzetowo zwisaly przy konkurencyjnym dostepie

    > > do struktur i tablic

    > > - nie wiem dokladnie co by z tego wyszlo ale

    > > pojawily by sie wydaje obecne problemy z

    > > zakleszczeniami i race'ami, byc moze jednek udaloby sie

    > > je rozwiazac na tym sprzetowym poziomie a moze nie

    > > - ten model bylby podobny chyba do obecnego sposobu

    > > zakladania lokow (znanego mi osobiscie glownie

    > > z przeczytania 'pthreads primer' bo sam nie

    > > pisalem prawie nic wielowatkowych programow) -

    > > z tym ze nie byloby kodu bo loki zakladalyby sie

    > > automatycznie

    >

    > problemem jest tez to ze cala duza tablica lokowala by

    > sie hurtem (podzial na stale kawalki ktore mozna

    > by polokowac osobno tez byc moze nie rozwiazuje problemu)

    >

    >

    > ogolnie wydaje mi sie ze zakladanie bitowych kluczykow

    > wybranym kawalkom danych jest byc moze bardziej wygodnym

    > rozwiazaniem, np mozna pomyslec o lokowaniu danych

    > calego modulu - to by sklanialo do dzielania danych

    > na moduly w zwiazku z potrzebami wielowatkowosci

    > i/ale trudno mi powiedziec czy byloby to moze dobrze

    > czy zle

    >

    > jeszcze jedna uwaga: ten bitowy kluczyk lokujacy jakas

    > strukture danych nie powinien byc raczej z musu blokiem

    > (na ktorym zwisa odczyt czy przypisnie) czesto powinien

    > on byc raczej informacja czy dane sa zalokowane czy nie

    > tak by mozna to bylo podlaczyc do normalnego watkowego

    > ifa, druga rzecz ten bitowy kluczyk powinien raczej

    > dawac oddzielnie ijnformacje o tym czy dane sa przez

    > kogos obcego obecnie zajete tylko do read tylko do write

    > czy do obu

    >

    > trzebaby sie zastanowic teraz jak ew wygladaloby

    > programowanie przy takim ukladzie i jak by bylo

    >

    >

    w sumie jak zastanawiam sie jak ew mozna by zrobic/moglo by wygladac
    odpalenie liczenia tablicy 1000x1000 (np zbioru mandelbrota) na tysiacu
    watkow to mz mogloby to wygladac np tak - przy uzyciu normalnych srodkow
    potrzebna jest tylko atomowa funkcja 'acquire' do testu czy flaga jest wolna
    i jej ustawienia i funkcja 'newThread' do odpalenia nowego watku

    typedef char lock;



    tab [1000][1000];

    lock tab_column_lock[1000];

    void calculateColumn(int k)
    {

    //.... operacje na tab[k][...]
    }


    void main()
    {

    for(int i=0; i<1000;i++)
    {
    if(acquire(tab_column_lock[i]))
    {
    newThread( calculateColumn(i) );
    }

    }

    }

    chyba daloby sie to zrobic normalnymi srodkami i 'skalowaloby' sie to
    na n procesorow - np dla dziesieciu procesorow na kazdym mw odpaliloby
    sie po sto watkow po czym w miare wygasania tych watkow moc
    dzielilaby sie na pozostale




    --
    Wysłano z serwisu OnetNiusy: http://niusy.onet.pl


  • 4. Data: 2011-09-04 08:31:21
    Temat: Re: [mt] few points (kilka uwag)
    Od: p...@p...onet.pl


    >   if(acquire(tab_column_lock[i]))
    >   {
    >     newThread( calculateColumn(i) );
    >   }
    >

    w tych dwu linijkach niedokladnosci bo acquire musi byc
    atomowe wiec nie wiem czy mozna przedstawiac w postaci
    wywolania funkcji pozatym nie ma info ze to do readwrite,
    z kolei robienie mechanizmu wbudowanego i slow kluczowych jak
    np "if(acquire readwrite tab_column_lock[i]) {}" tez nie wiem
    czy jest najlepsze (bo jakby dac po prostu sposob ogolnego
    robienia takich atomowek moglobybyc ogolniejsze); pozatym
    to wywolanie w newThread jest bledne i raczej powinno
    byc "newThread(calculateColumn, i)" gdzie newTherad musialoby
    byc poprzeciazane albo calculateColumn jakims rodzajem funkcji
    z VA_ARGS albo cos - ale akurat niezbyt wazne w kontekscie tego
    jak ew mozna mz robic naladniej multithreading



    --
    Wysłano z serwisu OnetNiusy: http://niusy.onet.pl


  • 5. Data: 2011-09-04 09:13:55
    Temat: Re: [mt] few points (kilka uwag)
    Od: p...@p...onet.pl


    > >      newThread( calculateColumn(i) );

    ciagle nie wiem czy blocki (blocks) w objective-c nie sa
    zrobione wlasnie po to by moc wywolywac jak wyzej - bo nie
    moglem ostatnio zrozumiecichniego wyjasnienia - a jesli tak
    to pytanie jak to jest implementowane w asmie?


    --
    Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

strony : [ 1 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: