On 11.07.2013 02:10, bartekltg wrote:
> W dniu 2013-07-11 01:50, Michoo pisze:
>
>> Brak GC (czy fakultatywny GC jak w pythonie) nie oznacza brak menagera
>> pamięci. Można by spokojnie zrobić system/język/framework z
>> deterministycznym zarządzaniem pamięcią a jednocześnie kompaktowaniem
>> sterty, optymalizowaniem rozłożenia obiektów pod względem cache/etc.
>> Oczywiście wykrywanie cykli musi jakoś być rozwiązane czy to przez
>> zmuszenie programisty do używania week-reference (cykl==terminate nauczy
>> bardzo szybko) czy przez wykrywanie cykli (vide python).
>
> To terminate z powodu cyklu to na pewno dobry pomysł?
>
> Czasem zmusi to do zupełnie niepotrzebnego obchodzenia,

Tak. Jest to cena którą płacisz za deterministyczne sprzątanie śmieci.
GC też zazwyczaj daje też dużą wolność a w praktyce czasami zmusza do
zupełnie niepotrzebnego obchodzenia - nie ma rozwiązań do wszystkiego
idealnych.

> np w jakimś algorytmie na grafie skierowanym głownie usuwającym
> krawędzie.

Jak to robiłem w C++ to aby z jednej strony nie bawić się w ręczne
new/delete a z drugiej nie cieknąć pamięcią miałem w obiektach
opakowujących algorytmy std::vector<shared_ptr<T> > freeMeLater a sam
algorytm działał już na wskaźnikach. Było szybkie i dawało gwarancję, że
w momencie gdy dane przestaną być używane wszystko się ładnie sprzątnie.


>
>
>> Tak jak się zrobił w pewnym momencie hype na noSQL tak może i przyjdzie
>> czas na noGC. Może się nawet coś dobrego z tego wykluje.
>
> A ludzie od c++ w większości tak nie mają?

Ludzie od C++ w większości muszą pamiętać o pamięci. Użytkownicy GC w
większości nie muszą. Mi chodzi o to, żeby pamiętać jedynie o nie
zepsuciu pamięci (być może za cenę dodatkowego wektora tu i uwdzie[*]) a
reszta się zrobi sama.

[*] Zauważ, że w języku to może się robić automatycznie na zasadzie np
operatora lNew który tworzy obiekt i wiąże jego czas życia z opakowującą
funkcją czy klasą.

--
Pozdrawiam
Michoo

do góry

On 2013-07-11, Michoo <m...@v...pl> wrote:
[...]
> GC też zazwyczaj daje też dużą wolność a w praktyce czasami zmusza do
^--- przecinek
> zupełnie niepotrzebnego obchodzenia - nie ma rozwiązań do wszystkiego
> idealnych.
[...]
> Jak to robiłem w C++ to aby z jednej strony nie bawić się w ręczne
^--- przecinek
> new/delete a z drugiej nie cieknąć pamięcią miałem w obiektach
^--- przecinek
> opakowujących algorytmy std::vector<shared_ptr<T> > freeMeLater a sam
przecinek ---^
> algorytm działał już na wskaźnikach. Było szybkie i dawało gwarancję, że
> w momencie gdy dane przestaną być używane wszystko się ładnie sprzątnie.
^--- przecinek
[...]
> Ludzie od C++ w większości muszą pamiętać o pamięci. Użytkownicy GC w
> większości nie muszą. Mi chodzi o to, żeby pamiętać jedynie o nie

Ci chodzi o to?
http://poradnia.pwn.pl/lista.php?id=5375
http://poradnia.pwn.pl/lista.php?id=523
http://poradnia.pwn.pl/lista.php?id=5842

> zepsuciu pamięci (być może za cenę dodatkowego wektora tu i uwdzie[*]) a
> reszta się zrobi sama.

"Ówdzie".

> [*] Zauważ, że w języku to może się robić automatycznie na zasadzie np
> operatora lNew który tworzy obiekt i wiąże jego czas życia z opakowującą
^--- przecinek
> funkcją czy klasą.

Michoo, na miłość Boską, przejrzyj jeszcze raz przyzwoity słownik (taki
z zasadami interpunkcji).

--
Secunia non olet.
Stanislaw Klekot

do góry

On 11.07.2013 01:53, A.L. wrote:
> On Thu, 11 Jul 2013 01:37:14 +0200, Michoo<m...@v...pl> wrote:
>
>>>
>> Ja od wielu lat twierdzę, że klasyczne GC to straszne marnowanie
>> zasobów.
>
> Uhum... Co jescze twierdzisz?
>
[*] Odwrócę pytanie:

Czy uważasz, że GC minimalizuje wykorzystanie zasobów? Czy też jednak
pozwala na proste[**] zarządzanie pamięcią z punktu widzenia programisty
za cenę jej względnie dużego(w porównaniu do optymalnego) zajęcia?

(Ja nie twierdzę, że GC nie należy nigdy używać, ja twierdzę, że GC jest
_zazwyczaj_ rozwiązaniem suboptymalnym. Są przypadki gdzie duże
wykorzystanie zasobów jest niewielką ceną, którą płaci się za korzyści
wynikające z GC, ale IMO decyzja projektowa powinna być odwrotna -
wiedzieć kiedy go użyć a nie używać "domyślnie".)


[*] Wiele rzeczy, np w okolicy problemu stopu w systemach o skończonych
zasobach, ale to nie ma nic do tematu.

[**] Proste dopóki nie trafi się ściany - widziałem już algorytmy z
dziedziny sztucznej inteligencji/uczenia maszynowego których "nie da
się" zrobić w javie. W c++ zajmują ~10-30x mniej pamięci (co jest
problemem gdy podstawą są gigabajty) ale RapidMiner jest akurat napisany
w javie i zostaje rzeźbienie z jni.

--
Pozdrawiam
Michoo

do góry

On 11.07.2013 05:16, A.L. wrote:
> On Wed, 10 Jul 2013 01:00:35 -0700 (PDT), Maciej Sobczak
> <s...@g...com> wrote:
>
> "Why mobile web apps are slow"
>
> Nie pzrez GC. Pzrez debilnosc systemu Android.

Rozwiń.

Zauważyłeś, że mowa jest o "WEB apps"?

--
Pozdrawiam
Michoo

do góry

On 11.07.2013 11:46, Stachu 'Dozzie' K. wrote:

> Michoo, na miłość Boską, przejrzyj jeszcze raz przyzwoity słownik (taki
> z zasadami interpunkcji).

Gdy piszę na szybko - zapomnij, mogę ewentualnie nie pisać albo ty
możesz nie czytać.

--
Pozdrawiam
Michoo

do góry

On 7/11/2013 11:46 AM, Stachu 'Dozzie' K. wrote:
> On 2013-07-11, Michoo <m...@v...pl> wrote:
> [...]
>> GC też zazwyczaj daje też dużą wolność a w praktyce czasami zmusza do
> ^--- przecinek
>> zupełnie niepotrzebnego obchodzenia - nie ma rozwiązań do wszystkiego
>> idealnych.
> [...]
>> Jak to robiłem w C++ to aby z jednej strony nie bawić się w ręczne
> ^--- przecinek
>> new/delete a z drugiej nie cieknąć pamięcią miałem w obiektach
> ^--- przecinek
>> opakowujących algorytmy std::vector<shared_ptr<T> > freeMeLater a sam
> przecinek ---^
>> algorytm działał już na wskaźnikach. Było szybkie i dawało gwarancję, że
>> w momencie gdy dane przestaną być używane wszystko się ładnie sprzątnie.
> ^--- przecinek
> [...]
>> Ludzie od C++ w większości muszą pamiętać o pamięci. Użytkownicy GC w
>> większości nie muszą. Mi chodzi o to, żeby pamiętać jedynie o nie
>
> Ci chodzi o to?
> http://poradnia.pwn.pl/lista.php?id=5375
> http://poradnia.pwn.pl/lista.php?id=523
> http://poradnia.pwn.pl/lista.php?id=5842
>
>> zepsuciu pamięci (być może za cenę dodatkowego wektora tu i uwdzie[*]) a
>> reszta się zrobi sama.
>
> "Ówdzie".
>
>> [*] Zauważ, że w języku to może się robić automatycznie na zasadzie np
>> operatora lNew który tworzy obiekt i wiąże jego czas życia z opakowującą
> ^--- przecinek
>> funkcją czy klasą.
>
> Michoo, na miłość Boską, przejrzyj jeszcze raz przyzwoity słownik (taki
> z zasadami interpunkcji).
>
Zawsze mnie fascynuje skad sie polonisci na technicznych grupach biora.
Wez moze poudzielaj sie na forum pisania wierszy czy cos. Wybacz ale
mnie komplentnie nie interesuje ja sie "mi chodzi o to" pisze, natomiast
opinie Michoo o GC jak najbardziej.


Pozdrawiam

Marek

do góry

On 11.07.2013 10:04, Maciej Sobczak wrote:
> W dniu czwartek, 11 lipca 2013 03:18:34 UTC+2 użytkownik A. L. napisał:
>

>> OK, ja mam tak isystem ktory ma cos kolo 3 tysiecy klas.
>
> Ilość klas nie ma kompletnie żadnego znaczenia. Uzgodnijmy więc, że
> masz ich 3 miliony, niech ten system wygląda jeszcze poważniej, nie
> wpływa to na dalsze rozważania.

Obawiam się, że w javie wcześniej trafisz na którąś z 16-bitowych ścian ;)

>
>> Obiekty owych klas organizowane sa w struktury zwane "hypergraph".
>
> O, i to dopiero ma znaczenia. Nawet jeśli w programie jest tylko
> jedna klasa.

Tylko nadal pozostaje pytanie (ok, w javie się tego nie da inaczej,
week-reference jest mało znane i upierdliwe w stosowaniu) jak wygląda
ownership i czas życia obiektów?

W przypadku bez GC zazwyczaj(oczywiście nie zawsze) na etapie tworzenia
struktury danych mamy jakąś mapę/listę/tablicę w której umieszczamy nowo
tworzone obiekty i z której je wyszukujemy tworząc kolejne krawędzie - w
takiej sytuacji czas życia może być powiązany z tą strukturą.

GC oczywiście daje możliwość zwalniania obiektów w czasie, gdy wypadają
one z hipergrafu i jeżeli właśnie tego potrzebujemy, to jest to właśnie
owo specyficzne zastosowanie w którym przy braku GC musielibyśmy je i
tak napisać. Jeżeli natomiast nie potrzebujemy zwalniania obiektów w
czasie pracy algorytmu to GC jest tylko zbędnym kosztem.

>
> Z punktu widzenia mainstreamu pytanie jest następujące: czy GC
> powinien być obowiązkowym elementem systemu, niezależnie od tego, co
> ten system robi.

Tu odpowiedź jest bolesna - tak, bo na rynku brakuje dobrych
programistów i obawiam się, że spora grupa dostępnych nie poradzi sobie
bez GC.

Natomiast cały czas uważam, że język który z jednej strony zabierał z
przed programisty konieczność zarządzania pamięcią ręcznie a z drugiej
strony wymuszał odpowiednie ustalenie własności obiektów na etapie
projektu byłby ciekawy.


--
Pozdrawiam
Michoo

do góry

Dnia pamiętnego Thu, 11 Jul 2013 12:57:15 +0200, Michoo wyjmując peta
oznajmił:

> On 11.07.2013 10:04, Maciej Sobczak wrote:
>> W dniu czwartek, 11 lipca 2013 03:18:34 UTC+2 użytkownik A. L. napisał:

>> Ilość klas nie ma kompletnie żadnego znaczenia. Uzgodnijmy więc, że
>> masz ich 3 miliony, niech ten system wygląda jeszcze poważniej, nie
>> wpływa to na dalsze rozważania.
>
> Obawiam się, że w javie wcześniej trafisz na którąś z 16-bitowych ścian ;)

Jakich 16-bitowych ścian? Jedyne jakie znam są w formacie plików .class,
ale tu nie może chodzić akurat o te.

>>> Obiekty owych klas organizowane sa w struktury zwane "hypergraph".
>>
>> O, i to dopiero ma znaczenia. Nawet jeśli w programie jest tylko
>> jedna klasa.
>
> Tylko nadal pozostaje pytanie (ok, w javie się tego nie da inaczej,
> week-reference jest mało znane i upierdliwe w stosowaniu) jak wygląda
> ownership i czas życia obiektów?

Michoo, życzliwie: nie tygodniowa referencja, tylko słaba (weak).

Weak-rwfs może używa się niezbyt często, ale owszem, dla uniknięcia
memory leaków w Javie, najczęściej spowodowanych trzymaniem dużych
chmur obiektów od gc root porzez albo niezwalnianą instancję lub
statyczne pola klas, które nigdy nie przestają być potrzebne. Ja się
spotkałem z tym, że najczęstsze dwa miejsca to monitoring, który
trzyma weak-refs do obiektów będąc singletonem, i wszelkie formy
stosów.

> W przypadku bez GC zazwyczaj(oczywiście nie zawsze) na etapie tworzenia
> struktury danych mamy jakąś mapę/listę/tablicę w której umieszczamy nowo
> tworzone obiekty i z której je wyszukujemy tworząc kolejne krawędzie - w
> takiej sytuacji czas życia może być powiązany z tą strukturą.
>
> GC oczywiście daje możliwość zwalniania obiektów w czasie, gdy wypadają
> one z hipergrafu i jeżeli właśnie tego potrzebujemy, to jest to właśnie
> owo specyficzne zastosowanie w którym przy braku GC musielibyśmy je i
> tak napisać. Jeżeli natomiast nie potrzebujemy zwalniania obiektów w
> czasie pracy algorytmu to GC jest tylko zbędnym kosztem.

Dokładnie. W rpzypadku grafów najłatwiej jest użyć zwykłych tablic,
które zwalania się po zakończeniu, albo trzymać bitowe maski użycia
indeksu oraz stos najbliższej maski z wolnym indeksem. Robiliśmy
takie rzeczy dla grafów zajmujących kilkadziesiąt czy kilkaset GB.

Hipergraf różni się tylko dodatkowymi setami, co niczym nie odbiega
od dołączonych do zwykłego grafu informacji dodatkowych pod względem
samej struktury danych.

>> Z punktu widzenia mainstreamu pytanie jest następujące: czy GC
>> powinien być obowiązkowym elementem systemu, niezależnie od tego, co
>> ten system robi.
>
> Tu odpowiedź jest bolesna - tak, bo na rynku brakuje dobrych
> programistów i obawiam się, że spora grupa dostępnych nie poradzi sobie
> bez GC.

Czasami wystarcza odpowiedni framework i wzięcie programistów w kamasze
mówiąc "macie robić tak i tak, zawsze i wszędzie". Z jakiegoś powodu
programiści lubiący Javę nie lubią takich "ograniczeń wolności".

> Natomiast cały czas uważam, że język który z jednej strony zabierał z
> przed programisty konieczność zarządzania pamięcią ręcznie a z drugiej
> strony wymuszał odpowiednie ustalenie własności obiektów na etapie
> projektu byłby ciekawy.

Jestem mocno zaciekawiony. Mógłbyś rozwinąć, chyba że ktoś czegoś takiego
próbował i masz linka?

--
Edek

do góry

On Thu, 11 Jul 2013 01:04:24 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>W dniu czwartek, 11 lipca 2013 03:18:34 UTC+2 użytkownik A. L. napisał:
>
>> OK, ja mam tak isystem ktory ma cos kolo 3 tysiecy klas.
>
>Ilość klas nie ma kompletnie żadnego znaczenia. Uzgodnijmy więc, że masz ich 3
miliony, niech ten system wygląda jeszcze poważniej, nie wpływa to na dalsze
rozważania.
>
>> Obiekty owych
>> klas organizowane sa w struktury zwane "hypergraph".
>
>O, i to dopiero ma znaczenia. Nawet jeśli w programie jest tylko jedna klasa.
>
>Tak czy inaczej: rozumiem, że wg Ciebie GC może być użytecznym narzędziem w
*specjalistycznych* i *niszowych* zastosowaniach. Otóż zgadzam się od lewej do
prawej, podobnie jak w przypadku każdego innego specjalistycznego narzędzia.
>
>Wyobraź sobie jednak, że te "mobile web apps" nie mają 3 milionów klas
zorganizowanych w struktury zwane "hypergraph". W związku z tym przydatność GC w
systemach z "hypergraph" ma się nijak do jego użyteczności w "mobile web apps".
Proste?
>
>Z punktu widzenia mainstreamu pytanie jest następujące: czy GC powinien być
obowiązkowym elementem systemu, niezależnie od tego, co ten system robi.
>
>Najwyraźniej nie przeczytałeś tego artykułu, bo gdybyś przeczytał, to byś zobaczył
odniesienie do Apple'a, który *wywalił* GC ze swojej platformy, co spotkało się z
wielkim aplauzem najbardziej zainteresowanych, czyli programistów. W tym kontekście
Twoje twierdzenie, że bez GC się nie da, jest oderwane od rzeczywistości. W
rzeczywistości okazuje się, że nie dość że bez GC się da, to nawet da się lepiej -
przynajmniej w tych niespecjalistycznych, nieniszowych zastosowaniach.
>
>> Wspolczesne odsmiecacze sa dosyc skomplikwoane ale efektywne.
>
>Artykuł pokazuje (wykres w ~połowie strony), w jakim zakresie są efektywne - tylko
wtedy gdy masz +6x więcej RAMu, niż potrzebujesz. Przy marginesie -4x GC zachowuje
się jak kotwica.


Na pewno ciekawie Pan pisze. Ale nei bedze cztal linii ktore maja po
500 znakow ciurkiem

A.L.

do góry

On Thu, 11 Jul 2013 09:46:51 +0000 (UTC), "Stachu 'Dozzie' K."
<d...@g...eat.some.screws.spammer.invalid> wrote:

>
>Michoo, na miłość Boską, przejrzyj jeszcze raz przyzwoity słownik (taki
>z zasadami interpunkcji).

Kolego, jestescie mlodym internauta, wiec nie wiecie jeszcze ze od
czasow protokolu uucp wytykanie na usenecie ortografii uchodzi za
ordynarne chamstwo.

Ale to nic takiego, z czasem Kolega zapozna sie z zwyczajami.
Wytrwalosci tylko tzreba...

A.L.

do góry