Nie korzystalem z Garbage Collectora w C i C++, ale uzywam juz Valgrinda. Czy korzystajac z Valgrind i poprawiajac kod wg jego zalecen to skutecznosc jest taka jakbym korzystal z zewnetrznego Garbage Collector ?
0
1
GC polega na tym zebys nie musial poprawiac wyciekow pamieci.
0
@teofrast: Skuteczność jeżeli chodzi o wycieki pamięci powinna być taka sama w nowoczesnym c++, ale nadal garbage collector i scopy w c++ to coś innego.
Poprawcie mnie jeśli się mylę, ale różnica jest mniej więcej taka:
{
int x = 5;
std::cout << x; // garbage collector widzi, że już nie będzie wywołań x i może go tutaj usunąć // JAVA
std::cout << "dupa";
} // tutaj kończy się scope i x jest ściągane ze stosu // C++
Odpowiadając na pytanie:
Czy korzystajac z Valgrind i poprawiajac kod wg jego zalecen to skutecznosc jest taka jakbym korzystal z zewnetrznego Garbage Collector ?
nie
5
teofrast napisał(a):
Nie korzystalem z Garbage Collectora w C i C++, ale uzywam juz Valgrinda. Czy korzystajac z Valgrind i poprawiajac kod wg jego zalecen to skutecznosc jest taka jakbym korzystal z zewnetrznego Garbage Collector ?
Polecam korzystać z opcji kompilatora address sanitizer. Lepsze od valgrind, kara do wydajności jest dużo mniejsza.
Obecnie narzędzie jest dostępne dla wszystkich głównych kompilatorów: clang (był pierwszy), gcc (ma dość długo), MSVC (od niedawna, chyba nadal experimental).
Valgrind ma swoje ograniczania i nie potrafi wykryć wszystkiego.
GC jest rozwiazaniem runtime - ergo daje narzut w czasie wykonywania. Valgrind/Address Sanitizer pozwala poprawić kod tak, by pamięć byłą zarządzana poprawnie i w sposób deterministyczny (GC tego nie potrafi).
Jest pewna klasa błędów zarządzania pamięci, dla których każde z tych narzędzi zawodzi (GC też).
4
Cepo napisał(a):
Poprawcie mnie jeśli się mylę, ale różnica jest mniej więcej taka:
{ int x = 5; std::cout << x; // garbage collector widzi, że już nie będzie wywołań x i może go tutaj usunąć // JAVA std::cout << "dupa"; } // tutaj kończy się scope i x jest ściągane ze stosu // C++
To trochce inaczej działa i zalezy od poziomu optymalizacji. Jesli masz GC oparte naliczeniu referencji to (zakładając że x jest zmienną/buforem na stercie do której jest liczona referencja x) gdy x jest poza scopem licznik referencji do bufora jest zmniejszany a gdy osiągnie zero to bufor jest usuwany (zaraz przyjdą tu pewnie mistrzowie liczenia referencji i Rusta i wytłumaczą to lepiej)
W Javie jest GC oparte na przeglądaniu sterty i tak naprawdę nie wiadomo czy zmienna zostanie usunąta i czy kiedykolwiek zostanie usunięta. Jeśli jest tworzone bardzo mało zmiennych na stercie, a pamięć jest bardzo duża to teoretycznie nigdy GC nie zostanie uruchomiony. Była nawet implementacja GC na potrzeby testów która nigdy nie wykonywała sprzątania. Po co sprzątać jeśli za minutę aplikacja przestanie żyć a pamięci jest jeszcze dużo?
UPDATE: oczywiście powyższy kod słabo to obrazuje bo zarówno w C++ jak i Javie int zostanie utworzony na stosie więc żadne GC nie jest nam potrzebne :P
1
@teofrast: nie, to zupełnie inna strategia działania. Niektóre sytuacje jak np. cykle jest bardzo ciężko rozwiązać przy pomocy ręcznego zwalniana pamięci. Dla niektórych zastosowań GC jest nie tylko ułatwieniem, jeśli chodzi o bezpieczeństwo/przyjemność kodzenia ale też performance. Aplikacje napisane w Javie działałyby dużo wolniej niż teraz, gdyby robiły malloc/free tak jak to robi C
4
(tracing) GC (bo zwykle o tracing GC chodzi jeśli nie dopisuje się rodzaju) to nie tylko skuteczność, ale i wygoda, zwłaszcza w obliczu wielu wątków, callbacków, itp itd Semantycznie (w przypadku tracing GC) jest jeden rodzaj referencji, podczas gdy w C/C++/Ruście/etc jest kilka, np: goła referencja do indywidualnego obiektu na stosie, goła referencja do indywidualnego obiektu na stercie, referencja ze zliczaniem nieatomowa (czyli ograniczona do jednowątkowości), referencja ze zliczaniem atomowa (czyli można współdzielić między wątkami), referencja do obiektu z puli (takiej, którą można zwalniać hurtowo, a więc trzeba pamiętać o cyklu życia pojedynczego obiektu jak i całej puli), czy też np. referencja z jakiegoś dołączanego GC (bo w C/C++/Ruście można dołączyć GC jako bibliotekę). Oczywiście tracing GC nie wyeliminuje magicznie wyścigów danych w ogólności, ale i tak (moim zdaniem) jest znacznie wygodniej.