• ú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
    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.)
    REDGUY
    REDGUY --- ---
    XCHAOS: nevidím nic špatného na tom mít jako jeden z přepínatelných režimů alokace konzervativní malloc - cili nevidis problem v tom, ze u kazde dynamicky alokovane pameti budes muset navic sledovat, jak jsi alokoval, protoze kdyz neuvolnis pamet alokovanou mallocem, budes leakovat a kdyz uvolnis pamet allokovanou xallocem, dostanes v lepsim pripade core dump, v hosrsim nejaky nahodny poskozeni pameti? To mi neprijde jako zrovna pritulne, jednu vec delat dvema ruznejma zpusobama, ktery kdyz si spletu, dostanu nahodnou, typicky bezprostredne neviditelnou chybu.

    jednoduše si nechci pamatovat, co vše musím na konci dealokovat. - coz mi ale prijde ze tvuj pristup neresi, jen to komplikuje - prijde mi, ze "nekterou pameti musim odalokovat a nekterou ne" je _slozitejsi_ nez "vsechnu pamet musim odalokovat".

    A jak myslis ten "prepinatelnej rezim"? Jako nejakej globalni stav, podle kteryho se vybira zpusob alokace?

    a dealokace by navíc byla blesková - jak dlouho podle tebe trva normalni free a proc to nepovazujes za bleskove?

    s jinejma knihovnama by to mělo fungovat tak, že o tom nebudou věddět: - coz jenom pokracuje v problemu z prvniho odstavce.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no, čirou náhodou jsem hned v předchozím příspěvku [ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] jsem svůj záměr vysvětlil...

    ANT_39: asprintf() znám a líbí se mi... až na to, že nechci záviset jen na mallocu(). vlastně ano... u toho svého get_str() (či jak se to bude jmenovat) plánuju ještě mutaci get_str(), která se bude lišit tím, že místo prostého řetězení se použije první parametr jako formátovací string pro sprintf()... jde čistě jen o to, že nechci záviset na malloc(), protože si nechci pamatovat na které všechny pointery bude nutné ručně zavolat free().

    REDGUY: dobře, tak aby si neřekl:
    REDGUY: ...odpovědi na zbývající otázky:

    - nevidím nic špatného na tom mít jako jeden z přepínatelných režimů alokace konzervativní malloc() - a použít ho např. když budu chtít implementovat ve svém toolkitu nějakou veřejnou knihovní funkci a alokovat konzervativním způsobem prostor pro její návratovou hodnotu. nicméně chci mít možnost triviálním způsobem přepínat ještě minimálně mezi dvěma dalšími způsoby alokace, u kterých bych tak či onak nemusel volat free() - a dealokace by navíc byla blesková (tedy, i ta alokace - což mimochodem taky chci přesně proměřit, jestli zvládnu více alokací za sekundu, než malloc())

    - v čem jsou přesně nedostatečné? jednoduše si nechci pamatovat, co vše musím na konci dealokovat. často používám několik "dočasných proměnných" (například pointeru na stringy), jejichž obsah se průběžně mění pomocí aktuální situace - a na konci prostě už nevím, co vše jsem alokoval, na co chvíli ukazovaly. nechci pro 10 po sobě jdoucích aktivit deklarovat deset různých jednoúčelových proměnných jen proto, abych je na konci mohl dealokovat. nechci ani manuálně dealokovat po každé alokaci, apod.

    - jestli chci být v něčem nejlepší, to je zajímavá otázka :) chci být nejlepší v uživatelské přítulnosti pro moje vlastní použití. tedy je to v podstatě forma programátorské onanie - na čemž ovšem nevidím nic špatného :-)

    - s jinejma knihovnama by to mělo fungovat tak, že o tom nebudou věddět: nechci jim podsouvat jinej "univerzální" malloc() - chci jen sám občas použít něco jiného než malloc(), když to uznám za vhodné.

    - jaká je v případě C "koncepce celého jazyka", to je velká otázka - např. ostatní moje makra jsou obecně speciálním případem věcí jako va_args() (což je taky dost bordel, ale současně i součást "koncepce").

    C obecně rozlišuje "lokální" a "globální" - jedna možnost je, že každá další funkce by podle měla implicitně alokovat s využitím globální alokační funkce, dokud není definován lokální override. a nebo může funkce pokačovat dle aktuálně nastaveného kontextu - pokud si výslovně neřekne, že chce něco dělat jinak...

    v krajním případě by alokační strategie mohly být jen dvě: "chci malloc" (včetně toho, že si ručně zavolám) a "chci zapomenout vše alokované odsud až podsud". já celou dobu žiju v domění, že je praktické vymýšlet ještě nějakou "třetí cestu", ale možná je to overkill.
    REDGUY
    REDGUY --- ---
    XCHAOS: a další debata o tom "pro koho a proč" je podle mě v tomhle klubu offtopic. - obavam se ze jsi nepochopil proc ty otazky kladu. Jejich smyslem neni zjistit "jestli" to delat, ale "jak" to delat. Pokud si ani tohle neujasnis, narazis po ceste na velke problemy. Ostatne, uz jenom z te jedne zpravy je videt krapet problem: na jedne strane chces univerzalni alokator pro vsechny svoje aplikace, na druhe strane chces "pruzkum technik, bez debat proc by to nekdo chtel delat". Zakladni vyzkum a aplikovany vyzkum jsou dve ruzne veci a delat oboje soucasne mi prijde jako docela spatny napad. Jestli chces nahradu mallocu, mel bys bejt schopnej aspon rict co konkretne je na mallocu spatne. Ne proto ze te s tim otravuje nekdo na nyxu, ale proto abys nakonec poznal jestli se ti to podarilo nebo ne. Jestli chces zkoumat techniky, je dobre zacit tim podivat se jak to delaji ostatni. Co si kuprikladu myslis o tom, jak funguje alokace pameti v ObjC? 8))

    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Jezismarja to je TAK arogantni odpoved ze sem to ani od tebe necekal...
    A naproste nepochopeni otazky..

    To zes redguye po svejch offtopic vylevech zabanoval mne uz ani neprekvapuje, jelikoz zacnes kricet offtopic kdykoliv se ti to hodi.. ale ze vcetne otazek jako "jake je planovane pouziti daneho konstruktu"...
    ANT_39
    ANT_39 --- ---
    XCHAOS: Jestli ti nevadi zaviset na GNU rozsirenich, tak asprintf je jako sprintf, ale buffer si alokuje sam na halde, a pak do nej retezec nakopiruje. Konkatenace by pak byla proste asprintf(&buf, "%s%s%s%s", str1, str2, str3, str4);
    XCHAOS
    XCHAOS --- ---
    REDGUY: připomínky jsou to dobré. odpovím ti stručně (přeci jen je neděle) na tvoje první dvě otázky:

    - alokátor má být určen především pro mě (a dále pro lidi, co se mnou budou chtít spolupracovat)
    - alokátor bude použit ve všech příštích userspace aplikacích, které plánuji v C vyvíjet

    je to podle mě dostačující vysvětlení, které má právo uvést kdokoliv u všech svých dalších dotazů na jakouliv feature jazyka C, kterou v tomhle klubu vznese. Doufám, že je to nyní jasné - a další debata o tom "pro koho a proč" je podle mě v tomhle klubu offtopic. budeme se zde bavit o naprosté jakékoliv (jakkoliv technicky nesmyslné) feature jazyka C - včetně hledání všemožných bezpečnostních děr typu buffer overrun a stack insertion i debat, jak jim zamezit - a nebudeme se prosím bavit proč by toto někdo chtěl zneužít nebo se proti tomu bránit.

    prostě mě zajímá průzkum co nejširší možné množiny programátorských technik, které se týkají čistého jazyka C (a to konkrétně na úrovni předposlední specifikace C99, která mi vyhovuje více, než předchozí norma C89, na které jsem vyrůstal) - a nebudeme ztrácet čas debatami, kdo a proč by mohl chtít něco takového dělat (případná snaha o účast v "C obfuscated code contest" je dostatečný argument, kterým lze argumentovat na zcela jakoukoliv námitku)
    Kliknutím sem můžete změnit nastavení reklam