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

mam tu jedno reseni, jak zlepsit vysledek mallocu, vsiml jsem si toho az pozdej... staci jednoduse ovlivnit prostredi mereni...

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.

Vytvořil(a) deda.jabko v 26. 02. 2007, 19:48