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.

A.L.