eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.telefonia.gsmRe: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
Ilość wypowiedzi w tym wątku: 19

  • 1. Data: 2014-11-22 07:09:32
    Temat: Re: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
    Od: Marcin N <m...@o...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.


    --
    MN


  • 2. Data: 2014-11-22 14:03:07
    Temat: Re: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
    Od: "Pszemol" <P...@P...com>

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


  • 3. Data: 2014-11-22 17:07:58
    Temat: Re: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
    Od: A.L. <a...@a...com>

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

    Nonsens. Trzeba umiec programowac. Niestety, mlodzi miszczowie
    klawiatury nie maja zielonego pojecia jak pisac programy w systemach
    wyposazonych w garbage collector

    A.L.


  • 4. Data: 2014-11-22 17:19:36
    Temat: Re: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
    Od: A.L. <a...@a...com>

    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.


  • 5. Data: 2014-11-22 18:12:51
    Temat: Re: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
    Od: Pszemol <P...@P...com>

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

    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) ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
    korzystanie z zasobow pamieci...

    Jezykiem Swift chetnie sie zainteresuje.


  • 6. Data: 2014-11-22 18:37:05
    Temat: Re: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
    Od: masti <g...@t...hell>

    Pszemol wrote:

    > Ja mam ponad 20-letnie doświadczenie w programowaniu w C/C++ i żadna pamięć
    > w moich programach nie wycieka...

    i to by było na tyle jeśli chodzi o Twoje doświadczenie. Jeszcze się
    musisz dużo nauczyć

    --
    mst <at> gazeta <.> pl
    "-Mam lęk gruntu! -Chyba wysokości?
    -Wiem co mówię. To grunt zabija!" T.Pratchett


  • 7. Data: 2014-11-22 19:03:38
    Temat: Re: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
    Od: "Ghost" <g...@e...com>



    Użytkownik "Pszemol" napisał w wiadomości grup
    dyskusyjnych:m4qg6j$v7i$...@d...me...

    >Ja mam ponad 20-letnie doświadczenie w programowaniu w C/C++ i żadna pamięć
    >w moich programach nie wycieka...

    Wpisz to sobie w CV.


  • 8. Data: 2014-11-22 19:56:55
    Temat: Re: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
    Od: A.L. <a...@a...com>

    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.


  • 9. Data: 2014-11-22 20:17:03
    Temat: Re: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
    Od: "Pszemol" <P...@P...com>

    "A.L." <a...@a...com> wrote in message
    news:ifm17a961q00ft2i33ag4otoe0jl4d84nl@4ax.com...
    >>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?

    Zero komentarza?

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

    Głównie jest to embedded computing (nie pecety).

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

    Na pecetach pewnie nie deklaruje się zwyczajowo, choć też można.
    Ale na innych platformach często chcesz wiedzieć która zmienna
    w której kostce siedzi bo np. ta kostka ma podtrzymanie bateryjne
    a druga go nie ma...

    >> ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
    >>korzystanie z zasobow pamieci...
    >
    > Niby dlaczego? Pamiec w Javie alokuje sie tak samo jak w C++.

    Jasne. Są pointery/wskaźniki do fizycznej pamięci operacyjnej :-)

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

    W technice embedded unika się dynamicznej alokacji pamięci
    i związanej z nią fragmentacją wolnej pamięci - to są urządzenia
    które mają pracować bez restartu/resetu miesiącami, latami
    i nic tam nie może się samo w czasie używania "bałaganić"
    ani śmiecić żeby trzeba było śmieci zbierać...

    Ale oczywiście smartfone nie zawsze można tak zakwalifikować.
    Tym dzisiejszym smartfonom bliżej pecetowi niż komputerom embedded.

    > 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

    Ilość obiektów rzędu 1000 jest nieogarnięcia dla jednego człowieka, ale
    dla komputera nie stanowią takie liczby obiektów żadnego problemu...
    Co jest ważniejsze aby ogarnąć strukturę danych programu i stworzyć
    jako programista mechanizmy którymi komputer za nas będzie tymi
    obiektami zarządzał.

    > 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

    Bibliotek różnych i środowisk można dołożyć tysiące i zmienia to
    jedynie punkt widzenia dla aplikacji która z biblioteki korzysta...
    Ani nie masz gwarancji że ktoś zrobi alokację pomijając bibliotekę
    ani nie masz gwarancji że sama biblioteka nie ma jakiegoś robala.

    Ale chyba oddaliliśmy się nieco od tematu głównego...
    Sugerujesz może że inicjujący ten wątek cytat ma błędy?
    Z czymś się nie zgadzasz? Może podsumowałbyś ze swojej strony?


  • 10. Data: 2014-11-22 21:26:34
    Temat: Re: Czemu iPhone z 1G ramu jest szybszy od smartfona z Andkiem i 3G?
    Od: W <w...@w...pl>

    Pszemol wystukał, co następuje:

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

    Borze... Ty na prawdę jesteś ignorantem... primo - java to nie jvm; po wtóre
    - głupie ARC jest i w obj-c i w swifcie. Coś dzwoni, nawet wiesz że może to
    być kościół... a może jednak krowi dzwonek

strony : [ 1 ] . 2


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: