Fragmentace paměti s hash_setem (diskuse)

[l4m4]

To je zase benchmark...

For glib and ghthash, what is inserted is the pointer to the integer instead of the integer itself.

A ještě to pak drze diskutuje, že nevýhoda C-implementací generických hash tabulek je, že se to takhle musí dělat. Přitom jsem neviděl kód, který by v do GHashTable integery ukládal jinak než přes GINT_TO_POINTER() (a podobná makra), tj. přímo do tabulky bez dalších alokací...

[limit_false]

Njn, ja to cetl asi pred rokem kdyz jsem ten problem s fragmentaci pameti resil (taky jsem potreboval sablonoidne struktury, tim padem glib a ghthash vypadli). IMHO udelat poradny benchmark je neskutecne prace (proto vetsina benchmarku vypada tak jak vypada). Vzdy je lepsi (nebo spis nutny) si vsechno premerit (jine podminky, jine vysledky).

[petr_p]

Ehm, standardní knihovna je implementovaná z větší části v glibc, ne v gcc. Řekl bych, že i ty hash mapy nebo sety.

[l4m4]

Podle mne myslel standardní knihovnu C++ (libstdc++ AKA STL). Ta přichází s gcc. Coby podmnožinu z definice zahrnuje i standardní knihovnu C, takže teď bychom mohli začít řešit, co je větší, nicméně STL je v gcc.

[limit_false]

STL je urcite implementovana jako soucast gcc/msvc (i kdyz treba existuji separatni implementace jako STLport). C++ sablony navic ani nejde kompilovat (do strojoveho kodu; jedine do predkompilovanych headeru) pokud se neudela konkretni instanciace.

Na druhe strane implementace sablon urcite pouziva funkce z glibc (treba malloc/free pres new/delete a std::allocator), tim padem vykon znacne zavisi i od glibc.

Taky mam domnenku, ze od glibc zavisi rychlost vyjimek (tohle nemam jeste vyreseno, urcite jde o nejakou kombinaci z trojice glibc, binutils, libgcc_s.so), viz nasledujici pripad (__cxa_throw a _Unwind*):

spousta vyjimek v CentOS 4

spousta vyjimek v CentOS 5

Obe mereni je stejny testcase (specialni extremni pripad s 70000 vyjimkama, nemilujete proste specialni pripady? ). Vzdy prelozeno s gcc 4.1.2 (libgcc_s.so je soucasti gcc, tim padem i stejna libgcc_s.so odkud jsou _Unwind* funkce). Jednou na CentOS 4 s glibc 2.3.4 a jednou na CentOS 5 s glibc 2.5. Jedina rozdilna vec krome glibc jsou jiny verze binutils. No a ta CentOS 5 verze beha v danem pripade vic nez 5x rychleji.

(Nejspis ten problem s vyjimkama bude mat neco do cineni s timhle: http://gcc.gnu.org/ml/gcc/2005-02/msg00627.html ).

[limit_false]

Pozn. v tech grafech pochazeji vsechny funkce pod __cxa_throw z libgcc_s.so krome dl_iterate_phdr (je z glibc) a __gxx_personality_v0 (je z libstdc++ i s uzlem pod nim).

[Michal Kubeček]

Na druhe strane implementace sablon urcite pouziva funkce z glibc (treba malloc/free pres new/delete a std::allocator)

Ne nutně. Na unixových systémech to tak nejspíš většinou bude, ale nemusí to tak fungovat všude. Standardní C++ knihovna může být teoreticky naprosto nezávislá na standardní C knihovně.

[limit_false]

Prilis si neumim predstavit jak by se implementovalo new/delete nebo std::allocator bez malloc nebo mmap. Snad jedine primym volanim do kernelu (pres preruseni), co je prilis low-level pro standardni C++ knihovnu.

[Michal Kubeček]

Prostě by si tu alokaci napsali autoři sami, stejně jako ji napsali autoři implementace malloc() a free() v libc. Uvědomte si, že C++ je jazyk zcela nezávislý na C, teoreticky byste mohl mít C++ i na platformě, kde vůbec neexistuje překladač céčka, a tedy ani standardní C knihovna. Koneckonců dřív používala i řada projektů psaných v C své vlastní náhražky za systémové malloc() a free() a autoři to zdůvodňovali tím, že jejich implementace jsou efektivnější, což by nebylo dost dobře možné, kdyby to byly jen nadstavby nad těmi systémovými implementacemi.

[limit_false]

Tak tady doslo asi k nedorozumeni. Ja puvodne psal o zavislosti na glibc uz jenom proto (pripad Linuxu), ze na preimplementovani malloc/free potrebujete nejakou systemovou funkci jako mmap/brk, abyste mel _nejakou_ pamet nad ktorou postavite vlastni malloc/free. A mmap/brk je taky soucasti glibc (jinak musite volat kernel primo pres preruseni/syscall).

[Michal Kubeček]

A mmap/brk je taky soucasti glibc (jinak musite volat kernel primo pres preruseni/syscall).

Odpověděl jste si sám: ty funkce nejsou nic jiného než wrappery nad příslušné syscally. A použití céčkových wrapperů není principiálně nutné. Navíc se na to pořád díváte příliš linuxocentricky.

[limit_false]

True Dival jsem se na na jiny implementace new, snad vsechny bezne non-embedded systemy volaji nejakou verzi malloc (vratane msvc). Pak jsem disassembloval mmap, abych videl ze nema extra rezii. K alokatorum se jeste dostanu.

BTW nechapu tvrzeni "Standardní C++ knihovna může být teoreticky naprosto nezávislá na standardní C knihovně." AFAIK musi C++ alespon implementovat vsechny funkce C, treba taky malloc?

[Michal Kubeček]

Všechny rozhodně ne, jen některé. Funkce malloc() mezi nimi sice je, ale neznamená to, že musí jít o stejnou implementaci jako v libc. Vztah mezi funkcí malloc() a operátorem new je takový, že malloc() nesmí k alokaci použít new

The functions calloc(), malloc(), and realloc() do not attempt to allocate storage by calling ::operator new().

ale na druhou stranu se výslovně uvádí, že není specifikováno, zda operátor new používá malloc() nebo ne

Whether the attempt involves a call to the Standard C library function malloc is unspecified.

Takže operátor new může být nadstavba nad funkcí malloc(), ale stejně tak na ní může být úplně nezávislý. Funkce malloc() ale nesmí být implementována pomocí operátoru new, IMHO kvůli tomu, aby bylo možné beztrestně overloadovat new vlastní verzí využívající malloc().

[Michal Kubeček]

Příkladem něčeho, co je garantováno v ISO C, ale v ISO C++ to být nemusí, jsou např. celočíselné typy definované v <stdint.h>. V C++ programu se obecně nemůžete spolehnout na to, že je budete mít k dispozici (ani ty, jejichž dostupnost garantuje norma jazyka C).