C/C++ Engine a alokace paměti

[perry]

Zdravím,

ve svém enginu potřebuju za běhu vytvářet objekty (řekněme stavět zdi apod.). Každý objekt světa mám reprezentovaný N-ticí vlastností (grafika, fyzikální vlastnosti a logika (1 - N), pozice ve světě, boundig-box (1 - N))
Když vytvořím nový objekt, musím vytvořit instance všech zmíněných entit a pak objekt zaregistrovat do scény. To funguje tak, jak potřebuju.
Nicméně tvoření objektu = kupa volání "new" (a popř. klasický malloc). Předem si můžu naalokovat pouze některé entity, ale ne vše. Z toho, co vím, tak není dobré alokovat paměť za běhu pořád dokola, navíc např. každou minutu alokovat a uvolňovat přes delete.
Takže by to pravděpodobně chtělo nějaký memory-manager, kde alokuju paměť a pak z ní budu jenom přidělovat bloky...
Např. pěkný popis jednoho možného řešení jsem našel tady: http://www.ibm.com/developerworks/aix/tutorials/au-memorymanager/index.html, což mi dalo nějakou základní myšlenku jak to udělat.
Má cenu nějaký jednoduchý memory-manager naprogramovat (ala ten tutorial), nebo mám zůstat u volání new / delete... nebo mám použít nějaké 3rd party řešení.
_________________
Perry.cz

[mar]

No myslím si, že to cenu nemá
Pokud ti to funguje a nebrzdí ti to výkon, pak nevidím důvod něco měnit.
Jediný problém v častých alokacích/dealokacích může být fragmentace pokud často alokuješ a uvolňuješ velké bloky.

Pokud chceš přece jen vlastní memory manager, můžeš zkusit třeba tohle, je to public domain: http://g.oswego.edu/dl/html/malloc.html

[Tringi]

Dnešní nativní general purpose alokátory jsou dostatečně rychlé na to, abys je mohl použít aniž by ses bál nízké efektivity, přinejmenším do té úrovně, že neoptimalizuješ předem něco, co nebude úzkým hrdlem tvého enginu. Někde jsem si profiloval alokaci libc/malloc a kmalloc i msvcrt/malloc a HeapAlloc (6.0+), čísla můžu dohledat, ale výsledkem bylo, že investovat energii do hledání či implementace rychlejšího (pro náhodně velké objekty, za zachování rozumného overheadu) se opravdu vůbec nevyplatí.

Pokud si následně někdy v budoucnu odprofiluješ, že alokace jsou tím, co tě výrazně brzdí, pak teprve zvažuj jakým nejvhodnějším alokátorem je nahradit. Jeho/jejich volba se bude výrazně odvíjet od množství alokací, různorodosti velikostí a také vzorcem alokací a uvolňování.
_________________
WWW | GitHub | TW

[perry]

Ok.. diky Zaměřím svoje úsilí jiným směrem
_________________
Perry.cz

[OndraSej]

perry> podle obvykleho pravidla, ze nejhorsi ze vseho jsou predcasne optimalizace, bych byt tebou zustal u new/delete dokud nebudou vyrazne omezovat vykon. Pokud nebudes delat nejake zvracenosti, pak new/delete nejsou az tak strasne. Pokud tech alokaci delas jen nekolik (tisic) za frame, nemel by to byt takovy problem.

A i potom je IMO lepsi pouzit specialni alokator jen ve specialnich pripadech (napriklad slab allocator pro male objekty, kterych mas opravdu hodne, nebo arena allocator, pokud uvnitr konkretniho bloku kodu alokujes hromadu dat, ktera se nikdy nedostanou ven). Psat si vlastni obecny alokator (ktery navic pobezi uvnitr jineho obecneho alokatoru) mi prijde dost zbytecne. A pokud muzes pouzit valgrind nebo podobne nastroje, tak se to nevyplati ani kvuli hlidani alokaci pameti.
_________________
http://trionteam.net

[perry]

No..předčasný optimalizace jsou k ničemu.. ale u tohohle jsem myslel, že by případně bylo lepší to napsat teď, než potom,kdy se to bude blbě ladit už. Jinak na leaky mam VisualLeak Detektor... nicméně leakynějak neřešim a nechávam je jak jsou (njn..)
_________________
Perry.cz

[Frooxius]

Časté alokování a dealokování na výkon docela vliv má, např. když testovali výkon C vs Java, tak zjistili, že to bylo právě alokací paměti, protože Java má vestavěného správce, který naalokuje větší kus a ten pak rozděluje, zatímco v C to bylo po kousíčkách. Když v C ale použili nějakého správce paměti, tak v rychlosti tu Javu překonal, ve stejném testu.

Taky je třeba vzít v potaz platformu, ze zkušenosti jsou mobilní platformy na toto mnohem citlivější, ale to většinou v nějakém systému s garbage collectorem.

Ale jak říkají ostatní, pokud to jede v pohodě (na nejslabším HW co chceš podporovat), nemá smysl tím ztrácet čas.

Jinak fragmentace paměti není vůbec problém, to řeší na hardwarové úrovni stránkování, pokud tedy zrovna nepíšeš/nekompiluješ pro nějaký procesor, co stránkování nepodporuje.