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 ?
C 
C++ 
- Rejestracja:około 4 lata
- Ostatnio:około 3 lata
- Postów:48
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
edytowany 6x, ostatnio: Cepo
- Rejestracja:około 17 lat
- Ostatnio:minuta
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ż).
- Rejestracja:ponad 6 lat
- Ostatnio:4 dni
- Lokalizacja:Silesia/Marki
- Postów:5505
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
edytowany 4x, ostatnio: KamilAdam
- Rejestracja:około 7 lat
- Ostatnio:około 4 godziny
- Postów:876
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
- Rejestracja:prawie 20 lat
- Ostatnio:około godziny
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.
Ja bym raczej powiedział że "data race" to jest "wyścig o dane" - proszę nie kaleczyć polskiego :c
a ja bym powiedział, że na razie nie mam zdania. widziałem tylko "wyścigi danych", ale na forum, a nie w przetłumaczonych książkach.
No ale to powiedz - dane jakieś tutaj się ścigają? Czy raczej kod się ściga z innym kodem o dostęp do danych?
no powiedzmy, że "wyścig o dane" jest bardziej logiczny. czy ktoś już tak tłumaczył?
nie, albo przeczytałem o jedno za dużo :P