On Sat, 22 Nov 2014 17:12:51 +0000 (UTC), Pszemol <P...@P...com>
wrote:

>A.L. <a...@a...com> wrote:
>> On Sat, 22 Nov 2014 07:03:07 -0600, "Pszemol" <P...@P...com>
>> wrote:
>>
>>> "Marcin N" <m...@o...pl> wrote in message
>>> news:54702897$0$2844$65785112@news.neostrada.pl...
>>>> W dniu 2014-11-22 06:41, Pszemol pisze:
>>>>> Ano tu jest to wyjaśnione - przyczyna dla której Android wymaga
>>>>> dużo więcej pamięci do szybkiej pracy jest znowu Java i garbage
>>>>> collection:
>>>>> http://www.quora.com/How-come-the-iPhones-1-GB-RAM-i
s-touted-to-be-able-to-compete-with-more-than-2-GB-R
AM-of-Android-phones/answers/7061202
>>>>>
>>>>>
>>>>> Dopiero Android z 3G ramu na pokładzie będzie pracował tak szybko
>>>>> jak iPhone z 1G ramu - a mniej kostek pamięci to mniej prądu z baterii!
>>>>
>>>> Widać, jak niechlujnie pisane są programy w dzisiejszych czasach.
>>>> Potrzebne są gigabajty, żeby użyć jakichś prostych aplikacji, które
>>>> mogłyby się spokojnie zmieścić w megabajtach.
>>>
>>> Wiesz co Ci powiem - zawsze mi mówiono że Java jest nieefektywna
>>> i że ten cały wychwalany przez nielubiących wskaźników w C/C++
>>> mechanizm automatycznego zarządzania pamięcią jakoś tam działa
>>> ale niezbyt efektywnie - więc nie jest to dla mnie nowością, że coś
>>> co wykorzystuje Javę nie będzie efektywne, będzie rozrzutne jeśli
>>> chodzi o pamięć czy inne zasoby procesora...
>>> Co mnie zszokowało to jak dowiedziałem się JAK BARDZO jest to
>>> nieefektywne i jak bardzo marnotrawne. Spodziewałem się czegoś
>>> na kształt 10-20% a nie że stosunek całej pamięci procesora do tej
>>> używanej części ma być jak 4:1 czy nawet jak piszą 8:1 aby to szybko
>>> działało... To jest dla mnie po prostu tak absurdalne że wręcz śmieszne.
>>
>> To jest fragment dyskusji na temat jezyka Swift:
>>
>> Garbage collection: It's likely that Apple considered that ARC was
>> good enough in most situations, and it makes interoperability with
>> Objective-C (compatibility in terms of memory management) much easier
>> to handle. Still, this would give me trouble. Lack of proper garbage
>> collection means more memory bugs to hunt down.
>>
>> JEzyk Swift (podobnie jak Objectiwe C) MA odsmiecacz, konkretnie
>> implementacje zwana "reference counting". Ma sie to tak do
>> wspolczesnych odsmiecaczy jak woz drabiniasty do Mercedesa. To jest
>> wynajazek spzred 30 lat.
>>
>> Jednoczesnie, jak pisza wyzej, brak porzadnego odsmeicacza kreuje
>> problemy z wyciekaniem pamiei ("memory leaks") i skutkuje zwiekszonymi
>> kosztami i czasem niezbednym na zrobienie i pzretestowanei aplikacji.
>> Generalnie, gospodarka pamiecia w systemach bez GC jest mniej
>> efektywna niz w systemach z GC i skutkuje aplikacjami wymagajacymi
>> wiecej pamieci.
>>
>> Zapewne dlatego wsztsko w Apple jest drozsze. Podbnie jak drozszy
>> bylby stol robiony heblem i krajzegoa w porownaniu ze stolem zeobionym
>> przy pomocy automatycznych obrabiarek
>>
>> Wspolczesne GC (zwlaszcza w javie) dostarczane sa w wersji "parallel".
>> Oznacza to ze GC moze byc wykonywany w osobnym watku, "w tle"
>> aplikacji. W koncu, gdy pzrecietny procesor ma 4 "cores" tzreba je
>> jakos wykorzystac.
>
>Czy autor tych słów na ktore się tu powołujesz jest dla Ciebie jakimś
>autorytetem?
>Bo nie przytoczyłeś źródła tej wypowiedzi - może autor nie wie o czy mówi?
>
>Ja mam ponad 20-letnie doświadczenie w programowaniu w C/C++ i żadna pamięć
>w moich programach nie wycieka...
>

To jeszcze ciekawe jakie to sa programy

>Mam pewne przeczucie na podstawie pracy w innych językach programowania
>gdzie nie deklaruje się rozmiaru/typu zmiennej ani nie alokuje się dla niej
>specyficznego obszaru w pamieci RAM (ale brak bezposredniego doswiadzczenia
>w Javie)

Java jest akurat jezykiem silnie typowanym. Czy w C/C++ deklaruje sie
GDZIE w pamieci zmienna bedzie ulokowana? Jakos sobie nie przypominam.

> ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
>korzystanie z zasobow pamieci...
>

Niby dlaczego? Pamiec w Javie alokuje sie tak samo jak w C++. Czas
zycia obiektu w Javie kontroluje sie pzrez referencje - jak dlugo jest
referencja do obiektu, tak dlugo nei bedzie on "odsmiecony". Znane sa
techniki programwoania gdzie obiektow sie nei zwalnia (to znaczy,
zachowuje sie referencje), a trzyma zbior obiektow do pozniejszego
wykorzystania. Co parwda, takie techniki stosowano w czasach Javy 1.1,
teraz sa juz niepotzrebne.

Bez odsmiecacza nei da sie efektywnie napisac w miare skomplikowwnego
programu. Gdy w pewnym momencie mamy zaalokowane, powiedzmy, 1000
obiektow i tworaz one skomplikowany graf zaleznosci, reczena
dealokacja ani nie am sensu ani szans na powodzenie. Zwlaszcza jezeli
taka struktuar tworzona jest dynamicznie


Zreszta, C++ tez ma "proteze" odsmiecacza - patrz "smart pointers" w
bibliotece Boost. Powszechnie tez stosowany jest pzrez programistow
C++ odsmiecacz zwany Boehm garbage collector. Biblioteka taka

A.L.