Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

[SGCL] Odśmiecania współbieżnego ciąg dalszy

64 views
Skip to first unread message

Sebastian Nibisz

unread,
Feb 23, 2008, 3:24:23 PM2/23/08
to
Witam.

Nadarzyła się okazja, aby zweryfikować działanie biblioteki SGCL na
platformie z procesorem wielordzeniowym.
Już po pierwszych testach okazało się, że biblioteka nie radzi sobie zbytnio
na takiej konfiguracji. Postanowiłem zweryfikować swoje założenia odnośnie
koncepcji współbieżnego działania systemu GC w bibliotece i w miarę
możliwości spróbować ją poprawić.

Po głębszej analizie algorytmu doszedłem do wniosku, że ogólne założenia
współbieżnej pracy systemu GC były prawidłowe. Biblioteka posiadała szereg
błędów w implementacji, które w szczególności ujawniały sie na platformie
wieloprocesorowej.

Biblioteka została gruntownie przebudowana. Pierwotne założenie, braku
potrzeby synchronizacji wątków aplikacji z wątkiem systemu GC, zostało
zachowane. Dodałem wsparcie dla systemów 64-bitowych, poprzez zniesienie
ograniczenia wielkości mapowanej pamięci (4GB).

Ze względu na wykorzystanie w bibliotece funkcji systemowych Windows,
biblioteka nadal przeznaczona jest jedynie na tę platformę systemową. Na
chwilę obecną, starałem się skupić na systemie, który znam najlepiej.

Na dzień dzisiejszy projekt biblioteki nie kompiluje się na kompilatorze GCC
(a przynajmniej od wersji 3.4 w dół), ponieważ w szablonie jednej z klas,
skorzystałem z dobrodziejstwa specjalizacji metod, co niestety jest trochę
niestandardowe. Postaram sie to zmienić później. Bibliotekę można
przekompilować na kompilatorach VC8 oraz VC9, na wsześniejszych nie
sprawdzałem.

SGCL nie wykorzystuje już biblioteki boost.

Zainteresowanych zachęcam do pobrania najnowszych plików projektu:
http://sourceforge.net/projects/sgcl/

Pozdrawiam.

- Bastek -

Paweł

unread,
Feb 23, 2008, 4:38:04 PM2/23/08
to
Sebastian Nibisz wrote:

> Na dzień dzisiejszy projekt biblioteki nie kompiluje się na kompilatorze
> GCC (a przynajmniej od wersji 3.4 w dół), ponieważ w szablonie jednej z
> klas, skorzystałem z dobrodziejstwa specjalizacji metod, co niestety jest
> trochę niestandardowe. Postaram sie to zmienić później.

tylko nie cofaj w rozwoju kodu :)
branch 3.4 jest juz dawno zamkniety, a wkrotce takze ten los spotka 4.1,
wiec radze sie skupic tylko na kompilowalnosci pod gcc >= 4.2

Adam Karpierz

unread,
Feb 25, 2008, 5:13:18 PM2/25/08
to
Użytkownik "Paweł" <root@[127.0.0.1]> napisał:

> tylko nie cofaj w rozwoju kodu :)
> branch 3.4 jest juz dawno zamkniety, a wkrotce takze ten los spotka 4.1,
> wiec radze sie skupic tylko na kompilowalnosci pod gcc >= 4.2

Nie sluchaj tego czlowieka !

>> Postaram sie to zmienić póĽniej.

Postaraj sie koniecznie :)
W zaprzyjaznionej firmie gcc 3.x bedzie jeszcze przez lata uzywany
(jak chyba w wiekszosci), a bardzo chcialbym wyprobowac Twoja biblioteke.

AK

Sebastian Nibisz

unread,
Feb 26, 2008, 4:35:03 AM2/26/08
to
> Na dzień dzisiejszy projekt biblioteki nie kompiluje się na kompilatorze
> GCC (a przynajmniej od wersji 3.4 w dół), ponieważ w szablonie jednej z
> klas, skorzystałem z dobrodziejstwa specjalizacji metod, co niestety jest
> trochę niestandardowe. Postaram sie to zmienić później. Bibliotekę można
> przekompilować na kompilatorach VC8 oraz VC9, na wsześniejszych nie
> sprawdzałem.

Udostępniłem wersję 0.8.2 biblioteki SGCL w której poprawiłem kompatybilność
kodu z kompilatorem GCC (wersja 3.4.2)
Dodałem testowy plik projektu dla środowiska Dev-Cpp.

Pozdrawiam.

- Bastek -

Adam Karpierz

unread,
Feb 26, 2008, 5:07:29 AM2/26/08
to
Sebastian

Jeszcze jedno pytanie z gatunku naiwnych:

Czym sie rozni/codaje wiecej ta biblioteka
w stosunku od boostowego/MSowego
shared_pointer-a ?

AK


Sebastian Nibisz

unread,
Feb 26, 2008, 5:48:07 AM2/26/08
to

Shared poiner jest niestety wielce niedoskonałym sposobem odśmiecania, gdyż
działa w oparciu o mechanizm zliczania referencji i ma cztery podstawowe
wady:

1. Nie zwalnia struktur cyklicznych.
2. Operacje na wskaźnikach są kosztowne (wymaga operacji atomowych).
3. Zwalnianie większych struktur, może doprowadzić do przepełnienia ramki
stosu.

struct Node
{
shared_ptr<Node> Next;
};

{
shared_ptr<Node> root(new Node);
shared_ptr<Node> node(root);

for (int x = 0; x < 1000000; ++x)
{
node = node->Next = shared_ptr<Node>(new Node);
}
} // <- KATASTROFA !!!

4. Zwalnianie większych struktur, może na dłuższy okres wstrzymać działanie
aplikacji (wymaga operacji atomowych).

Oczywiście niezaprzeczalna zaletą shared poiner, jest możliwość
deterministycznego zwalniania zasobów, co w typowym systemie GC jest
niemożliwe do uzyskania.

SGCL jest w pełni wspóbieżnym systemem GC (osobny wątek aplikacji), opartym
na algorytmie mark & sweep. Wątek GC działa niezależnie od innych wątków
aplikacji i nie musi być z nimi w żaden sposób synchronizowany.

Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej
implementacji systemu GC w jakimkolwiek języku czy środowisku.

Pozdrawiam.

- Bastek -

Artur Bać

unread,
Feb 26, 2008, 5:58:23 AM2/26/08
to
Sebastian Nibisz wrote:
> SGCL jest w pełni wspóbieżnym systemem GC (osobny wątek aplikacji),
> opartym na algorytmie mark & sweep. Wątek GC działa niezależnie od
> innych wątków aplikacji i nie musi być z nimi w żaden sposób
> synchronizowany.
>
> Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej
> implementacji systemu GC w jakimkolwiek języku czy środowisku.

.NET CLR

--

Artur

Sebastian Nibisz

unread,
Feb 26, 2008, 6:03:41 AM2/26/08
to
>> Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej
>> implementacji systemu GC w jakimkolwiek języku czy środowisku.
>
> .NET CLR

.NET CLR może mieć co najwyżej odśmiecacz przyrostowy a wątek GC musi być
synchronizowany z wątkami aplikacji.

Pozdrawiam.

- Bastek -

Adam Karpierz

unread,
Feb 26, 2008, 6:11:35 AM2/26/08
to
Użytkownik "Sebastian Nibisz" <EB...@poczta.onet.pl> napisał:

> Shared poiner jest niestety wielce niedoskonałym sposobem odśmiecania,
> gdyż działa w oparciu o mechanizm zliczania referencji i ma cztery
> podstawowe wady:

Swieta prawda

> Oczywiście niezaprzeczalna zaletą shared poiner, jest możliwość
> deterministycznego zwalniania zasobów, co w typowym systemie GC jest
> niemożliwe do uzyskania.

Mozna przebolec.
Rachunek zalet do wad zdecydowanie na korzysc gc.

> SGCL jest w pełni wspóbieżnym systemem GC (osobny wątek aplikacji),
> opartym na algorytmie mark & sweep. Wątek GC działa niezależnie od innych
> wątków aplikacji i nie musi być z nimi w żaden sposób synchronizowany.

To mnie wlasnie w Twojej implementacji zainteresowalo.
Nie widzialem 'smieciarki' do C++ o takim podejsciu.

> Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej
> implementacji systemu GC w jakimkolwiek języku czy środowisku.

Nie slyszalem tez, bo zwyczajnie sie nie znam/nie siedze w odsmiecarkach,
ale jelsi tak to gratuluje lecz.. podejrzewalbym jednak Jave i/lub .NET :).

AK

Artur Bać

unread,
Feb 26, 2008, 6:40:40 AM2/26/08
to

Nie cieprie GC :) to sie wogole nie sprawdza przy przetwarzaniu duzej
ilosci danych , duze chwilowe alokacje, przynajmiej ten z NET.


Seweryn Habdank-Wojewódzki

unread,
Feb 26, 2008, 6:55:29 AM2/26/08
to
Witam

Adam Karpierz wrote:

>> Oczywiście niezaprzeczalna zaletą shared poiner, jest możliwość
>> deterministycznego zwalniania zasobów, co w typowym systemie GC jest
>> niemożliwe do uzyskania.
>
> Mozna przebolec.
> Rachunek zalet do wad zdecydowanie na korzysc gc.

To zależy od celu. Taka generalizacja jest bardziej wadliwa niż wady smart
pointerów.

Powiedziałbym tak:

Średnio na komputerach klasy PC i lepszych z dużą ilością RAM-u GC może
ułatwić pisanie programu mielącego RAM.

Tam gdzie RAM trzeba szanować należy również przemyśleć skutki pracy z GC.

Pomijam aspekty wpływu GC an lenistwo i ignorancję koderów oraz ich zaufanie
do jego świątobliwości GC w sytuacjach kiedy np. potrzeba alokować/zwalniać
zasoby mające mocne ograniczenia (liczbowe/ilościowe) -- i to jest bardzo
groźne. Mam na myśli deskryptory plików, sokety, połączenia do baz danych,
rurki, obiekty i transakcje rozproszone itd.

Poza tym w swojej ocenie pominął Pan obiekty pośrednie czyli Alokatory,
które mogą łączyć zalety/wady GC i smart pointerów.

Temat był wiele razy walcowany. Takie jednolinijkowe podsumawania nikomu nie
są potrzebne.

Raczej cenne jest to, że w C/C++ można mieć GC i można go nie mieć w
zależności od potrzeb. I to jest ewidentna zaleta C/C++.

W innych językach, aby pokombinować przy GC trzeba się nahakować -- patrz
manuale o tunigu GC w Javie.

Pozdrawiam.

--
|\/\/|   Seweryn Habdank-Wojewódzki
\/\/

Sebastian Nibisz

unread,
Feb 26, 2008, 7:02:58 AM2/26/08
to
> Kiedys była mowa o jakims pdf-ie który opisuje zastosowane przez Ciebie
> algorytm, ale jakos teraz go nie moge znależć, czy jestes w stanie go
> udostepnić?

Biorąc pod uwagę zmiany w bibliotece, jakie zostały poczynione od wersji
0.8.1, dokument ten ma wiele rozbieżności i musiałbym go poprawic.
Z drugiej strony, nie widzę sensu tracenia czasu na poprawianiu dokumentu,
którego i tak prawie nikt nie będzie czytał.

Pozdrawiam.

- Bastek -

Sebastian Nibisz

unread,
Feb 26, 2008, 7:27:04 AM2/26/08
to
>>> Oczywiście niezaprzeczalna zaletą shared poiner, jest możliwość
>>> deterministycznego zwalniania zasobów, co w typowym systemie GC jest
>>> niemożliwe do uzyskania.
>>
>> Mozna przebolec.
>> Rachunek zalet do wad zdecydowanie na korzysc gc.
>
> To zależy od celu. Taka generalizacja jest bardziej wadliwa niż wady smart
> pointerów.

Taka generalizacja z małymi wyjątakami, jest jak najbardziej prawidłowa.
Poza systemami z bardzo ograniczonymi zasobami pamięciowymi, smart pointery
ze zliczaniem referencji, średnio się nadają do zarządzania pamięcią RAM.

> Powiedziałbym tak:
>
> Średnio na komputerach klasy PC i lepszych z dużą ilością RAM-u GC może
> ułatwić pisanie programu mielącego RAM.

Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to
pieniądź. Nikt nie będzie sie bawił w dużą optymalizację zużycia pamięci RAM
w aplikacji dla typowego sprzętu PC, bo to nie ma większego sensu.

> Tam gdzie RAM trzeba szanować należy również przemyśleć skutki pracy z GC.

Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z wbudowanym
systemem GC, jest coraz mniej obszarów w których pamięć aż tak bardzo trzeba
szanować.

> Pomijam aspekty wpływu GC an lenistwo i ignorancję koderów oraz ich
> zaufanie
> do jego świątobliwości GC w sytuacjach kiedy np. potrzeba
> alokować/zwalniać
> zasoby mające mocne ograniczenia (liczbowe/ilościowe) -- i to jest bardzo
> groźne. Mam na myśli deskryptory plików, sokety, połączenia do baz danych,
> rurki, obiekty i transakcje rozproszone itd.

GC nadaje się tylko i wyłacznie do zarządzania pamięcią RAM. Kto tego nie
rozumie, nie lepiej z GC nie korzysta.

Pozdrawiam.

- Bastek -

sop3k

unread,
Feb 26, 2008, 7:40:48 AM2/26/08
to


A jesli masz go pod ręką mógłbys przesłąć na sop3k at 02 dot pl? bede wdzieczny

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

Sebastian Nibisz

unread,
Feb 26, 2008, 7:56:38 AM2/26/08
to
> A jesli masz go pod ręką mógłbys przesłąć na sop3k at 02 dot pl? bede
> wdzieczny

Wysłałem.

Pozdrawiam.

- Bastek -

Adam Karpierz

unread,
Feb 26, 2008, 7:56:56 AM2/26/08
to
Użytkownik "Seweryn Habdank-Wojewódzki" <shw_...@wp.pl> napisał:

> Powiedziałbym tak:
>
> Średnio na komputerach klasy PC i lepszych z dużą ilością RAM-u
> GC może ułatwić pisanie programu mielącego RAM.

Panie Wojewodzki ! Prosze nie stulac nastepnych glupot.
Simula67 maila sobie gc (jako czesc jezyka a nie zewnetrzna lib czy tool)
i dzialala sobie na OSsie z calkowita pamiecia
32kW (slow 24 bitowych) wiec prosze dac juz spokoj z ta
idiotyczna 'krytyka' gc.

Na reszte Pana wypocin szkoda zwyczajnie klawiatury !

> W innych językach, aby pokombinować przy GC trzeba się nahakować -- patrz
> manuale o tunigu GC w Javie.

I badzo dobrze ze trzeba sie nahakowac
Hakowanie zniecheca (i o to chodzi).

AK


Adam Karpierz

unread,
Feb 26, 2008, 7:58:04 AM2/26/08
to
Brawo !

AK


Artur Bać

unread,
Feb 26, 2008, 8:01:36 AM2/26/08
to
Seweryn Habdank-Wojewódzki wrote:
> Raczej cenne jest to, że w C/C++ można mieć GC i można go nie mieć w
> zależności od potrzeb. I to jest ewidentna zaleta C/C++.
>
> W innych językach, aby pokombinować przy GC trzeba się nahakować -- patrz
> manuale o tunigu GC w Javie.

Np w C# mordowac jak ja z starym dobrym malloc /heapalloc
Btw kod na tak przydzielonej pameici jest lekko 2x szybszy od tego co
intensywnie kozysta z NET owego GC
Nie mowiac juz o problemach z fragmentacja ramu gdy uzywa sie GC i
duzej ilosci (setki tysiecy/ mln) alokacji i zwalnainia malych class.

Wtedy sie przydaje znajmosc C /algorytmow i mozna jechac z C# tak jakby
byl to C z mozliwoscia deklarowania metod. (uzywam wtedy tylko struct
ktory jest value type w C#)


//wycinek
public static unsafe class Heap
{
public enum HEAP_INFORMATION_CLASS {
HeapCompatibilityInformation
};

#if USE_KERNEL32
static HANDLE* ph = InitializeLFH();
static HANDLE* InitializeLFH()
{
uint HeapFragValue = 2;
HANDLE* heap = HeapCreate( (uint)dwFlags.CREATE_ENABLE_EXECUTE |
(uint)dwFlags.HEAP_GENERATE_EXCEPTIONS, 4 * 1024 * 1024, 0);

if(!HeapSetInformation(heap,HEAP_INFORMATION_CLASS.HeapCompatibilityInformation,
&HeapFragValue, sizeof(uint)))
throw new InvalidProgramException("Setting LowFragmentationHeap failed");
return heap;
}
#endif


public static void* Malloc(int type_size, int element_count)
#if USE_KERNEL32
void* result = HeapAlloc(ph, (int)dwFlags.HEAP_ZERO_MEMORY, type_size *
element_count);
#else
void* result = malloc(type_size * element_count);
#endif

return result;
}

[DllImport(KERNEL32)]
static extern void* HeapAlloc(HANDLE* hHeap, int flags, int size);

Seweryn Habdank-Wojewódzki

unread,
Feb 26, 2008, 8:44:56 AM2/26/08
to
Witam

Sebastian Nibisz wrote:

> Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to
> pieniądź.

O tak to ma sens, ale wszystko w ten sam sposób moge sprowadzić do
pieniędzy. Co więcej teorię przeciwną również.

> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż tak
> bardzo trzeba szanować.

A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
instalacji.



> GC nadaje się tylko i wyłacznie do zarządzania pamięcią RAM. Kto tego nie
> rozumie, nie lepiej z GC nie korzysta.

O tak! Święta prawda. Powiedz mi teraz ile koderów tak uważa, co więcej ile
koderów ma to w pamięci. Generalnie jest tak, że tylko ci "> intemediate" o
tym pamiętają, zeby np. plik zamknac, żeby zamknąc połaczenie do bazy, zeby
posprzatac rozproszone obiekty itd. A kodu tego typu powstaje dosc troche w
jezykach z GC. Po prostu ogólnie zakłada się nieskończoność zasobów i jak
system się nasyca, to winą zwala się na system -- dać mu trzeba więcej
węgla -- a nie na kichane "wycieki" w programie (GC zwalnia zasoby kiedy
chce).

Jedrzej Dudkiewicz

unread,
Feb 26, 2008, 8:55:46 AM2/26/08
to
Sebastian Nibisz wrote:
>>>> Oczywiście niezaprzeczalna zaletą shared poiner, jest możliwość
>>>> deterministycznego zwalniania zasobów, co w typowym systemie GC jest
>>>> niemożliwe do uzyskania.
>>>
>>> Mozna przebolec.
>>> Rachunek zalet do wad zdecydowanie na korzysc gc.
>>
>> To zależy od celu. Taka generalizacja jest bardziej wadliwa niż wady
>> smart
>> pointerów.
>
> Taka generalizacja z małymi wyjątakami, jest jak najbardziej prawidłowa.
> Poza systemami z bardzo ograniczonymi zasobami pamięciowymi, smart
> pointery ze zliczaniem referencji, średnio się nadają do zarządzania
> pamięcią RAM.

Tych systemów z ograniczonymi zasobami pamięciowymi jest chyba znacznie
więcej niż tych z "nieograniczonymi" (gdzie "nieograniczone to, załóżmy,
2GB).

JD

Sebastian Nibisz

unread,
Feb 26, 2008, 9:02:01 AM2/26/08
to
>> Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to
>> pieniądź.
>
> O tak to ma sens, ale wszystko w ten sam sposób moge sprowadzić do
> pieniędzy. Co więcej teorię przeciwną również.

Ale po co sobie utrudniac życie, dla frajdy?

>> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
>> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż tak
>> bardzo trzeba szanować.
>
> A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
> instalacji.

W ilościach nowych projektów tworzonych w języku C++. Od kilka lat,
procentowo ta ilość systematycznie spada.

>> GC nadaje się tylko i wyłacznie do zarządzania pamięcią RAM. Kto tego nie
>> rozumie, nie lepiej z GC nie korzysta.
>
> O tak! Święta prawda. Powiedz mi teraz ile koderów tak uważa, co więcej
> ile
> koderów ma to w pamięci. Generalnie jest tak, że tylko ci "> intemediate"
> o
> tym pamiętają, zeby np. plik zamknac, żeby zamknąc połaczenie do bazy,
> zeby
> posprzatac rozproszone obiekty itd. A kodu tego typu powstaje dosc troche
> w
> jezykach z GC. Po prostu ogólnie zakłada się nieskończoność zasobów i jak
> system się nasyca, to winą zwala się na system -- dać mu trzeba więcej
> węgla -- a nie na kichane "wycieki" w programie (GC zwalnia zasoby kiedy
> chce).

To że istnieją niekompetentni programiści, nie jest w żadnym stopniu winą
istnienia systemów GC.

Pozdrawiam.

- Bastek -

Sebastian Nibisz

unread,
Feb 26, 2008, 9:09:41 AM2/26/08
to
> Tych systemów z ograniczonymi zasobami pamięciowymi jest chyba znacznie
> więcej niż tych z "nieograniczonymi" (gdzie "nieograniczone to, załóżmy,
> 2GB).

Wszystko zależy od wymagań samej aplikacji. Dla niektórych, "nieograniczonym
zasobem", może być już 64MB pamięci.

Pozdrawiam.

- Bastek -

Jedrzej Dudkiewicz

unread,
Feb 26, 2008, 9:27:18 AM2/26/08
to

Wydaje mi się, że na maszynach, gdzie pamięci jest w okolicach małych GB
(czyli np. domowe pecety albo jakieś Pomniejsze Serwery (tm)), to tych
aplikacji jest znacząco więcej niż jedna. To wszystko się na siebie
nakłada. Pewnie, że jak otwierasz Eclipse i masz 2GB to to jest jak
splunąć, tylko że mało kto ma otwarte samo Eclipse.

JD

Sebastian Nibisz

unread,
Feb 26, 2008, 9:35:57 AM2/26/08
to

Zgadza się, ale to przecież nie jest tak, że jak mam aplikację w której
zasoby są zwalniane ręcznie, to mi wystarczy 10MB pamięci systemowej a jak
korzystam z systemu GC, to tej pamięci muszę mieć 10 razy wiecej. Wszystko
zależy od specyfiki danej aplikacji i od sposobu zarządzania pamięcią przez
system GC.

Nie potrzeba mi aplikacji wykorzystujących GC, aby zadusić system
wygórowanymi rządaniami.

Pozdrawiam.

- Bastek -

Jedrzej Dudkiewicz

unread,
Feb 26, 2008, 10:27:17 AM2/26/08
to
Sebastian Nibisz wrote:
>>>> Tych systemów z ograniczonymi zasobami pamięciowymi jest chyba
>>>> znacznie więcej niż tych z "nieograniczonymi" (gdzie "nieograniczone
>>>> to, załóżmy, 2GB).
>>>
>>> Wszystko zależy od wymagań samej aplikacji. Dla niektórych,
>>> "nieograniczonym zasobem", może być już 64MB pamięci.
>>
>> Wydaje mi się, że na maszynach, gdzie pamięci jest w okolicach małych
>> GB (czyli np. domowe pecety albo jakieś Pomniejsze Serwery (tm)), to
>> tych aplikacji jest znacząco więcej niż jedna. To wszystko się na
>> siebie nakłada. Pewnie, że jak otwierasz Eclipse i masz 2GB to to jest
>> jak splunąć, tylko że mało kto ma otwarte samo Eclipse.
>
> Zgadza się, ale to przecież nie jest tak, że jak mam aplikację w której
> zasoby są zwalniane ręcznie, to mi wystarczy 10MB pamięci systemowej a
> jak korzystam z systemu GC, to tej pamięci muszę mieć 10 razy wiecej.

Jasne. Ktoś tutaj jednak podawał statystyki kiedyś i wychodziło, że
średnio aplikacja z GC żre więcej - co jest w zasadzie oczywiste. Więc,
było nie było, łatwiej.

> Wszystko zależy od specyfiki danej aplikacji i od sposobu zarządzania
> pamięcią przez system GC.
> Nie potrzeba mi aplikacji wykorzystujących GC, aby zadusić system
> wygórowanymi rządaniami.

Zdecydowanie.

Tak w ogóle, to mi się idea GC bardziej niż bardzo podoba, zjeżyłem się
tylko z tego powodu, że z Twojej wypowiedzi można było wnioskować, że o
pamięć nie warto dbać, bo ma się jej ile się chce.

Przy czym rozumiem, że chodziło o to, że należy zasoby ściśle podzielić
na te, których przydziałem trzeba się bardzo przejmować i takie, których
przydziałem można zajmować się mniej i że w większości przypadków pamięć
należy do tej drugiej grupy.

JD

Sebastian Nibisz

unread,
Feb 26, 2008, 10:55:54 AM2/26/08
to
>> Zgadza się, ale to przecież nie jest tak, że jak mam aplikację w której
>> zasoby są zwalniane ręcznie, to mi wystarczy 10MB pamięci systemowej a
>> jak korzystam z systemu GC, to tej pamięci muszę mieć 10 razy wiecej.
>
> Jasne. Ktoś tutaj jednak podawał statystyki kiedyś i wychodziło, że
> średnio aplikacja z GC żre więcej - co jest w zasadzie oczywiste. Więc,
> było nie było, łatwiej.

Aplikacja korzystająca z GC zawsze będzie bardziej pamięciożerna, ale to jak
bardzo, zależy już od samego systemu GC.
Typowy system GC zwalnia pamięć w sytuacji, kiedy zaczyna jej brakować.
Nietrudno sobie wyobrazić, co się stanie w sytuacji, gdy odpalimy dwie
pamięciożerne aplikacje, korzystające z niezależnych od siebie systemów GC.

>> Wszystko zależy od specyfiki danej aplikacji i od sposobu zarządzania
>> pamięcią przez system GC.
> > Nie potrzeba mi aplikacji wykorzystujących GC, aby zadusić system
> > wygórowanymi rządaniami.
>
> Zdecydowanie.
>
> Tak w ogóle, to mi się idea GC bardziej niż bardzo podoba, zjeżyłem się
> tylko z tego powodu, że z Twojej wypowiedzi można było wnioskować, że o
> pamięć nie warto dbać, bo ma się jej ile się chce.
>
> Przy czym rozumiem, że chodziło o to, że należy zasoby ściśle podzielić na
> te, których przydziałem trzeba się bardzo przejmować i takie, których
> przydziałem można zajmować się mniej i że w większości przypadków pamięć
> należy do tej drugiej grupy.

To, że pamięć jest tania, nie znaczy, że jest za darmo i można ją
marnotrawić.
GC z biblioteki SGCL został tak zaprojektowany, że na bieżąco analizauje
stan osiągalnej pamięci w aplikacji. Pamięć zwalniana jest "na bieżąco",
niezależnie od tego czy aplikacja żąda przydzielania nowej.

Pozdrawiam.

- Bastek -

Seweryn Habdank-Wojewódzki

unread,
Feb 26, 2008, 2:05:43 PM2/26/08
to
Witam

Sebastian Nibisz wrote:

>>> Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to
>>> pieniądź.
>>
>> O tak to ma sens, ale wszystko w ten sam sposób moge sprowadzić do
>> pieniędzy. Co więcej teorię przeciwną również.
>
> Ale po co sobie utrudniac życie, dla frajdy?

Dla ustalenia uwagi. Nie mam nic przeciwko SGCL ani Śmieciuchowi, ani innemu
GC dla C++ i C.

Podkreślę moje stanowisko.

Zarówno Ty jak i Pan Karpierz oraz wszyscy lokalni Ajatollahowie GC :-)
znają i umieją pisać w C, C++ lub innych brzydkich językach !!!

Mając to w pamięci. Kiedy mówisz o zasobach w językach z GC używasz wzorca
projektowego "język C", czyli jezeli coś ma być napisane
alokując/zwalniając zasoby inne niż RAM mówisz: "Piszemy jak w C!".
To jest użycie wzorca projektowego "język C".

Teraz postaw się w sytuacji (która mnie dotknęła) wytłumacz to przeciętnemu
koderowi języka z GC (i tylko jednego języka, bo tacy jednojęzykowcy są
tanii).

Co mu powiesz? Wyłożysz mu C? Ile to bedzie kosztować? Szkolenie z podstaw C
też kosztuje. Ja chętnie szkolę, ale czy to jest tanie -- nie sądzę?
Jest tańsze niż wykłady firm consultingowych, ale nadal nie jest tanie.

>>> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
>>> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż
>>> tak bardzo trzeba szanować.
>>
>> A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
>> instalacji.
>
> W ilościach nowych projektów tworzonych w języku C++. Od kilka lat,
> procentowo ta ilość systematycznie spada.

Aha. No ja na to patrzę przez inny pryzmat.

Metryka używalności:

max ( liczba użytkowników, liczba instalacji )

Przykład: Amazon -- tak o sobie piszą:

Platform: Linux, Oracle, C++, Perl, Mason, Java, Jboss, Servlets

Przykład 2: Linux sam w sobie.

Przykład 3: Winsdows + M$ Office (+ .NET).

Ta metryka jest obiektywna dla starych programów również jak i dla nowych
rewelacyjnych języków dedykowanych np. VHDL, STL (dla PLC).
Jeśli patrzysz na komórki, to mówisz Java, ale zapominasz, że poniżej Javy
jest C, który napędza to cudo. Co więcej to właśnie w C napisane są
kluczowe (ze względu na wydajność) kawałki kodu.

Kolejna metryka:

Łańcuch utrzymywalności i rozwijalności: Ile procentowo linii kodu
z danej aplikacji (biblioteki) w danym języku jest używane po 3, 7
i 15 latach funkcjonowania.

Podkreślam w danej aplikacji i w danym języku.

Około 7 lat temu napisałem pierwsze linijki kodu "dla przemysłu" i patrzę z
tego punktu widzenia.
Na SF powstaje całe dzikie mnóstwo projektów. I co z tego jeśli one równie
szybko giną co powstały.
Co więcej, bardzo ciekawy jest dla mnie Python. Język, który sam dla siebie
nie istnieje, zawsze ciągnie za sobą kogoś z grupy "ciężki kaliber", o tym
należy pamiętać -- uwaga: CPython jest wiodąca produkcją, a zatem język C
dostaje bonusowe punkty chociaż niby nikt go nie lubi i co więcej domyślnie
nie ma w nim GC, a Python ma GC. Zreszta guru Pythona zazwyczaj są guru C.

> To że istnieją niekompetentni programiści, nie jest w żadnym stopniu winą
> istnienia systemów GC.

NIE! Nie jest winą GC.

GC dla ludzi znających C, C++ i języki bez GC jest istotnie obniżeniem
kosztów w sytuacji kiedy tego trzeba. Miałem osobiście przypadki kiedy
powodowało wzrost kosztów.

Dla ludzi, nie mających pojęcia o tym, może powodować drastyczny wzrost
kosztów w projektach korzystających z zasobów innych niż RAM na skutek nie
przewidzianych katastrof.

Podsumowując -- wiem, że są sytuacje kiedy GC może być wygodne, ale GC to
jest bardzo rozleniwiająca brzytwa -- generalnie goli elegancko, ale słabo
obeznani potrafią poderżnąc sobie i innym gardło. A nalezy pamiętać, że
określony kod jest uzywany zazwyczaj w zakresie 10 - 1000 razy większym
podwzględem zasobów niż przewidziane przez koderów obciążenie.

Sektor van Skijlen

unread,
Feb 26, 2008, 3:01:17 PM2/26/08
to
Dnia Tue, 26 Feb 2008 15:02:01 +0100, Sebastian Nibisz skrobie:

> >> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
> >> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż tak
> >> bardzo trzeba szanować.
> >
> > A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
> > instalacji.

> W ilościach nowych projektów tworzonych w języku C++. Od kilka lat,
> procentowo ta ilość systematycznie spada.

A jakimi statystykami się w tym podpierasz?

Owszem, nie przeczę, nawet na własne oczy ostatnio obserwuję wycofywanie się z
C++ i przechodzenie na Javę, tylko jeden drobny szczegół - aplikacje przestają
być standalowe, a zaczynają być webowe.

Powtarzam jeszcze raz - istnieją statystyki, w których PHP jest na pierwszym
miejscu, w wielu innych PHP stoi bardzo wysoko. Czy świadczy to o tym, że:

- PHP jest najpopularniejszym (lub prawie najpopularniejszym) językiem
programowania
- Aplikacje webowe są najczęściej podejmowanymi projektami oprogramowania

?

Ile znasz firm produkujących oprogramowanie dla urządzeń, komputerów
pokładowych samochodów, samolotów, infrastruktury telekomunikacyjnej, centrów
obliczeniowych, produkcji baz danych itd., które CHWALĄ SIĘ jakiego języka
programowania używają?


--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethouris(O)gmail.com>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"

Piotr Wyderski

unread,
Feb 26, 2008, 6:30:00 PM2/26/08
to
Sebastian Nibisz wrote:

> Shared poiner jest niestety wielce niedoskonałym sposobem odśmiecania,
> gdyż działa w oparciu o mechanizm zliczania referencji i ma cztery
> podstawowe wady:
>
> 1. Nie zwalnia struktur cyklicznych.

Niezaprzeczalnie.

> 2. Operacje na wskaźnikach są kosztowne (wymaga operacji atomowych).

I tu -- niespodzianka -- nie wymagają. Sam się zdziwiłem, gdy
wpadłem na pomysł rozwiązania, ale ono było złudnie proste.
Zaimplementowałem pierwotny pomysł w 2 dni, a potem... przez
7 debugowałem, zanim zrozumiałem, że to nie w kodzie jest
problem i poprawiłem algorytm. Przedstawiłem tu kiedyś szkic
pomysłu. Ale on jest błędny (choć wtedy jeszcze tego nie
wiedziałem); ot, super rzecz dla szpiegów przemysłowych
-- coś, co wygląda na poprawne, ale wybuchnie w rękach... :-)

Dlatego ostatnimi czasy wróciłem do rozwiązań ze zliczaniem
referencji (intruzywnym), po tuningu są niewiele wolniejsze niż
zwykły wskaźnik.

> 3. Zwalnianie większych struktur, może doprowadzić do przepełnienia ramki
> stosu.

To się da rozwiązać, choć nie zawsze jest to konieczne. Naiwna
implementacja mark&sweep cierpi na dokładnie ten sam problem.

> 4. Zwalnianie większych struktur, może na dłuższy okres wstrzymać
> działanie aplikacji (wymaga operacji atomowych).

Ja deterministyczny punkt destrukcji uznaję za zaletę.

> Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej
> implementacji systemu GC w jakimkolwiek języku czy środowisku.

Pogratulować. :-)

Pozdrawiam
Piotr Wyderski

Sebastian Nibisz

unread,
Feb 27, 2008, 4:37:56 AM2/27/08
to
Nie było i nie jest moim zamysłem, prowadzenie wojny dziejowej z językiem
C++.
Faktem jest, że restrykcje dotyczące zużycia przez aplikacje pamięci, są
dzisiaj znacznie mniejsze niż kiedyś.
Faktem jest, że język C++ się praktycznie nie rozwija i że jeżeli taki stan
się utrzyma, będzie wiódł prym lidera tylko do czasu.
Faktem jest, że istnieją dziedziny w których, podobnie jak obecnie język C,
język C++ długo nie będzie zagrożony.

Pozdrawiam.

- Bastek -

Sebastian Nibisz

unread,
Feb 27, 2008, 6:02:00 AM2/27/08
to
>> 2. Operacje na wskaźnikach są kosztowne (wymaga operacji atomowych).
>
> I tu -- niespodzianka -- nie wymagają. Sam się zdziwiłem, gdy
> wpadłem na pomysł rozwiązania, ale ono było złudnie proste.
> Zaimplementowałem pierwotny pomysł w 2 dni, a potem... przez
> 7 debugowałem, zanim zrozumiałem, że to nie w kodzie jest
> problem i poprawiłem algorytm. Przedstawiłem tu kiedyś szkic
> pomysłu. Ale on jest błędny (choć wtedy jeszcze tego nie
> wiedziałem); ot, super rzecz dla szpiegów przemysłowych
> -- coś, co wygląda na poprawne, ale wybuchnie w rękach... :-)
>
> Dlatego ostatnimi czasy wróciłem do rozwiązań ze zliczaniem
> referencji (intruzywnym), po tuningu są niewiele wolniejsze niż
> zwykły wskaźnik.

Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma sie
pewność, że manipulacja wskaźnikiem odbywa się w jednym wątku aplikacji.

>> 3. Zwalnianie większych struktur, może doprowadzić do przepełnienia ramki
>> stosu.
>
> To się da rozwiązać, choć nie zawsze jest to konieczne. Naiwna
> implementacja mark&sweep cierpi na dokładnie ten sam problem.

Zawsze można to jakoś rozwiązać. Można się jednak nieźle ździwić, gdy niby
prawidłowy fragment kodu wysypuje nam aplikację.

>> 4. Zwalnianie większych struktur, może na dłuższy okres wstrzymać
>> działanie aplikacji (wymaga operacji atomowych).
>
> Ja deterministyczny punkt destrukcji uznaję za zaletę.

Trudno uznać za zaletę stuację w której aplikacja zatrzymuje się na dwie
sekundy tylko po to, aby zwolnić zajmowana przez siebie pamięć.

>> Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej
>> implementacji systemu GC w jakimkolwiek języku czy środowisku.
>
> Pogratulować. :-)

Dzięki, choć niestety rozwiązanie nie jest pozbawione wad.

Pozdrawiam.

- Bastek -

Sektor van Skijlen

unread,
Feb 27, 2008, 6:06:49 AM2/27/08
to
Dnia Wed, 27 Feb 2008 10:37:56 +0100, Sebastian Nibisz skrobie:

> Nie było i nie jest moim zamysłem, prowadzenie wojny dziejowej z językiem
> C++.
> Faktem jest, że restrykcje dotyczące zużycia przez aplikacje pamięci, są
> dzisiaj znacznie mniejsze niż kiedyś.

To prawda, ale dotyczy to tylko części rynku oprogramowania. Dotyczy aplikacji
standalowych oraz aplikacji webowych, nie dotyczy jednak aplikacji na
systemach wbudowanych.

> Faktem jest, że język C++ się praktycznie nie rozwija i że jeżeli taki stan
> się utrzyma, będzie wiódł prym lidera tylko do czasu.

Już go i tak nie wiedzie. Niestety jak na razie w wielu zastosowaniach jak na
razie jedynymi sensownymi alternatywami dla tego języka wydają się być D i C#.
Zastępowanie C++ jednak tym językom niespecjalnie idzie, a ostatnie dodatki do
C# umacniają go akurat nie w tych obszarach, w których C++ rządzi.

> Faktem jest, że istnieją dziedziny w których, podobnie jak obecnie język C,
> język C++ długo nie będzie zagrożony.

I o tym właśnie mówię - a co gorsza, są to prężnie rozwijające się gałęzie
produkcji oprogramowania, w przeciwieństwie do aplikacji standalowych.

Marcin ‘Qrczak’ Kowalczyk

unread,
Feb 27, 2008, 6:35:54 AM2/27/08
to
Dnia 27-02-2008, Śr o godzinie 12:02 +0100, Sebastian Nibisz pisze:

> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma sie
> pewność, że manipulacja wskaźnikiem odbywa się w jednym wątku aplikacji.

Pewnie można w każdym obiekcie pamiętać, który wątek ostatnio dotykał
jego licznika odwołań. Operacje atomowe będą potrzebne tylko kiedy
obiekt jest przekazywany między wątkami, co powinno być rzadkie.

Wystarczy, jeśli operacji atomowych unika się w typowym przypadku.
Nie trzeba unikać ich bezwzględnie.

--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/

Piotr Wyderski

unread,
Feb 27, 2008, 7:09:32 AM2/27/08
to
Sebastian Nibisz wrote:

> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma sie
> pewność, że manipulacja wskaźnikiem odbywa się w jednym wątku aplikacji.

Ano właśnie nie... :-)
Są potrzebne tylko wtedy, gdy wątek pierwszy raz spotyka się z danym
obiektem.
Wówczas atomowo podnosi licznik referencji (i od tego momentu ma pewność, że
nikt mu tego obiektu nie zabije) i może sobie zacząć lokalne zliczanie
swoich referencji.

>>> 3. Zwalnianie większych struktur, może doprowadzić do przepełnienia
>>> ramki stosu.
>>
>> To się da rozwiązać, choć nie zawsze jest to konieczne. Naiwna
>> implementacja mark&sweep cierpi na dokładnie ten sam problem.
>
> Zawsze można to jakoś rozwiązać. Można się jednak nieźle ździwić, gdy niby
> prawidłowy fragment kodu wysypuje nam aplikację.

No tak, tylko Ty to podawałeś jako wadę RC, choć dotyczy to też M&S
z dokładnie tego samego powodu. I w ten sam sposób się to rozwiązuje.

> Trudno uznać za zaletę stuację w której aplikacja zatrzymuje się na dwie
> sekundy tylko po to, aby zwolnić zajmowana przez siebie pamięć.

Przesadzasz... poza tym na to też są sposoby... RC jest bardzo często
wykorzystywany w systemach czasu rzeczywistego, więc chyba nie ma
lepszego dowodu na istnienie rozwiązania.

Pozdrawiam
Piotr Wyderski

Piotr Wyderski

unread,
Feb 27, 2008, 7:11:41 AM2/27/08
to
Marcin 'Qrczak' Kowalczyk wrote:

> Pewnie można w każdym obiekcie pamiętać, który wątek ostatnio dotykał
> jego licznika odwołań. Operacje atomowe będą potrzebne tylko kiedy
> obiekt jest przekazywany między wątkami, co powinno być rzadkie.

Owszem, to jedno z możliwych rozwiązań, choć da się znacznie lepiej.

> Wystarczy, jeśli operacji atomowych unika się w typowym przypadku.
> Nie trzeba unikać ich bezwzględnie.

Własnie tak. :-) To dokładnie to samo, co z pamięcią cache. Można
łatwo pokazac przypadek, że żadne cache nie pomoże, a jednak... jakoś
się producenci procesorów prześcigają w zwiększaniu jego rozmiaru.
Lokalność referencji to znacznie ogólniejsze zjawisko...

Pozdrawiam
Piotr Wyderski

Sebastian Nibisz

unread,
Feb 27, 2008, 7:19:56 AM2/27/08
to
>> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma
>> sie
>> pewność, że manipulacja wskaźnikiem odbywa się w jednym wątku aplikacji.
>
>Pewnie można w każdym obiekcie pamiętać, który wątek ostatnio dotykał
>jego licznika odwołań. Operacje atomowe będą potrzebne tylko kiedy
>obiekt jest przekazywany między wątkami, co powinno być rzadkie.

Niby tak, ale wyjdzie na to, że zapis i odczyt pola przechowującego
identyfikator wątku i tak w jakiś sposób musiałby być synchronizowany.
Zastanawiałem się kiedyś nad podobnym rozwiązaniem i doszedłem do wniosku,
że raczej nie da sie tego w żaden sensowny sposób zaimplementować.

>Wystarczy, jeśli operacji atomowych unika się w typowym przypadku.
>Nie trzeba unikać ich bezwzględnie.

Zgadza się, potrzeba stosowania synchronizacji, nie jest nagminna. Można
sobie wyobrazić taki shared_ptr dostępny w dwóch wersjach, synchronizowanej
oraz niesynchronizowanej i stosować odpowiednią wersję w ramach potrzeb.
Takie podejście może jednak rodzić problemy w późniejszym utrzymywaniu kodu.

Pozdrawiam.

- Bastek -

Johnny

unread,
Feb 27, 2008, 7:32:39 AM2/27/08
to
> Na reszte Pana wypocin szkoda zwyczajnie klawiatury !

Niezależnie od tego kto ma słuszność, daruj, proszę sobie tego typu
wstawki. Nie po to człowiek wchodzi do sieci żeby mieć powtórkę dyskusji
polityków z TVN24.

To jest grupa dyskusyjna, ścierają się tu różne opinie (w tym błędne).
Jeśli ktoś z nas ma wyrobić sobie *prawidłowe* zdanie na podstawie
dyskusji to musi się oprzeć na argumentach obu stron. Pisanie o
wypocinach argumentem nie jest. Jest to tak oczywiste, że wstyd iż
trzeba o tym przypominać.


--
Pozdrawiam
Johnny

"Zauważyłem że ci wszyscy, którzy opowiadają się za aborcją, zdążyli się
urodzić". R. Reagan

Sebastian Nibisz

unread,
Feb 27, 2008, 7:40:54 AM2/27/08
to
>> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma
>> sie pewność, że manipulacja wskaźnikiem odbywa się w jednym wątku
>> aplikacji.
>
> Ano właśnie nie... :-)
> Są potrzebne tylko wtedy, gdy wątek pierwszy raz spotyka się z danym
> obiektem.
> Wówczas atomowo podnosi licznik referencji (i od tego momentu ma pewność,
> że
> nikt mu tego obiektu nie zabije) i może sobie zacząć lokalne zliczanie
> swoich referencji.

A w jaki sposób wątek sprawdza, czy pierwszy raz spotkał sie z danym
obiektem, aby ewentualnie atomowo podnieść licznik referencji?

>>>> 3. Zwalnianie większych struktur, może doprowadzić do przepełnienia
>>>> ramki stosu.
>>>
>>> To się da rozwiązać, choć nie zawsze jest to konieczne. Naiwna
>>> implementacja mark&sweep cierpi na dokładnie ten sam problem.
>>
>> Zawsze można to jakoś rozwiązać. Można się jednak nieźle ździwić, gdy
>> niby prawidłowy fragment kodu wysypuje nam aplikację.
>
> No tak, tylko Ty to podawałeś jako wadę RC, choć dotyczy to też M&S
> z dokładnie tego samego powodu. I w ten sam sposób się to rozwiązuje.

Nie można stawiać tych dwóch przypadków na jednym poziomie, gdyż shared_ptr
wymaga rozwiązania problemu na poziomie aplikacji a algorytm "mark & sweep"
na poziomienie implementacji systemu GC.

>> Trudno uznać za zaletę stuację w której aplikacja zatrzymuje się na dwie
>> sekundy tylko po to, aby zwolnić zajmowana przez siebie pamięć.
>
> Przesadzasz... poza tym na to też są sposoby... RC jest bardzo często
> wykorzystywany w systemach czasu rzeczywistego, więc chyba nie ma
> lepszego dowodu na istnienie rozwiązania.

RC nie jest jedyna techniką odśmiecania stosowaną w systemach czasu
rzeczywistygo, co dobitnie świadczy o tym, że jego wady mogą przeszkadzać.

Pozdrawiam.

- Bastek -

Piotr Wyderski

unread,
Feb 27, 2008, 7:48:35 AM2/27/08
to

Sebastian Nibisz wrote:

> A w jaki sposób wątek sprawdza, czy pierwszy raz spotkał sie z danym
> obiektem, aby ewentualnie atomowo podnieść licznik referencji?

Zapamiętuje sobie w TLSie N ostatnio używanych obiektów.
Potem tylko proste hashowanie i masz, co potrzeba.

> Nie można stawiać tych dwóch przypadków na jednym poziomie, gdyż
> shared_ptr wymaga rozwiązania problemu na poziomie aplikacji a algorytm
> "mark & sweep" na poziomienie implementacji systemu GC.

To się da rozwiązać poprzez modyfikację implementacji shared_ptr. Jest taka,
jaka jest, więc i problem w naturalny sposób występuje, ale nie musi taka
być.

> RC nie jest jedyna techniką odśmiecania stosowaną w systemach czasu
> rzeczywistygo, co dobitnie świadczy o tym, że jego wady mogą przeszkadzać.

Oczywiście, że ta metoda ma wiele wad. Ale w RT chyba dominuje i wcale
mnie to nie dziwi. Lubię deterministyczne programy... :-)

Pozdrawiam
Piotr Wyderski

Sebastian Nibisz

unread,
Feb 27, 2008, 8:00:28 AM2/27/08
to
> Dla ustalenia uwagi. Nie mam nic przeciwko SGCL ani Śmieciuchowi, ani
> innemu
> GC dla C++ i C.
>
> Podkreślę moje stanowisko.

Ok, ale nawet gdybyś był przeciwko, to masz do tego prawo i z pewnością
pretensji bym o to do Ciebie nie miał.

> Mając to w pamięci. Kiedy mówisz o zasobach w językach z GC używasz wzorca
> projektowego "język C", czyli jezeli coś ma być napisane
> alokując/zwalniając zasoby inne niż RAM mówisz: "Piszemy jak w C!".
> To jest użycie wzorca projektowego "język C".
>
> Teraz postaw się w sytuacji (która mnie dotknęła) wytłumacz to
> przeciętnemu
> koderowi języka z GC (i tylko jednego języka, bo tacy jednojęzykowcy są
> tanii).
>
> Co mu powiesz? Wyłożysz mu C? Ile to bedzie kosztować? Szkolenie z podstaw
> C
> też kosztuje. Ja chętnie szkolę, ale czy to jest tanie -- nie sądzę?
> Jest tańsze niż wykłady firm consultingowych, ale nadal nie jest tanie.

Ale to świadczy jedynie o tym, że koder jest niedouczony. Nawet ucząc się
tylko języka z GC, koder powinien sie dowiedzieć co to jest GC i do czego
tego wykorzystywać nie można.

>> To że istnieją niekompetentni programiści, nie jest w żadnym stopniu winą
>> istnienia systemów GC.
>
> NIE! Nie jest winą GC.
>
> GC dla ludzi znających C, C++ i języki bez GC jest istotnie obniżeniem
> kosztów w sytuacji kiedy tego trzeba. Miałem osobiście przypadki kiedy
> powodowało wzrost kosztów.
>
> Dla ludzi, nie mających pojęcia o tym, może powodować drastyczny wzrost
> kosztów w projektach korzystających z zasobów innych niż RAM na skutek nie
> przewidzianych katastrof.
>
> Podsumowując -- wiem, że są sytuacje kiedy GC może być wygodne, ale GC to
> jest bardzo rozleniwiająca brzytwa -- generalnie goli elegancko, ale słabo
> obeznani potrafią poderżnąc sobie i innym gardło. A nalezy pamiętać, że
> określony kod jest uzywany zazwyczaj w zakresie 10 - 1000 razy większym
> podwzględem zasobów niż przewidziane przez koderów obciążenie.

j/w

Pozdrawiam.

- Bastek -

Sebastian Nibisz

unread,
Feb 27, 2008, 8:39:29 AM2/27/08
to
>> Faktem jest, że restrykcje dotyczące zużycia przez aplikacje pamięci, są
>> dzisiaj znacznie mniejsze niż kiedyś.
>
> To prawda, ale dotyczy to tylko części rynku oprogramowania. Dotyczy
> aplikacji
> standalowych oraz aplikacji webowych, nie dotyczy jednak aplikacji na
> systemach wbudowanych.

Z tego co zauważyłem, to i w niektórych systemach wbudowanych znika powoli
problem z ilościa dostępnej pamięci.

>> Faktem jest, że język C++ się praktycznie nie rozwija i że jeżeli taki
>> stan
>> się utrzyma, będzie wiódł prym lidera tylko do czasu.
>
> Już go i tak nie wiedzie. Niestety jak na razie w wielu zastosowaniach jak
> na
> razie jedynymi sensownymi alternatywami dla tego języka wydają się być D i
> C#.
> Zastępowanie C++ jednak tym językom niespecjalnie idzie, a ostatnie
> dodatki do
> C# umacniają go akurat nie w tych obszarach, w których C++ rządzi.

Język D nie jest na chwilę obecną zbyt atrakcyjny, gdyż nie posiada wsparcia
w postaci ciekawych bibliotek.
Język C# wraz z jego bibliotekami byłby silnym rywalem C++, gdyby nie był
tak uwiązany do jednej platformy systemowej. Na chwilę obecną,
(nie)nieprzenośność aplikacji napisanych w tym języku, jest jednym z
głównych powodów niższej jego popularności.

>> Faktem jest, że istnieją dziedziny w których, podobnie jak obecnie język
>> C,
>> język C++ długo nie będzie zagrożony.
>
> I o tym właśnie mówię - a co gorsza, są to prężnie rozwijające się gałęzie
> produkcji oprogramowania, w przeciwieństwie do aplikacji standalowych.

Tak, ale tutaj niewiele sie w tej materii zmieni. Znam firmy z gałęzi
przemysłu energetycznego, które do dzisiaj rozwijają oraz sprzedają
programy, napisane w zamierzchłych czasach dla DOS.

Pozdrawiam.

- Bastek -

Artur Bać

unread,
Feb 27, 2008, 9:30:37 AM2/27/08
to
Sebastian Nibisz wrote:
>> Co mu powiesz? Wyłożysz mu C? Ile to bedzie kosztować? Szkolenie z
>> podstaw C
>> też kosztuje. Ja chętnie szkolę, ale czy to jest tanie -- nie sądzę?
>> Jest tańsze niż wykłady firm consultingowych, ale nadal nie jest tanie.
>
> Ale to świadczy jedynie o tym, że koder jest niedouczony. Nawet ucząc
> się tylko języka z GC, koder powinien sie dowiedzieć co to jest GC i do
> czego tego wykorzystywać nie można.

Ile % koderów piszacych wylacznie w PHP, C#, Java ma o tym pojecie ?
Sadze ze mniej niz 1%.

Ostatnio prowadzilem dyskuje tj tlumaczylem koledze ktory od lat pisze
apliakcje webowe w PHP i jest dobry w tym co robi, na czym polegaja
roznice przekazania paramteru przez referencje const referencje wskaznik
przez wartosc.

Sedno w tym ze wiekszosc nie ma o tym pojecia a takie slowa jak stos czy
sterta to szyszeli ze sa.

Ich niedouczenie wynika wlasnie z tego faktu iz oni nie musza tego
wiedziec aby napisac program, bo robi to za nich automat.

Czlowiek ma taka nature ze jak dostanie zupe w proszku to nie bedzie
wnikac jak to sie dzieje ze ona tam sie znalazla tylko podswiadomie
bedzie chcial sie ograniczyc do poznania wiedzy jak jak przyzadzic aby
moc ja zjesc.

--

Artur

Maciej Sobczak

unread,
Feb 27, 2008, 9:42:29 AM2/27/08
to
On 27 Lut, 14:39, "Sebastian Nibisz" <EB...@poczta.onet.pl> wrote:

> >> Faktem jest, że restrykcje dotyczące zużycia przez aplikacje pamięci, są
> >> dzisiaj znacznie mniejsze niż kiedyś.
>
> > To prawda, ale dotyczy to tylko części rynku oprogramowania. Dotyczy
> > aplikacji
> > standalowych oraz aplikacji webowych, nie dotyczy jednak aplikacji na
> > systemach wbudowanych.
>
> Z tego co zauważyłem, to i w niektórych systemach wbudowanych znika powoli
> problem z ilościa dostępnej pamięci.

Nie rozumiem tego powyżej.
Co to znaczy, że gdzieś znika problem z ilością pamięci? Nigdzie nie
znika. Kupuje się większy hardware po to, żeby na nim puszczać większy
software. Problemu pamięci to nie rozwiązuje, jedynie pozwala dalej
ślizgać się po krawędzi. Ja problemy z pamięcią widzę zarowno na
płytach z 64MB jak i z <put-your-favorite-number>GB, bo po prostu
chodzą na nich różne systemy, które mają różne wymagania. Tak samo nie
ma sensu mówić, że autobusy rozwiązują problem samochodów osobowych z
ilością miejsc dla pasażerów. Kto stał w tłoku w szczycie zrozumie.
Inaczej: dla każdej ilości pamięci istnieją programy, które się w niej
nie mieszczą. Problem nigdzie nie "znika". Co więcej, większe programy
są pisane również po to, żeby wykorzystać okazje stwarzane przez
większy hardware. Kręcimy się tak od kilku dekad - każdego roku ktoś z
radością ogłasza, że problem pamięci lub CPU lub dysków itd. "znika",
bo oto np. firma X wyprodukowała dysk twardy o zawrotnej pojemności
80MB (megabajtów), i teraz ludzie w ekstazie nie mają pomysłu, co tam
trzymać. Całą walizkę dyskietek 5.25" można tam zmieścić. Łał.

Bilu też kiedyś myślał, że 640kB każdemy wystarczy - a dzisiaj Visty
poniżej 2GB nie ma po co nawet uruchamiać.

Pytam się więc - co to znaczy, że problem z pamięcią znika?

> >> Faktem jest, że język C++ się praktycznie nie rozwija

Język C++ rozwija się na dwóch płaszczyznach, z dwoma różnymi
prędkościami.
Jedna płaszczyzna to definicja języka, czyli standard - tempo rozwoju
to jedna iteracja na dekadę. Czy to wolno? Moim zdaniem akurat -
przemysł ledwo nadąża z wymianą kompilatorów w tym tempie. Hint:
przemysł to nie jest koleś z laptopem i Ubuntu aktualizowanym z
automatu.
Druga płaszczyzna to biblioteki i narzędzia orbitujące (np. generatory
kodu). To się rozwija dużo szybciej i spokojnie pozwala na
przedłużenie życia C++ w dowolnym obszarze. Hint: nie potrzeba było
zmieniać standardu, żeby pojawił się przykładowy Boost.

> >> i że jeżeli taki
> >> stan
> >> się utrzyma, będzie wiódł prym lidera tylko do czasu.

C++ nie wiedzie prymu lidera, bo nie musi. To jest język, który
świetnie się sprawdza w wymagających zastosowaniach i nie musi być na
topie popularności we wszelkich innych.

Wracając do GC - sam GC nie jest problemem. Problemem jest sytuacja, w
której twórca języka po wrzuceniu do niego GC otrzepuje ręce i
oznajmia, że wszystkie problemy rozwiązał. Efekty takiej
amatorszczyzny widać w Javie, gdzie np. w tutorialu dla początkujących
co chwila jest wołami przypominane, jakie to ważne, żeby zawsze
zamykać strumienie i inne takie. I to jeszcze w odpowiedniej
kolejności. W XXI wieku to jest po prostu *żenujące* (chociaż
początkujący czytelnicy akurat tego nie zauważą), niezależnie od
dostępnych gigabajtów.
To jest też dowód na to, że w Javie GC więcej problemów pozostawił,
niż rozwiązał.

Dodanie GC do C++ może przedłużyć mu życie w wielu obszarach. A
ponieważ wiadomo, że tak się właśnie stanie, to nie ma po co ogłaszać
zgonu.
Co ciekawe, dodanie GC do C++ jest dużo łatwiejsze, niż dodanie
sensownego systemu zarządzania czasem życia obiektów w Javie. Nie
podejmuję się prorokować, jak będą wyglądały rankingi języków za ~5
lat - ale wiem, że będą ciekawe.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Sebastian Nibisz

unread,
Feb 27, 2008, 10:59:38 AM2/27/08
to
>> Z tego co zauważyłem, to i w niektórych systemach wbudowanych znika
>> powoli
>> problem z ilościa dostępnej pamięci.
>
> Nie rozumiem tego powyżej.
> Co to znaczy, że gdzieś znika problem z ilością pamięci? Nigdzie nie
> znika. Kupuje się większy hardware po to, żeby na nim puszczać większy
> software. Problemu pamięci to nie rozwiązuje, jedynie pozwala dalej
> ślizgać się po krawędzi. Ja problemy z pamięcią widzę zarowno na
> płytach z 64MB jak i z <put-your-favorite-number>GB, bo po prostu
> chodzą na nich różne systemy, które mają różne wymagania. Tak samo nie
> ma sensu mówić, że autobusy rozwiązują problem samochodów osobowych z
> ilością miejsc dla pasażerów. Kto stał w tłoku w szczycie zrozumie.
> Inaczej: dla każdej ilości pamięci istnieją programy, które się w niej
> nie mieszczą. Problem nigdzie nie "znika". Co więcej, większe programy
> są pisane również po to, żeby wykorzystać okazje stwarzane przez
> większy hardware. Kręcimy się tak od kilku dekad - każdego roku ktoś z
> radością ogłasza, że problem pamięci lub CPU lub dysków itd. "znika",
> bo oto np. firma X wyprodukowała dysk twardy o zawrotnej pojemności
> 80MB (megabajtów), i teraz ludzie w ekstazie nie mają pomysłu, co tam
> trzymać. Całą walizkę dyskietek 5.25" można tam zmieścić. Łał.
>
> Bilu też kiedyś myślał, że 640kB każdemy wystarczy - a dzisiaj Visty
> poniżej 2GB nie ma po co nawet uruchamiać.
>
> Pytam się więc - co to znaczy, że problem z pamięcią znika?

W systemach wbudowanych nie wykorzystuje sie pamięci tak ja na komputerach
domowych. Tam nie ma tak, że jak mamy 10 razy więcej pamięci, to sobie
wrzucimy wiecej obrazków, dodamy muzyczkę, jakieś dynamiczne menu i pamięci
znów mamy mało.

Samego kodu nie da się mnożyć na dużą skalę w nieskończoność. Z pewnością
jest coraz mniej sytuacji w której ze względu na małą ilość dostępnej
pamięci, nie można zaimplementować jakieś funkcjonalności w systemie
wbudowanym. Sprzęt niewielkim kosztem można rozbudować, co jeszcze
kilkanaście lat temu często nie było możliwe.

>> Faktem jest, że język C++ się praktycznie nie rozwija
>
> Język C++ rozwija się na dwóch płaszczyznach, z dwoma różnymi
> prędkościami.
> Jedna płaszczyzna to definicja języka, czyli standard - tempo rozwoju
> to jedna iteracja na dekadę. Czy to wolno? Moim zdaniem akurat -
> przemysł ledwo nadąża z wymianą kompilatorów w tym tempie. Hint:
> przemysł to nie jest koleś z laptopem i Ubuntu aktualizowanym z
> automatu.

Przy założeniu, że język C++ jest dedykowany jedynie dla przemysłu, to można
sie zgodzić z tym, że tempo jego rozoju jest zadowalające.
Niestety takiego założenia przyjąć nie można i mogą rodzić sie słuszne obawy
o to, że zanim nowy standard zostanie "zaklepany" no i oczywiście wdrożony,
języka C++ na desktopach mało kto już będzie używał.

> Druga płaszczyzna to biblioteki i narzędzia orbitujące (np. generatory
> kodu). To się rozwija dużo szybciej i spokojnie pozwala na
> przedłużenie życia C++ w dowolnym obszarze. Hint: nie potrzeba było
> zmieniać standardu, żeby pojawił się przykładowy Boost.

Zgadza się, trzeba jednak wziąć pod uwagę, że możliwości bibliotek są
ograniczane przez możliwości samego języka.

>> i że jeżeli taki
>> stan
>> się utrzyma, będzie wiódł prym lidera tylko do czasu.
>
> C++ nie wiedzie prymu lidera, bo nie musi. To jest język, który
> świetnie się sprawdza w wymagających zastosowaniach i nie musi być na
> topie popularności we wszelkich innych.

W swojej kategorii, język C++ wiedzie prym lidera.

> Wracając do GC - sam GC nie jest problemem. Problemem jest sytuacja, w
> której twórca języka po wrzuceniu do niego GC otrzepuje ręce i
> oznajmia, że wszystkie problemy rozwiązał. Efekty takiej
> amatorszczyzny widać w Javie, gdzie np. w tutorialu dla początkujących
> co chwila jest wołami przypominane, jakie to ważne, żeby zawsze
> zamykać strumienie i inne takie. I to jeszcze w odpowiedniej
> kolejności. W XXI wieku to jest po prostu *żenujące* (chociaż
> początkujący czytelnicy akurat tego nie zauważą), niezależnie od
> dostępnych gigabajtów.
> To jest też dowód na to, że w Javie GC więcej problemów pozostawił,
> niż rozwiązał.

Jak najbardziej sie zgadzam. Nie wyobrażam sobie języka C++ z innym, niż
jedynie opcjonalnym system GC.

> Dodanie GC do C++ może przedłużyć mu życie w wielu obszarach. A
> ponieważ wiadomo, że tak się właśnie stanie, to nie ma po co ogłaszać
> zgonu.

Nikt nie ogłasza zgonu języka C++, ale też nikomu nie chce sie czekać
kolejnych 10 lat na jego nowszą wersję.

> Co ciekawe, dodanie GC do C++ jest dużo łatwiejsze, niż dodanie
> sensownego systemu zarządzania czasem życia obiektów w Javie. Nie
> podejmuję się prorokować, jak będą wyglądały rankingi języków za ~5
> lat - ale wiem, że będą ciekawe.

Pożyjemy, zobaczymy.

Pozdrawiam.

- Bastek -

Michał 'Khorne' Rzechonek

unread,
Feb 27, 2008, 11:03:14 AM2/27/08
to
On 27 Lut, 13:09, "Piotr Wyderski" <wyder...@REMOVEii.uni.wroc.pl>
wrote:

> Są potrzebne tylko wtedy, gdy wątek pierwszy raz spotyka się z danym
> obiektem.
> Wówczas atomowo podnosi licznik referencji (i od tego momentu ma pewność, że
> nikt mu tego obiektu nie zabije) i może sobie zacząć lokalne zliczanie
> swoich referencji.

Ach, tak proste, że aż genialne. Bardzo fajne rozwiązanie, zapamiętam,
dziękuję :)

--
Michał 'Khorne' Rzechonek

Sebastian Kaliszewski

unread,
Feb 27, 2008, 11:21:28 AM2/27/08
to
Seweryn Habdank-Wojewódzki wrote:
>>>> Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to
>>>> pieniądź.
>>>
>>> O tak to ma sens, ale wszystko w ten sam sposób moge sprowadzić do
>>> pieniędzy. Co więcej teorię przeciwną również.
>>
>> Ale po co sobie utrudniac życie, dla frajdy?
>
> Dla ustalenia uwagi. Nie mam nic przeciwko SGCL ani Śmieciuchowi, ani
> innemu GC dla C++ i C.
>
> Podkreślę moje stanowisko.
>
> Zarówno Ty jak i Pan Karpierz oraz wszyscy lokalni Ajatollahowie GC :-)
> znają i umieją pisać w C, C++ lub innych brzydkich językach !!!
>
> Mając to w pamięci. Kiedy mówisz o zasobach w językach z GC używasz wzorca
> projektowego "język C", czyli jezeli coś ma być napisane
> alokując/zwalniając zasoby inne niż RAM mówisz: "Piszemy jak w C!".
> To jest użycie wzorca projektowego "język C".

Nonsens.

Piszemy jak w każdym normalnym języku. Zasoby istotne się po sobie zwalnia i
są do tego narzędzia właściwe (czyli with / using, try finally, itd).

Destruktory z C++ są rozwiązaniem cienkim. Cienkim z jednego, prozaicznego,
ale kluczowego(!), powodu. Z poziomu destruktora nie da się poinformować o
błędzie (poza wywaleniem całego programu, jakże wychwalanemu przez
astronautów i ajatollachów C++, ale w Rzeczywistym Świecie(tm) zazwyczaj
Kompletnie Do Dupy(tm)).

> Teraz postaw się w sytuacji (która mnie dotknęła) wytłumacz to
> przeciętnemu koderowi języka z GC (i tylko jednego języka, bo tacy
> jednojęzykowcy są tanii).
>
> Co mu powiesz?

Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
filozofia.


>>>> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
>>>> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż
>>>> tak bardzo trzeba szanować.
>>>
>>> A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
>>> instalacji.
>>
>> W ilościach nowych projektów tworzonych w języku C++. Od kilka lat,
>> procentowo ta ilość systematycznie spada.
>
> Aha. No ja na to patrzę przez inny pryzmat.
>
> Metryka używalności:
>
> max ( liczba użytkowników, liczba instalacji )
>

Słaba to metryka. Co z tego, że coś ma miliard użytkowników, skoro żyje z
tego jeden człowiek (zostało napisane raz i już sobie jest). Dużo ciekawsza
jest metryka w czym większy procent ludzi pisze. A tu C++ jedzie w dół,
coraz ostrzej.

BTW. W 6 na 7 podanych przez ciebie przypadkach mowa jest o C a nie C++.
Z tego wynika jedno -- o ile C zostanie, bo zapotrzebowanie na "przenośny
assembler" jest i w przewidywalnej przyszłości będzie, to C++ nie ma
takiej "z góry upatrzonej pozycji na którą może się wycofać".


>> To że istnieją niekompetentni programiści, nie jest w żadnym stopniu winą
>> istnienia systemów GC.
>
> NIE! Nie jest winą GC.
>
> GC dla ludzi znających C, C++ i języki bez GC jest istotnie obniżeniem
> kosztów w sytuacji kiedy tego trzeba. Miałem osobiście przypadki kiedy
> powodowało wzrost kosztów.

Te przypadki są statystycznie nieisotne.

> Dla ludzi, nie mających pojęcia o tym, może powodować drastyczny wzrost
> kosztów w projektach korzystających z zasobów innych niż RAM na skutek nie
> przewidzianych katastrof.

Jakież to katastrofy są nieprzewidziane? Brak close łatwo zauważyć.


> Podsumowując -- wiem, że są sytuacje kiedy GC może być wygodne, ale GC to
> jest bardzo rozleniwiająca brzytwa -- generalnie goli elegancko, ale słabo
> obeznani potrafią poderżnąc sobie i innym gardło. A nalezy pamiętać, że
> określony kod jest uzywany zazwyczaj w zakresie 10 - 1000 razy większym
> podwzględem zasobów niż przewidziane przez koderów obciążenie.

To też nie jest prawda.


pzdr
\SK
--
"Never underestimate the power of human stupidity" -- L. Lang

Sebastian Kaliszewski

unread,
Feb 27, 2008, 11:34:28 AM2/27/08
to
Sebastian Nibisz wrote:

>>> Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma
>>> sie
>>> pewność, że manipulacja wskaźnikiem odbywa się w jednym wątku aplikacji.
>>
>>Pewnie można w każdym obiekcie pamiętać, który wątek ostatnio dotykał
>>jego licznika odwołań. Operacje atomowe będą potrzebne tylko kiedy
>>obiekt jest przekazywany między wątkami, co powinno być rzadkie.
>
> Niby tak, ale wyjdzie na to, że zapis i odczyt pola przechowującego
> identyfikator wątku i tak w jakiś sposób musiałby być synchronizowany.
> Zastanawiałem się kiedyś nad podobnym rozwiązaniem i doszedłem do wniosku,
> że raczej nie da sie tego w żaden sensowny sposób zaimplementować.

Hehe, zauważ, że takie "pole" bardzo często masz już za darmo, na i396 i
x86-64 leży sobie ono w procesorze i dostępne jesyt poprzez FS albo GS
(zależnie od ABI) :).

Piotr Wyderski

unread,
Feb 27, 2008, 12:54:06 PM2/27/08