Fruit International

Obrazek ovoce

else return -1;

Fruit Intl. morálně podporuje následující projekty:

schemik.sourceforge.net
diagnose.sourceforge.net
www.rustina-preklad.cz
petruj.eu/blog/

A vitezem jsou - popelari

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

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


Přidat komentář