eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingLLVM a Garbage Collector
Ilość wypowiedzi w tym wątku: 23

  • 11. Data: 2012-05-21 14:40:19
    Temat: Re: LLVM a Garbage Collector
    Od: "Borneq" <b...@a...hidden.pl>

    Użytkownik "Roman W" <b...@g...pl> napisał w wiadomości
    news:37b7e9b9-0be2-4f9f-bd99-6e0823d5efec@googlegrou
    ps.com...
    > Cecha charakterystyczna programow napisanych w C czy C++ bez GC jest
    > fanatyczne
    > unikanie (re)alokacji pamieci, bo to kosztuje, kosztem czytelnosci
    > programu. Kiedy sie
    > uzywa GC, te operacje staja sie tansze, i nie trzeba sie tak meczyc.

    Za zwalnianie odpowiada GC, a co z alokacją? W jaki sposób tańsza? Czy
    alokacja dlatego tania że wskaźniki mogą być przesunięte, pamięć nie jest
    rozdrobiona, i po lewo mamy pamięć przydzieloną, po prawo wolną i tylko
    przesuwamy wskaźnik?


  • 12. Data: 2012-05-21 14:51:00
    Temat: Re: LLVM a Garbage Collector
    Od: Roman W <b...@g...pl>

    On Monday, May 21, 2012 1:40:19 PM UTC+1, Borneq wrote:
    > Użytkownik "Roman W" <b...@g...pl> napisał w wiadomości
    > news:37b7e9b9-0be2-4f9f-bd99-6e0823d5efec@googlegrou
    ps.com...
    > > Cecha charakterystyczna programow napisanych w C czy C++ bez GC jest
    > > fanatyczne
    > > unikanie (re)alokacji pamieci, bo to kosztuje, kosztem czytelnosci
    > > programu. Kiedy sie
    > > uzywa GC, te operacje staja sie tansze, i nie trzeba sie tak meczyc.
    >
    > Za zwalnianie odpowiada GC, a co z alokacją? W jaki sposób tańsza? Czy
    > alokacja dlatego tania że wskaźniki mogą być przesunięte, pamięć nie jest
    > rozdrobiona, i po lewo mamy pamięć przydzieloną, po prawo wolną i tylko
    > przesuwamy wskaźnik?

    http://www.umbrant.com/blog/2012/twitter_jvm_tuning.
    html

    RW


  • 13. Data: 2012-05-21 14:52:15
    Temat: Re: LLVM a Garbage Collector
    Od: " weary.fighter.of.grunge" <f...@g...pl>

    >
    > Cecha charakterystyczna programow napisanych w C czy C++ bez GC jest fanaty=
    > czne unikanie (re)alokacji pamieci, bo to kosztuje, kosztem czytelnosci pro=
    > gramu. Kiedy sie uzywa GC, te operacje staja sie tansze, i nie trzeba sie t=
    > ak meczyc.
    >

    W jaki sposob meczyc? Pytam bo jak zyje i pisze w c nie znam
    takiego przypadku. Moze ktos podac jakis taki przypadek
    o jakim mowa, rozwazylbym to. Ciekawe czy to nie da sie zrobic
    normalnie np na stosie.

    ??


    --
    Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/


  • 14. Data: 2012-05-21 15:17:10
    Temat: Re: LLVM a Garbage Collector
    Od: Roman W <b...@g...pl>

    On Monday, May 21, 2012 1:52:15 PM UTC+1, weary.fighter.of.grunge wrote:
    > >
    > > Cecha charakterystyczna programow napisanych w C czy C++ bez GC jest fanaty=
    > > czne unikanie (re)alokacji pamieci, bo to kosztuje, kosztem czytelnosci pro=
    > > gramu. Kiedy sie uzywa GC, te operacje staja sie tansze, i nie trzeba sie t=
    > > ak meczyc.
    > >
    >
    > W jaki sposob meczyc? Pytam bo jak zyje i pisze w c nie znam
    > takiego przypadku. Moze ktos podac jakis taki przypadek
    > o jakim mowa, rozwazylbym to. Ciekawe czy to nie da sie zrobic
    > normalnie np na stosie.

    Typowy usage pattern w C++ to prealokacja pamieci roboczej, a nastepnie przekazywanie
    odnosnika do niej (w jakiejs formie: wskaznika, referencji, sprytnego wskaznika,
    itd.) do niej, albo do "workspace" jej zawierajacej, z procedury do procedury, nawet
    jezeli jej zawartosc jest nadpisywana. W Javie mozna po prostu zadeklarowac sobie
    tablice dokladnie tam gdzie jest ona potrzebna, i tez jest dobrze.

    C++ z kolei umozliwia tworzenie obiektow na stosie, co jest jeszcze szybsze.

    RW


  • 15. Data: 2012-05-21 16:00:07
    Temat: Re: LLVM a Garbage Collector
    Od: " " <f...@g...pl>

    Roman W <b...@g...pl> napisał(a):

    > On Monday, May 21, 2012 1:52:15 PM UTC+1, weary.fighter.of.grunge wrote:
    > > >=20
    > > > Cecha charakterystyczna programow napisanych w C czy C++ bez GC jest fa=
    > naty=3D
    > > > czne unikanie (re)alokacji pamieci, bo to kosztuje, kosztem czytelnosci=
    > pro=3D
    > > > gramu. Kiedy sie uzywa GC, te operacje staja sie tansze, i nie trzeba s=
    > ie t=3D
    > > > ak meczyc.
    > > >=20
    > >=20
    > > W jaki sposob meczyc? Pytam bo jak zyje i pisze w c nie znam=20
    > > takiego przypadku. Moze ktos podac jakis taki przypadek=20
    > > o jakim mowa, rozwazylbym to. Ciekawe czy to nie da sie zrobic=20
    > > normalnie np na stosie.
    >
    > Typowy usage pattern w C++ to prealokacja pamieci roboczej, a nastepnie prz=
    > ekazywanie odnosnika do niej (w jakiejs formie: wskaznika, referencji, spry=
    > tnego wskaznika, itd.) do niej, albo do "workspace" jej zawierajacej, z pro=
    > cedury do procedury, nawet jezeli jej zawartosc jest nadpisywana. W Javie m=
    > ozna po prostu zadeklarowac sobie tablice dokladnie tam gdzie jest ona potr=
    > zebna, i tez jest dobrze.
    >
    > C++ z kolei umozliwia tworzenie obiektow na stosie, co jest jeszcze szybsze=
    > ..

    no to jesli o to chodzi to mozna zrobic na stosie

    void test()
    {
    auto ListaItemow[] = PodajInventoryPostaciNr(15);

    loguj( ListaItemow[] );
    }

    tak ze tutaj nie tylko gc ale i heap nie jest
    potrzebny (slowo auto dodalem dla podkreslenia ze to na stosie)

    co prawda obecne stare c tego nie wspiera (*) i to wymaga
    manipulowania wskaznikiem stosu, ale (o ile sie nie
    myle bo nie myslem o tym za duzo) mozna to zrobic
    w ramach statego systemu stos+globale-malloc ze tak powiem

    (*) nawet w obecnym c mozna to zrobic z tego co sie orientuje

    void test()
    {
    conts int lista_ilemow_max = 10000;

    auto ListaItemow[lista_ilemow_max];

    PodajInventoryPostaciNr(15, ListaItemow);

    loguj( ListaItemow );
    }

    kosztem zaalokowanie na stosie nie dokladnie tyle ile trzeba
    tylko maksymalnej dopuszczalnej wartosci (ktos wie czy to by
    ruszylo? moze bym tego uzywal bo lubie takie ciekawe wynalazki)


    moze jakis inny przypadek (gdzie moznaby sie niemaczyc
    uzywajac czegos w rodzaju gc lub recznej dealokacji) ?

    (niby mozna sobie cos takiego wyobrazic np gre ktora
    zawiera w sobie dwie rozne gry i przelacza sie miedzy jedna a
    druga dealokujac ram nieuzywanej - ale w praktyce nie natrafilem
    jeszcze na takie cos, i tak nie wiem czy nie daloby sie
    kombinowac ze stosem w tym nawet wypadku a jak nie to i
    tak chyba realokowanie tablic do 0 (ale nie zamazywanie
    wskaznikow) byloby chyba lepsze niz 'calkowite odpinanie'
    (acz nie mam jasnosci w tych sprawach )






    --
    Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/


  • 16. Data: 2012-05-21 16:05:41
    Temat: Re: LLVM a Garbage Collector
    Od: " weary fighter of grunge" <f...@g...pl>

    > auto ListaItemow[] = PodajInventoryPostaciNr(15);
    tu powinno byc

    auto Item listaItemow[] = PodajInventoryPostaciNr(15);

    (gdzie item to jakas struktura)

    --
    Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/


  • 17. Data: 2012-05-21 16:23:34
    Temat: Re: LLVM a Garbage Collector
    Od: Maciej Sobczak <s...@g...com>

    On 21 Maj, 10:14, Roman W <b...@g...pl> wrote:

    > Cecha charakterystyczna programow napisanych w C czy C++ bez GC jest fanatyczne
    unikanie (re)alokacji pamieci, bo to kosztuje, kosztem czytelnosci programu.

    To zależy od kontekstu. Bardzo często mam wrażenie, że kod właśnie
    zyskuje na czytelności tam, gdzie nie ma (re)alokacji. Wraz z alokacją
    pojawiają się w kodzie wskaźniki a potem jest już tylko gorzej.

    Alokacja to w ogóle dosyć niskopoziomowej narzędzie i jak z tego typu
    narzędziami, im lepszy ma być kod, tym powinno być tego mniej.

    > Kiedy sie uzywa GC, te operacje staja sie tansze, i nie trzeba sie tak meczyc.

    Wtedy trzeba się męczyć z czymś innym. Np. z nullami albo z
    niezamierzonym współdzieleniem obiektów, albo niezamierzoną
    wielokrotną alokacją tego samego, gubiąc przy okazji poprzedni stan
    (takiego właśnie buga w Javie ostatnio widziałem), itd.
    To nie jest postęp, to jest zamiana pewnych niskopoziomowych problemów
    na inne niskopoziomowe problemy.

    --
    Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com


  • 18. Data: 2012-05-21 16:47:43
    Temat: Re: LLVM a Garbage Collector
    Od: Roman W <b...@g...pl>

    On Monday, May 21, 2012 3:23:34 PM UTC+1, Maciej Sobczak wrote:
    > On 21 Maj, 10:14, Roman W <b...@g...pl> wrote:
    >
    > > Cecha charakterystyczna programow napisanych w C czy C++ bez GC jest fanatyczne
    unikanie (re)alokacji pamieci, bo to kosztuje, kosztem czytelnosci programu.
    >
    > To zależy od kontekstu. Bardzo często mam wrażenie, że kod właśnie
    > zyskuje na czytelności tam, gdzie nie ma (re)alokacji. Wraz z alokacją
    > pojawiają się w kodzie wskaźniki a potem jest już tylko gorzej.
    >
    > Alokacja to w ogóle dosyć niskopoziomowej narzędzie i jak z tego typu
    > narzędziami, im lepszy ma być kod, tym powinno być tego mniej.
    >
    > > Kiedy sie uzywa GC, te operacje staja sie tansze, i nie trzeba sie tak meczyc.
    >
    > Wtedy trzeba się męczyć z czymś innym. Np. z nullami albo z
    > niezamierzonym współdzieleniem obiektów, albo niezamierzoną
    > wielokrotną alokacją tego samego, gubiąc przy okazji poprzedni stan
    > (takiego właśnie buga w Javie ostatnio widziałem), itd.
    > To nie jest postęp, to jest zamiana pewnych niskopoziomowych problemów
    > na inne niskopoziomowe problemy.

    Racja, ale przynajmniej mozna sobie wybrac takie problemy, jakie sie lubi bardziej.

    RW


  • 19. Data: 2012-05-21 17:08:25
    Temat: Re: LLVM a Garbage Collector
    Od: "Borneq" <b...@a...hidden.pl>

    Użytkownik "Roman W" <b...@g...pl> napisał w wiadomości
    news:e89a9b9f-c37e-4810-b375-42ea653b1b82@googlegrou
    ps.com...
    > http://www.umbrant.com/blog/2012/twitter_jvm_tuning.
    html

    "Garbage collection is also simple; live objects get copied out to the first
    survivor, and then the Eden pointer gets zeroed back to the start of the
    heap. Trash doesn't need to be explicitly zeroed out, so deallocation is
    "free". Note that this efficiency is true only for small objects; larger
    objects (megabytes) are allocated in a different and more expensive way
    directly to the old generation"
    To znaczy małe obiekty są kopiowane jeden za drugim, a jak uaktualniane są
    wskaźniki do nich?


  • 20. Data: 2012-05-21 17:30:23
    Temat: Re: LLVM a Garbage Collector
    Od: " przegrany człowiek fir *" <f...@g...pl>

    Roman W <b...@g...pl> napisał(a):

    > On Monday, May 21, 2012 3:23:34 PM UTC+1, Maciej Sobczak wrote:
    > > On 21 Maj, 10:14, Roman W <b...@g...pl> wrote:
    > >=20
    > > > Cecha charakterystyczna programow napisanych w C czy C++ bez GC jest fa=
    > natyczne unikanie (re)alokacji pamieci, bo to kosztuje, kosztem czytelnosci=
    > programu.
    > >=20
    > > To zale=BFy od kontekstu. Bardzo cz=EAsto mam wra=BFenie, =BFe kod w=B3a=
    > =B6nie
    > > zyskuje na czytelno=B6ci tam, gdzie nie ma (re)alokacji. Wraz z alokacj=
    > =B1
    > > pojawiaj=B1 si=EA w kodzie wska=BCniki a potem jest ju=BF tylko gorzej.
    > >=20
    > > Alokacja to w og=F3le dosy=E6 niskopoziomowej narz=EAdzie i jak z tego ty=
    > pu
    > > narz=EAdziami, im lepszy ma by=E6 kod, tym powinno by=E6 tego mniej.
    > >=20
    > > > Kiedy sie uzywa GC, te operacje staja sie tansze, i nie trzeba sie tak =
    > meczyc.
    > >=20
    > > Wtedy trzeba si=EA m=EAczy=E6 z czym=B6 innym. Np. z nullami albo z
    > > niezamierzonym wsp=F3=B3dzieleniem obiekt=F3w, albo niezamierzon=B1
    > > wielokrotn=B1 alokacj=B1 tego samego, gubi=B1c przy okazji poprzedni stan
    > > (takiego w=B3a=B6nie buga w Javie ostatnio widzia=B3em), itd.
    > > To nie jest post=EAp, to jest zamiana pewnych niskopoziomowych problem=F3=
    > w
    > > na inne niskopoziomowe problemy.
    >
    > Racja, ale przynajmniej mozna sobie wybrac takie problemy, jakie sie lubi b=
    > ardziej.=20
    >
    z tym ze ciagle ciekawe o jakich to problemach (zwiazanych
    brakiem gc w c) mowa ????

    bo na razie to stanelo mw na tym ze nie wiem czego w c nie
    mozna zrobic na ramie statycznym, encjach typu auto na stosie

    ( i EW moze czasem (tez pytanie kiedy to jest potrzebne
    bo na codzien nie uzywam) sporadycznych realokach czy innych
    tego typu sprawach typu ew swego rodzaju unie (tj np dwie
    gry na tym samym kawalku ramu zaadresowane przez rzutowanie)

    tej trzeciej opcji ja nie uzywalem poki co a i tak jest to
    (z tego jak niedokladnie widze) opcja bezwskaznikowa, (twarde
    adresy) czyli to wszystko pozbawione jest problemow zwiazanych
    ze wskaznikami (ypu przestrzen na bledy i opoznienia zwiazane
    z posrednimi referencjami)

    (* znowu mam pewnego doła zwiazanego zmoja cienkościa, jak i zlym
    samopoczuciem zwiazanym ze zlym stanem zdrowotnym)


    --
    Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

strony : 1 . [ 2 ] . 3


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: