On Sat, 22 Nov 2014 13:17:03 -0600, "Pszemol" <P...@P...com>
wrote:

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

Cytat jest taki sobie bo nie mowi ZCO bylo mierzone i w jakich
warunkach

Lepsze zrodlo jest tutaj

http://www.devahead.com/blog/2011/12/coding-for-perf
ormance-and-avoiding-garbage-collection-in-android/

A.L.

do góry

W dniu 2014-11-22 o 21:26, W pisze:

> 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

A co z kólturą dyskusji? I poszanowaniem innego człowieka?



--
pozdrawiam
Piotr
XLR250&bmw_f650_dakar

do góry

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:m4qned$86m$...@d...me...

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

Tak myślałem, co drugiemu elektronikowi się zdaje, że ma duże skillsy
programistyczne bo mu programy działają. Nie czarujmy się, to są
programiątka. Tyci, tyci.

do góry

"W" <w...@w...pl> wrote in message news:XnsA3EDDA07CBC32wuathome@at.home...
> 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...

Nie podaję się wcale za eksperta. Zwłaszcza nie eksperta od Java.

> primo - java to nie jvm;

A kto tu twierdził i gdzie, że Java to jest to samo co java virtual machine?

> po wtóre
> - głupie ARC jest i w obj-c i w swifcie.

A kto tu twierdzi że nie ma?
Jak widać działa jednak dużo lepiej niż ten w Andku, skoro taka jest
duża różnica w wydajności między Andkiem a iOS że trzeba 3x
więcej RAMu w Andku aby zrównać się z iOS z 1Gb RAMu.

do góry

"A.L." <a...@a...com> wrote in message
news:jcu17admr7kielbuephp208lvcq0tk5jsf@4ax.com...
>>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?
>
> Cytat jest taki sobie bo nie mowi ZCO bylo mierzone i w jakich
> warunkach
>
> Lepsze zrodlo jest tutaj
>
> http://www.devahead.com/blog/2011/12/coding-for-perf
ormance-and-avoiding-garbage-collection-in-android/

No i co z niego dla Ciebie wynika? Zrewidowałeś swe stanowisko?

do góry

"Ghost" <g...@e...com> wrote in message
news:54710a34$0$20327$65785112@news.neostrada.pl...
> Użytkownik "Pszemol" napisał w wiadomości grup
> dyskusyjnych:m4qned$86m$...@d...me...
>
>>>>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).
>
> Tak myślałem, co drugiemu elektronikowi się zdaje, że ma duże skillsy
> programistyczne bo mu programy działają. Nie czarujmy się, to są
> programiątka. Tyci, tyci.

Nie masz podstaw do wyciągania wniosków o rozmiarze moich programów.
No chyba że dla Ciebie "embedded" oznacza tylko 8-bitowego PICa :-)))))
Ale wtedy to już nie jest mój problem że masz ograniczone horyzonty.

do góry

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

>> Tak myślałem, co drugiemu elektronikowi się zdaje, że ma duże skillsy
>> programistyczne bo mu programy działają. Nie czarujmy się, to są
>> programiątka. Tyci, tyci.

>Nie masz podstaw do wyciągania wniosków o rozmiarze moich programów.

Mam pewność, że nie napisałeś się w życiu dużo kodu.

do góry

On Sat, 22 Nov 2014 16:19:44 -0600, "Pszemol" <P...@P...com>
wrote:

>"A.L." <a...@a...com> wrote in message
>news:jcu17admr7kielbuephp208lvcq0tk5jsf@4ax.com...
>>>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?
>>
>> Cytat jest taki sobie bo nie mowi ZCO bylo mierzone i w jakich
>> warunkach
>>
>> Lepsze zrodlo jest tutaj
>>
>> http://www.devahead.com/blog/2011/12/coding-for-perf
ormance-and-avoiding-garbage-collection-in-android/
>
>No i co z niego dla Ciebie wynika? Zrewidowałeś swe stanowisko?

jakie stanowisko?

ja mowie tylko ze jak chce sie uzywskac dobar sparwnosc, to tzreba
wiedziec jak to robic. Nie mozan programwoanc "na pale"

A.L.

do góry

"A.L." <a...@a...com> wrote in message
news:ps327a5j5eq28n86ughbcb0p6r4orcb662@4ax.com...
>>No i co z niego dla Ciebie wynika? Zrewidowałeś swe stanowisko?
>
> jakie stanowisko?
>
> ja mowie tylko ze jak chce sie uzywskac dobar sparwnosc, to tzreba
> wiedziec jak to robic. Nie mozan programwoanc "na pale"

To obowiązuje przecież zawsze i wszędzie - niezależnie od tego
jakiego narzędzia się używa i w jakim środowisku tworzy programy.
Właśnie o tym mówiłem że języki w których środowisko zdejmuje
z programisty odpowiedzialność za troszczenie się o zarządzenie
pamięcią mogą prowokować do niechlujnego pisania programów.

"Co? Limity pamięci? A niech się kompilator/interpreter/VM martwi.
A sobie radośnie będę tworzył program a inni niech sprzątają" :-)

Niestety nigdzie tak nie ma.
Ale to rozmowa na news:pl.comp.programming a nie tutaj.

do góry