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