• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    XCHAOSANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Aha, tak to asi nema smysl se o cemkoliv bavit, pokud nemas alespon ramcovou predstavu co vlastne dela malloc.
    XCHAOS
    XCHAOS --- ---
    REDGUY: je to trochu jinak.. právě proto jsem chtěl to flow-control makro forget{ } (jak si zašal prudit, že uvnitř toho není definovaný chování continue a break :-)

    v podstatě jsem si představoval, že ty režimy jsou dva - ale spíše jsou tři, a jen jeden z nich je standardní malloc

    představ si tyhle vnoření

    main { /*alloc=malloc*/ forget { /*alloc=xalloc*/ remember { /*alloc=malloc*/ } } }

    vs.

    main { /*alloc=malloc*/ forget { /*alloc=xalloc0*/ forget { /*alloc=xalloc1*/ remember { /*alloc=xalloc0 */ } } } }

    v podstatě moje myšlenka na promísení forget{ } a remember{ } maker vede ke třem možným stavům (pokud ten top-level očekávaný stav má být malloc) ... a ještě bych to doplnil o nějaké allocate{ } flow control makro, ve kterém by alloc byl vždy malloc().

    tím, že nepřepínám kontexty, ale tvrdě hlídám začátek a konec scope je to zejména vhodné ke strukturám typu

    forget {void *tmp1r=get_něco(), *tmp1r=get_něco() }

    protože se ti naalokovaná paměť na konci místní scope uvolní spolu s definicema těch proměnných, co na ní odkazují. já takto víceméně jednak programovat chci, jednak už vím, jak toho dosáhnu, ovšem jak už jsem citoval Henryho Forda jinde - stěží si vybuduju reputaci na tom, že se to chystám udělat - budu muset jít a udělat to :-) důvod proč jsem to neudělal je prostě ten, že mi některé kombinace nebyly jasné, a že jsem pořád dost tvrdě ignoroval, že jeden z režimů ve kterých se budu chtít pohybovat, by měl natvrdo být "fallback na malloc()" - tedy ta samá moje funkce (postavená na toolkitu) použije malloc() když jí zavolám jen tak z main() bez uvedení další speficikace, ale že naopak použije bleskové memory pooly, když jí zavolám uvnitř svého forget { } scope.

    takže zadání pro sebe mám jasné - nepíšu univerzální náhradu malloc(), ale píšu jakési svoje "get_cosi(...)" či "get(cosi,...), které má jako jeden z režimů malloc(): na uvolňované pointery se může free() v případě, že volající ví, co dělá - typicky se free zavolá na nějaké více "vnější" vrstvě programu.

    další možnost je definovat dispose(), které si zkontroluje, zda pointer neukazuje dovnitř aktuálního memory poolu - a teprve pokud ne, tak na to zavolat free a pokud ano, tak snižovat nějaký vnitřní counter memory poolu až do té míry, že by např. stránka memory poolu obsahující právě jeden záznam byla ozačená jako volná...

    lze si to představit jako trochu sofistikovanější přepínání mezi malloc() a alloca() - s tím, že alloca() není omezené na velikost stacku.

    víceméně vám tohle může připadat jako dlouhé a jako blábol - ale pro mě je to naopak zdůvodnění toho, proč se o tom s někým radím online (a musím přetrpět všechen výsměch a flamewary) - protože se víceméně pořád držím své původní koncepce, ale zahrnul jsem do ní některé docela chytré přípomínky, které tu zazněly. a teď bych asi fakt měl sednout a naprogramovat to :-)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: mě přijde, že ten malloc() je docela rychlej, ale to může záležet na implementaci ... v některý implementaci malloc() může být klidně schovaný volání garbabge collectoru, který hledá volné místo...
    XCHAOS
    XCHAOS --- ---
    ANT_39: to je zajímavý odkaz, ale upozorňuju, že moje (rozpracované) memory pooly nejsou plnohodnotná náhrada obecného alokátoru zahrnujícího zcela obecnou garbage collection... od začátku počítám s tím, že je tam nějaký tradeoff, tedy že něco bude rychlejší - a na oplátku to něco jiného nebude umět vůbec
    REDGUY
    REDGUY --- ---
    XCHAOS: a proc nemuzes kratke stringy a docasne veci drzet na stacku?
    XCHAOS
    XCHAOS --- ---
    ANT_39: no tak s tím reallocem právě moc nepočítám - resp. neumím si to představit. pokud si budeš chtít pole reallocovat, mělo by to být pole alokované v první řadě normálním allocem().

    mám to myšlené hlavně na krátké stringy a různé dočasné obsahy textových souborů či HTTP requestů načtené do paměti... jinak moje oblíbená struktura spojový seznam je s touto metodou alokace kompatibilnější, než právě třeba pole náhodné délky :-) vlastně jste mě moje vize nejvíc rozbili tím, jak jste mě upozornili, že díky cacheování paměti přímo v jádře CPU už nejsou spojové seznamy až tak efektivní, jako byly např. v éře před 15ti lety (kdy se _už_ nedělalo onboard cacheování RAM, ale současně se _ještě_ nedělalo onchip cacheování...)
    REDGUY
    REDGUY --- ---
    JANFROG: ehm. OSX neni slusny system?
    JANFROG
    JANFROG --- ---
    JACHYMKO: Budes se divit, ale je. Protoze pri pocitani referenci, overhead prirazeni je
    - fetch, decrement, store
    - fetch, increment, store

    To je duvod - krom cyklickych referenci - proc se pocitani referenci nepouziva jako garbage collector (ve slusnych systemech)


    REDGUY
    REDGUY --- ---
    kolikrát by si se zdržoval počítáním referencí i ve chvíli, kdy ti je jasné, že paměť o pět řádků dál zase zahodíš - nerozumim. Jak, zdrzoval? Reknu si o pamet, o pet radku dal reknu at se zmensi pocet referenci a pamet se uvolni. Kde je zdrzovani? Mozna bys mel ukazat nejake konrektni use-case kde si myslis ze bude tvuj pristup lepsi, ne?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    Skoro vubec? Alokovat pamet na pet trivialnich radku je samo o sobe podezrely, na pet komplexnich radku te to nezdrzi a tech pet komplexnich radku muze delat veci volnejc.
    XCHAOS
    XCHAOS --- ---
    REDGUY: no ano, já dokonce chvíli vymýšlel, že kdyby se místo = použilo nějaké makro - třeba let( ) - tak by to šlo poloautomatizovat. ale fakt je, že na to prostě kašlu - vezmi si jen, kolikrát by si se zdržoval počítáním referencí i ve chvíli, kdy ti je jasné, že paměť o pět řádků dál zase zahodíš...
    REDGUY
    REDGUY --- ---
    XCHAOS: počítaný reference jsou v C vyloučený, v podstatě. - ale kdeze. Kdyz uz, tak _automaticky_ pocitany reference jsou vylouceny. Normalni pocitani referenci delat muzes zcela bez problemu, akorat se o to musis starat (uplne stejne jako se budes aspon castecne muset starat o alokaci pameti v tvem systemu).
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Nebyla tu uz debata o pocitanejch referencich?
    Shrnu co si pamatuju: Ne, nejsou vylouceny. Ne, nepotrebujes pretizeny operatory. Ano, musis pak delat add/remove manualne. Koukni se na ObjectiveC jak to dela.
    (netreba se o tom hadat, ja svoji pozici nezmenim, ty svoji pozici nezmenis, jen sem to chtel pripomenout).

    To co tu resis je uplne klasickej mempool. Ma to spoustu vyhod (rychla alokace, rychla dealokace), ale jakmile to jednou alokujes, nemuzes to uvolnit jinak nez vsechno najednou. Obal si necim mallocy a zjisti jaky mas bezny access patterns pro svoje planovany pouziti.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: počítaný reference jsou v C vyloučený, v podstatě.

    uvažuju "ukusovat" malé kousky paměti z větších bloků a hlídat jen "kolik ještě zbývá"... a pak zahazovat ty větší bloky najednou.

    spíš nevím, jestli to dělit na "malloc/krátkodobé" nebo "malloc/střednědobé/krátkodobé".
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    Ten handoff pameti by mozna sel udelat tak, ze by pointer mel nejakej flag (ze se nema volat explicitni free) a celej ten memory blok by mel pocitany reference, aby vedel jestli se mu jeste nekde neco necoura... ale je to natolik convoluted, ze bych radsi exekutivne zakazal jakejkoliv handoff.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    Ja mam vzdycky pocit ze mne vic trapi trvani mallocu nez free.
    Protoze pokud mam tendence hodne delat malloc/free pattern, tak se pokusim tu pamet prepouzit (s nejakym reallocem treba).

    Jinak s xallocem bude problem ze nejde udelat handoff pameti (tj. stejnej jako ma alloca). Knihovne vubec ne, a i mimo knihovny to bude prinejlepsim tricky.
    REDGUY
    REDGUY --- ---
    REDGUY: Jenom pro jistotu, aby si to xchaos nevzal nejak extra osobne. Druhej odstavec minuly zpravy bych klidne naformuloval i "... ze vetsina z nas v zivote nepsala ...".
    REDGUY
    REDGUY --- ---
    ANT_39: No presne proto mi prijde rozumne si predem udelat nejakou analyzu soucasneho stavu, aby pozdeji sel zmerit prinos (nebo postih) kterej xallokator prinesl.

    (a radsi vubec nebudu mluvit o tom, ze (a) jsem si na 95% jistej, ze xchaos v zivote nepsal a ani psat nebude prakticky uzivany program, ve kterem by nahrazeni free necim rychlejsim melo pro uzivatele viditelny prinos a (b) pokud nahodou ano, tak ten program lze na 99% urychlit necim jinym vic nez rychlejsim free. Cili ze cviceni "potrebuju bleskovy free" je predcasna a zcela zbytecna optimalizace. Ale budiz, pravo hrat si se zbytecnejma vecma mu nikdy upirat nebudu, naopak 8) )
    ANT_39
    ANT_39 --- ---
    REDGUY: Je fakt, ze free je celkem netrivialni, a nahradit deset volani free jednim by mohlo byt znat. Nehlede na to, ze malloc je taky slozity, kdezto alokace z poolu bude proste posunuti nejakeho interniho citace. (Btw, XCHAOSi, budou pooly umet realloc? Budou umet pooly rust podle potreby?)

    Na druhou stranu, tim ze bude pool velky, tak hrozi, ze ten malloc, nad kterym je postaveny, pouzije ke splneni pozadavku mmap. (Ev. to nebude stavet na mallocu, ale primo na mmapu, to je jedno.) Pamet pridelenou mmapem kernel musi smaznout, coz chvili trva. Takze neni vyloucene, ze nevhodne pouzite pooly vykonnost programu snizi.

    Zkratka, tesim se na detailni vykonnostni analyzu v zavislosti na ruznych workloadech. Kolega o tom psal diplomku, treba by to mohlo byt uzitecne. (Necetl jsem.)
    Kliknutím sem můžete změnit nastavení reklam