🚀 go-pugleaf

[ciach]

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

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

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

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

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 

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

Michał 'Khorne' Rzechonek wrote:

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

Dzieki za miłe słowo, ale prostota tego rozwiązania jest złudna. :-)

    Pozdrawiam
    Piotr Wyderski

sobota, 23 lutego 2008 o 21:24:23 UTC+1 Sebastian Nibisz napisał(a):
> 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 -

Odkopię ten historyczny temat.
Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https://github.com/pebal/sgcl

Odkopię ten historyczny temat.
Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https://github.com/pebal/sgcl

On Thursday, January 19, 2023 at 1:51:44 PM UTC+1, Sebastian Nibisz wrote:
> Odkopię ten historyczny temat. 
> Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https://github.com/pebal/sgcl

Korzysta z STL'a?

czwartek, 9 marca 2023 o 19:44:15 UTC+1 Przemek Biernat napisał(a):
> On Thursday, January 19, 2023 at 1:51:44 PM UTC+1, Sebastian Nibisz wrote: 
> > Odkopię ten historyczny temat. 
> > Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https://github.com/pebal/sgcl
> Korzysta z STL'a?
Korzysta. Obecnie raczej trudno obyć się bez STL'a.

On Thursday, March 9, 2023 at 10:19:07 PM UTC+1, Sebastian Nibisz wrote:
> czwartek, 9 marca 2023 o 19:44:15 UTC+1 Przemek Biernat napisał(a): 
> > On Thursday, January 19, 2023 at 1:51:44 PM UTC+1, Sebastian Nibisz wrote: 
> > > Odkopię ten historyczny temat. 
> > > Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https://github.com/pebal/sgcl 
> > Korzysta z STL'a?
> Korzysta. Obecnie raczej trudno obyć się bez STL'a.

Obyłem się. Napisałem własną bibliotekę, która została rozwinięta. STL jest słabe. Iteratory przez wartość, brak cykli, brak klonowania iteratora, bida. Szczerze to nie wiem do czego służy SGCL, jak mi wyjaśnisz to napiszę własną wersję, może będzie działać wydajniej.

czwartek, 9 marca 2023 o 22:24:34 UTC+1 Przemek Biernat napisał(a):
> On Thursday, March 9, 2023 at 10:19:07 PM UTC+1, Sebastian Nibisz wrote: 
> > czwartek, 9 marca 2023 o 19:44:15 UTC+1 Przemek Biernat napisał(a): 
> > > On Thursday, January 19, 2023 at 1:51:44 PM UTC+1, Sebastian Nibisz wrote: 
> > > > Odkopię ten historyczny temat. 
> > > > Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https://github.com/pebal/sgcl 
> > > Korzysta z STL'a? 
> > Korzysta. Obecnie raczej trudno obyć się bez STL'a.
> Obyłem się. Napisałem własną bibliotekę, która została rozwinięta. STL jest słabe. Iteratory przez wartość, brak cykli, brak klonowania iteratora, bida. Szczerze to nie wiem do czego służy SGCL, jak mi wyjaśnisz to napiszę własną wersję, może będzie działać wydajniej.
SGCL to współbieżny, całkowicie bezpauzowy garbage collectror dla C++. Chcesz napisać szybszy? Powodzenia. Szczególnie w tym, aby w ogóle działał.

On Thursday, March 9, 2023 at 10:40:41 PM UTC+1, Sebastian Nibisz wrote:
> czwartek, 9 marca 2023 o 22:24:34 UTC+1 Przemek Biernat napisał(a): 
> > On Thursday, March 9, 2023 at 10:19:07 PM UTC+1, Sebastian Nibisz wrote: 
> > > czwartek, 9 marca 2023 o 19:44:15 UTC+1 Przemek Biernat napisał(a): 
> > > > On Thursday, January 19, 2023 at 1:51:44 PM UTC+1, Sebastian Nibisz wrote: 
> > > > > Odkopię ten historyczny temat. 
> > > > > Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https://github.com/pebal/sgcl 
> > > > Korzysta z STL'a? 
> > > Korzysta. Obecnie raczej trudno obyć się bez STL'a. 
> > Obyłem się. Napisałem własną bibliotekę, która została rozwinięta. STL jest słabe. Iteratory przez wartość, brak cykli, brak klonowania iteratora, bida. Szczerze to nie wiem do czego służy SGCL, jak mi wyjaśnisz to napiszę własną wersję, może będzie działać wydajniej.
> SGCL to współbieżny, całkowicie bezpauzowy garbage collectror dla C++. Chcesz napisać szybszy? Powodzenia. Szczególnie w tym, aby w ogóle działał.

Garbage collector w C++, hmm, ciekawe, tylko po co? Nie lepiej dobrze nauczyć się pisać w C++ i kontrolować czas życia obiektu z użyciem new i delete. Alokator ma jakiś sens bo przyspiesza tworzenie nowych obiektów. W naszym kompilatorze jest o ile dobrze pamiętam wsparcie dla scope'ów więc sprawa jest odrobinę łatwiejsza jeżeli się nie mylę. Co ja tam mogę wiedzieć.

piątek, 10 marca 2023 o 15:41:14 UTC+1 Przemek Biernat napisał(a):
> On Thursday, March 9, 2023 at 10:40:41 PM UTC+1, Sebastian Nibisz wrote:
> > czwartek, 9 marca 2023 o 22:24:34 UTC+1 Przemek Biernat napisał(a): 
> > > On Thursday, March 9, 2023 at 10:19:07 PM UTC+1, Sebastian Nibisz wrote: 
> > > > czwartek, 9 marca 2023 o 19:44:15 UTC+1 Przemek Biernat napisał(a): 
> > > > > On Thursday, January 19, 2023 at 1:51:44 PM UTC+1, Sebastian Nibisz wrote: 
> > > > > > Odkopię ten historyczny temat. 
> > > > > > Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https://github.com/pebal/sgcl 
> > > > > Korzysta z STL'a? 
> > > > Korzysta. Obecnie raczej trudno obyć się bez STL'a. 
> > > Obyłem się. Napisałem własną bibliotekę, która została rozwinięta. STL jest słabe. Iteratory przez wartość, brak cykli, brak klonowania iteratora, bida. Szczerze to nie wiem do czego służy SGCL, jak mi wyjaśnisz to napiszę własną wersję, może będzie działać wydajniej. 
> > SGCL to współbieżny, całkowicie bezpauzowy garbage collectror dla C++. Chcesz napisać szybszy? Powodzenia. Szczególnie w tym, aby w ogóle działał.
> Garbage collector w C++, hmm, ciekawe, tylko po co? Nie lepiej dobrze nauczyć się pisać w C++ i kontrolować czas życia obiektu z użyciem new i delete. Alokator ma jakiś sens bo przyspiesza tworzenie nowych obiektów. W naszym kompilatorze jest o ile dobrze pamiętam wsparcie dla scope'ów więc sprawa jest odrobinę łatwiejsza jeżeli się nie mylę. Co ja tam mogę wiedzieć.
Nie da się wszystkim zarządzać ręcznie, bo problem własności nie zawsze jest trywialny. Poszukaj implementacji współbieżnego stosu w C++, który zwalnia pamięć. Nawet biblioteka boost takiej nie ma a mając GC implementacja jest trywialna.

On Friday, March 10, 2023 at 4:01:54 PM UTC+1, Sebastian Nibisz wrote:
> piątek, 10 marca 2023 o 15:41:14 UTC+1 Przemek Biernat napisał(a): 
> > On Thursday, March 9, 2023 at 10:40:41 PM UTC+1, Sebastian Nibisz wrote: 
> > > czwartek, 9 marca 2023 o 22:24:34 UTC+1 Przemek Biernat napisał(a): 
> > > > On Thursday, March 9, 2023 at 10:19:07 PM UTC+1, Sebastian Nibisz wrote: 
> > > > > czwartek, 9 marca 2023 o 19:44:15 UTC+1 Przemek Biernat napisał(a): 
> > > > > > On Thursday, January 19, 2023 at 1:51:44 PM UTC+1, Sebastian Nibisz wrote: 
> > > > > > > Odkopię ten historyczny temat. 
> > > > > > > Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https:

Napisałem i zaprojektowałem trochę kodu również współbieżnego i ani razu nie użyłem GC. Być może jak masz błędy w projekcie to garbage collector jest potrzebny. Trudno mi powiedzieć.

piątek, 10 marca 2023 o 16:49:10 UTC+1 Przemek Biernat napisał(a):
> On Friday, March 10, 2023 at 4:01:54 PM UTC+1, Sebastian Nibisz wrote: 
> > piątek, 10 marca 2023 o 15:41:14 UTC+1 Przemek Biernat napisał(a): 
> > > On Thursday, March 9, 2023 at 10:40:41 PM UTC+1, Sebastian Nibisz wrote: 
> > > > czwartek, 9 marca 2023 o 22:24:34 UTC+1 Przemek Biernat napisał(a): 
> > > > > On Thursday, March 9, 2023 at 10:19:07 PM UTC+1, Sebastian Nibisz wrote: 
> > > > > > czwartek, 9 marca 2023 o 19:44:15 UTC+1 Przemek Biernat napisał(a): 
> > > > > > > On Thursday, January 19, 2023 at 1:51:44 PM UTC+1, Sebastian Nibisz wrote: 
> > > > > > > > Odkopię ten historyczny temat. 
> > > > > > > > Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https:
> Napisałem i zaprojektowałem trochę kodu również współbieżnego i ani razu nie użyłem GC. Być może jak masz błędy w projekcie to garbage collector jest potrzebny. Trudno mi powiedzieć.
To, że czegoś nie użyłeś nie świadczy o tym, że coś jest niepotrzebne. Niektórzy nie są nawet świadomi takich problemów jak ABA a wydaje im się, że wszystko wiedzą.

On Friday, March 10, 2023 at 5:18:02 PM UTC+1, Sebastian Nibisz wrote:
> piątek, 10 marca 2023 o 16:49:10 UTC+1 Przemek Biernat napisał(a): 
> > On Friday, March 10, 2023 at 4:01:54 PM UTC+1, Sebastian Nibisz wrote: 
> > > piątek, 10 marca 2023 o 15:41:14 UTC+1 Przemek Biernat napisał(a): 
> > > > On Thursday, March 9, 2023 at 10:40:41 PM UTC+1, Sebastian Nibisz wrote: 
> > > > > czwartek, 9 marca 2023 o 22:24:34 UTC+1 Przemek Biernat napisał(a): 
> > > > > > On Thursday, March 9, 2023 at 10:19:07 PM UTC+1, Sebastian Nibisz wrote: 
> > > > > > > czwartek, 9 marca 2023 o 19:44:15 UTC+1 Przemek Biernat napisał(a): 
> > > > > > > > On Thursday, January 19, 2023 at 1:51:44 PM UTC+1, Sebastian Nibisz wrote: 
> > > > > > > > > Odkopię ten historyczny temat. 
> > > > > > > > > Po piętnastu latach SGCL doczekał się zupełnie nowej implementacji. Przenośnej, z mniejszym narzutem pamięci niż shared_ptr, działającej ;-): https: 
> > Napisałem i zaprojektowałem trochę kodu również współbieżnego i ani razu nie użyłem GC. Być może jak masz błędy w projekcie to garbage collector jest potrzebny. Trudno mi powiedzieć.
> To, że czegoś nie użyłeś nie świadczy o tym, że coś jest niepotrzebne. Niektórzy nie są nawet świadomi takich problemów jak ABA a wydaje im się, że wszystko wiedzą.

Ja pisałem proste rzeczy w najbardziej prosty sposób. Być może w twoim przypadku GC jest potrzebny. Nie wiem tego. Co do współbieżności to u mnie wystarczyła sekcja krytyczna i sprawdzenie flagi.

piątek, 10 marca 2023 o 17:18:02 UTC+1 Sebastian Nibisz napisał(a):
> piątek, 10 marca 2023 o 16:49:10 UTC+1 Przemek Biernat napisał(a): 
> > Napisałem i zaprojektowałem trochę kodu również współbieżnego i ani razu nie użyłem GC. Być może jak masz błędy w projekcie to garbage collector jest potrzebny. Trudno mi powiedzieć.
> To, że czegoś nie użyłeś nie świadczy o tym, że coś jest niepotrzebne. Niektórzy nie są nawet świadomi takich problemów jak ABA a wydaje im się, że wszystko wiedzą.

Właśnie sobie poczytałem o problemie ABA i wygląda to trochę jak "użyliśmy wadliwej reprezentacji dla naszego zagadnienia i teraz mamy problem, ale zamiast zmienić reprezentację, będziemy brnąć w zaparte"

On Monday, March 20, 2023 at 8:01:02 AM UTC+1, Maciek Godek wrote:
> piątek, 10 marca 2023 o 17:18:02 UTC+1 Sebastian Nibisz napisał(a): 
> > piątek, 10 marca 2023 o 16:49:10 UTC+1 Przemek Biernat napisał(a): 
> > > Napisałem i zaprojektowałem trochę kodu również współbieżnego i ani razu nie użyłem GC. Być może jak masz błędy w projekcie to garbage collector jest potrzebny. Trudno mi powiedzieć. 
> > To, że czegoś nie użyłeś nie świadczy o tym, że coś jest niepotrzebne. Niektórzy nie są nawet świadomi takich problemów jak ABA a wydaje im się, że wszystko wiedzą.
> Właśnie sobie poczytałem o problemie ABA i wygląda to trochę jak "użyliśmy wadliwej reprezentacji dla naszego zagadnienia i teraz mamy problem, ale zamiast zmienić reprezentację, będziemy brnąć w zaparte"

Też mi się tak w pierwszej chwili wydawało, że problem leży po stronie projektu/struktur czy jak to się ładnie nazywa reprezentacji dla zagadnienia. Opinia jest jak d.pa każdy ma swoją tylko cudza śmierdzi bardziej.