A vitezem jsou - popelari

10.10.2006 18:45 | Přečteno: 1913× | Programování | | poslední úprava: 10.10.2006 19:21

Mam tu rozepsany text srovnavajici spravu pameti z pohledu aplikace a jelikoz vetsina je o automaticke dealokaci a jejich vyhodach, tak jsem zkusil udelat priklad, kde by tolik pomlouvani sberaci odpadku vyhrali.

Je to opravdu hruza a s realnym pouzitim to nema nic spolecneho. Kazdopadne ty rozdily jsou docela markantni a zajimave

• Jako jednoznacny vitez se ukazala varianta s boehmovym kolektorem (2.36s).
• Jako druhy se umistilo nechat pamet alokovanou a nechat uvolneni na smrt aplikace (3.34s). Horsi cas bude asi zpusoben tim, ze pri alokacich se mnohem casteji pouzivaji syscally nez treba u garbage collectoru.
• Nejhur skoncilo hlidat si pamet rucne, pomoci malloc a free (5.30s). Velka rezie je zpusobena skladovanim volnych bloku po dealokaci a jejich opetovanym hledanim pri malloc

#include <gc/gc.h>
#include <stdlib.h>

#define MAX_ALLOCATIONS (10000000)

#ifdef USE_GC
        #define ALLOC(x) (GC_MALLOC_ATOMIC(x))
        #define FREE(x) GC_FREE(x)
#endif

#ifdef USE_GLIBC
        #define ALLOC(x) (malloc(x))
        #define FREE(x) free(x)
#endif

#ifdef USE_LEAVE_ALLOCATED
        #define ALLOC(x) (malloc(x))
        #define FREE(x) {}
#endif

int main(int argc, char **argv)
{
        unsigned long i;
        unsigned long result;
        for (i = 0; i < MAX_ALLOCATIONS; i++) {
                int * a = ALLOC(sizeof(unsigned long));
                *a = i * 2;
                result += *a;
                FREE(a);
        }

        return 0;
}

       

Komentáře

[Michal Vyskočil]

Moc hezké, mám pocit, že něco podobného budu časem potřebovat taky. Tak mám další novou záložku na dlouhé zimní večery

[Kníže Ignor]

Proč se volá GC_FREE()? Však i v tom příkladě z těch stránek se píše: "A function GC_FREE is provided but need not be called. For very small objects, your program will probably perform better if you do not call it, and let the collector do its job."

[deda.jabko]

dobra pripominka... napsal jsem to tak nejak instinktivne, ale rozdil v tom moc neni.

[MJ]

Takovýhle test ukazuje spíš než na výhodnost popelaření na nešikovnost alokátoru v libc

Knihovní malloc() je pěkně obecný (thread-safe a kdo ví, co všechno ještě), ale rychlostí opravdu neoplývá, zvlášť při alokování maličkých bloků (ostatně paměťový overhead jednoho pointeru na alokovaný blok také není zanedbatelný).

V takovémhle případě je nejrychlejší napsat si alokátor vlastní, který ví o tom, že alokujete pořád stejné bloky (to sice není obecně pravda, ale pokud program alokuje spoustu bloků, jsou skoro vždy několika málo různých velikostí). Pěkným příkladem je třeba SLAB alokator použitý v kernelu.

Tím určitě nechci pány popeláře zatracovat, ono programování s garbage collectorem je opravdu příjemné a návykové, ale určitě bych to nedělal kvůli výkonu...

[deda.jabko]

jo s tim taky souhlasim... ten alokator z glibc je fakt general-purpouse a treba je prakticky nepouzitelny v masivne paralelni aplikacich. na to se me velice osvedcil hoard. na druhou stranu napsat kvalitni alokator, ktery se umi chovat (rozume rychly, thread-safe a k tomu usporny) je docela veda.

[MJ]

Ono v masivně paralelních aplikacích bývá daleko lepší nezatěžovat se thread-safe alokací a rozdělit adresní prostor mezi thready a nechat každý, ať si alokuje na svém písečku. Nebo ho aspoň rozdělit na něco jako 1MB bloky a ty přidělovat threadům bezpečně a pak každý nechat, ať si své bloky rozděluje po svém.

[deda.jabko]

toto ma beohmuv kolektor docela elegantne osefovane... pri alokacich se pouziva lokalni cache (neco jako to 1MB bloky) a i pres to je mozne pouzivat alokovanou pamet napric thready. ma to jednu chybicku -- k informaci, kde je ta cache se pristupuje pres pthread_getspecific a v pripade, ze je nejaka funkce volana z hlavniho vlakna, nelze pouzit lokalni cache... takze je potreba si to hlidat

[Bluebear]

Promiň, ale myslím, že tenhle konkrétní příklad nemá statistickou hodnotu.

Bylo by třeba provést ten test na různých platformách, různých procesorech, zjistit, jak se to chová, pokud se kromě alokací provádí ještě i něco dalšího, a především prozkoumat a změřit, kde se ten čas ve skutečnosti spotřebovává.

IMHO hlavní slabina garbage collectoru nespočívá v pomalosti, ale v tom, že zavádí do běhu programu obtížně předvídatelná zdržení. Což podle typu aplikace může vadit citelně nebo vůbec ne.

[deda.jabko]

opet souhlasim... neni to realworld zalezitost a hlavne jsem to psal jako demonstraci, ze garbage collector i presto, ze je vyrazne slozitejsi muze byt za urcitych okolnosti rychlejsi. spis nez, "bylo by potreba" bych pouzil formulaci "bylo by zajimave"... samotneho by me to zajimalo, ale nejak neni cas... ty poznamky co jsem tam pripisoval, jsou vicemene takove "pozorovani" co jsem za pul roku co jsem se spravou pameti zabyval postrehl.

[Tom.š Ze.le.in]

A co porovnání s alokací na stacku? Kdysi mne někdo odkázal na tohle, pokud by to někoho zajímalo...

GC je rychlejší než stack - ne, není

[PaKr]

Stačí malinkatá úprava a klasický malloc je najednou cca 70x rychlejší.

#include <gc/gc.h>
#include <stdlib.h>

#define MAX_ALLOCATIONS (416660)

#define USE_GC

#ifdef USE_GC
        #define ALLOC(x) (GC_MALLOC_ATOMIC(x))
        #define FREE(x) {}
#endif

#ifdef USE_GLIBC
        #define ALLOC(x) (malloc(x))
        #define FREE(x) free(x)
#endif

#ifdef USE_LEAVE_ALLOCATED
        #define ALLOC(x) (malloc(x))
        #define FREE(x) {}
#endif

int main(int argc, char **argv)
{
        unsigned long i;
        unsigned long result;
        for (i = 0; i < MAX_ALLOCATIONS; i++) {
                int * a = ALLOC(3000*sizeof(unsigned long));
                *a = i * 2;
                result += *a;
                FREE(a);
        }

        return 0;
}

[deda.jabko]

:-]]

mam jeste jedno reseni, jak zlepsit vysledek mallocu, vsiml jsem si toho bohuzel az dneska rano... staci jednoduse ovlivnit prostredi mereni... o neco vys bylo zminene ze bych mel vyzkouset vic platforem... tak jsem si to zkusil....

puvodni test byl delany na i386 smp systemu s jadrem 2.4 a linux threads. rano jsem to zkusil na mem jednoprocosorovem amd64, jadrem 2.6 a nptl. a tady uz se rychlost gc a rychlost mallocu prakticky rovnaji. problem je hluboku v glibc, jelikoz je malloc threadsafe a pri kazde alokaci dochazi k zamykani. jenomze v linuxthreads jsou mutexy na smp architekturach brutalne pomale... kdezto v nptl, je zamykani reseno pomoci futexu a ty jsou o poznani rychlejsi... ale o tom nekdy priste.