Trafiłem na fajny artykuł:

http://sealedabstract.com/rants/why-mobile-web-apps-
are-slow/

Dosyś długawy, ale w ramach wakacyjnego rozruszania grupy polecam.
W szczególności tak gdzieś w połowie strony jest wykres pokazujący jak GC wpływa na
wydajność programu w zależności od pamięci, która jest dostępna w systemie w relacji
do tego, jaka jest faktycznie potrzebna.

W ogóle jest tam trochę mocnych stwierdzeń. Sporo odniesień do wszelakich obecnie
używanych języków programowania. Polecam.

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

do góry

W dniu środa, 10 lipca 2013 10:00:35 UTC+2 użytkownik Maciej Sobczak napisał:
> Trafiłem na fajny artykuł:
>
>
>
> http://sealedabstract.com/rants/why-mobile-web-apps-
are-slow/
>
>
no w miare ciekae tj mozna sie czegos dowiedziec
choc przydlugie;
nie wiem czy to 5 krotne 'zwolnienie' js wobec
jakiegos przecietnego c jest ze tak powiem 'stałe'
(podbindowanych funkcji to chyba nie dotyczy wiec
jest to moze staly koszt skryptu)
(tak czy owak 5x to nie az tak duzo)

do góry

On Wed, 10 Jul 2013 01:00:35 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>Trafiłem na fajny artykuł:
>
>http://sealedabstract.com/rants/why-mobile-web-apps
-are-slow/


Jedno wielkie wolanie: GARBAGE COLLECTOR IS BAD!

Co jest idiotyzmem samym w sobie

A.L.

do góry

On 10.07.2013 10:00, Maciej Sobczak wrote:
> Trafiłem na fajny artykuł:
>
> http://sealedabstract.com/rants/why-mobile-web-apps-
are-slow/
>
> Dosyś długawy, ale w ramach wakacyjnego rozruszania grupy polecam. W
> szczególności tak gdzieś w połowie strony jest wykres pokazujący jak
> GC wpływa

Jednym z przykładów języków z GC jako kontrast dla objC jest podany
python. W PyPy rzeczywiście jest GC ale standardowy cpython cały czasu
używa właśnie zliczanie referencji a zadaniem "GC" jest jedynie
wykrywanie cykli - dopóki się ich nie stworzy jest całkowicie zbędny.

Inna sprawa, że parę lat temu walczyłem z aplikacją serwerową w pythonie
która tworzyła cykliczne zależności z finalizatorami.


> na wydajność programu w zależności od pamięci, która jest
> dostępna w systemie w relacji do tego, jaka jest faktycznie
> potrzebna.

Niedawno odbyłem walkę z GC w javie - optymalizacje, które porobiłem
zawierają się w pierwszej 10 "czego nie robić w javie" jak np ręczne
wołanie gc() wielokrotnie w trakcie inicjalizacji aby nie dopuścić do
rozrostu eden space. Pracująca aplikacja pomimo zmniejszenia zużycia
pamięci prawie dwa razy nadal mogłaby mieć jeszcze ~30% mniej - bo po
starcie mniej-więcej tyle się marnuje.

>
> W ogóle jest tam trochę mocnych stwierdzeń. Sporo odniesień do
> wszelakich obecnie używanych języków programowania. Polecam.
>
Ja od wielu lat twierdzę, że klasyczne GC to straszne marnowanie
zasobów. Tylko brakuje wygodnego, kompilowanego języka ze zliczaniem
referencji. Można w C++ coś takiego uzyskać, ale łatwość użycia i
dostępne narzędzia są gorsze niż dla javy/c#. Liczyłem, że czymś takim
będzie PyPy - nieskomplikowany język z dobrym JITem i RC, ale twórcy
poszli w stronę GC...

--
Pozdrawiam
Michoo

do góry

On 10.07.2013 16:51, A.L. wrote:
> On Wed, 10 Jul 2013 01:00:35 -0700 (PDT), Maciej Sobczak
> <s...@g...com> wrote:
>
>> Trafiłem na fajny artykuł:
>>
>> http://sealedabstract.com/rants/why-mobile-web-apps-
are-slow/
>
>
> Jedno wielkie wolanie: GARBAGE COLLECTOR IS BAD!

W zastosowaniach gdy nie mamy duużo pamięci? Jest.

>
> Co jest idiotyzmem samym w sobie

Idiotyzmem jest panująca od wielu lat moda pchania wszędzie GC. Tak, GC
jest wygodne ale płaci się za nie cały czas. Jak się ma serwery z
nadmiarem wolnej pamięci to koszt jest względnie mały(o czym artykuł
wspomina), ale jest. Jak brakuje pamięci to się marnuję masę zasobów na
walkę z GC. Walkę, której przy zliczaniu referencji by nie było bo
zazwyczaj

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

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.


--
Pozdrawiam
Michoo

do góry

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?

A.L.

do góry

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,
np w jakimś algorytmie na grafie skierowanym głownie usuwającym
krawędzie.


> 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ą?
;-)

pzdr
bartekltg

do góry

On Thu, 11 Jul 2013 01:50:45 +0200, Michoo <m...@v...pl> wrote:

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

OK, ja mam tak isystem ktory ma cos kolo 3 tysiecy klas. Obiekty owych
klas organizowane sa w struktury zwane "hypergraph". Jak sobie
wyobrazasz "wykrywanie cykli" w takich strukturach, i ile czasu to
zajmie? I czy na pewno "wykrywanie cykli" rozwiaze wszystkie problemy
z gospodarka pamiecia? Czy na pewno wszystkie cykle zostana wykryte?


Wspolczesne odsmiecacze sa dosyc skomplikwoane ale efektywne. Java ma
kilka odsmiecaczy, a sam odsmeicacz wymaga "nastrojenia". Wstepne
informacje sa na przykald tutaj

http://www.oracle.com/technetwork/java/javase/gc-tun
ing-6-140523.html

Sugestia ze samemu mzona zrobic gospodarke pamiecia bardziej
efektywnie niz przy pomocy GC naleza do tej samej kategorii twierdzen
ze mozna przyspieszyc program w C wstawiajac kawalki w asemblerze

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

Watpie. Kilkanascie lat pracy w Smalltalku, Javie i Prologu, oraz
nieudane proby uzycia C++ przekonaly mnei dowodnie ze bez GC sie nei
da. No, chyba ze czyjas dzialalnosc ogranicza sie do "pierdykniecia
bazki szlauchow gumowych i kaloszy dla Miejskiego Pzresiebiorstwa
kanalizacyjnego"

A.L.

P.S> Krytykantom GC polecam ksiazke

The Garbage Collection Handbook: The Art of Automatic Memory
Management, Richard Jones, 2011

Niezbedna do tego zeby zrozumiec jak dziala GC, a zrozumienie jak
dziala GC jest neizbedne do tego aby GC prawidlowo uzyc i nastroic

do góry

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. Nie wiem jak jest w
iPhone, ale podejzrewam ze tak samo

A.L.

do góry

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.

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

do góry