• ú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 --- ---
    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)
    XCHAOS
    XCHAOS --- ---
    ANT_39: ano, tak já už nějaký čas vím, že bych takto měl se stringy pracovat. moje starší programy to ale obchází, a trapně používají buď MAXLEN buffery na stacku (a nebo MAXLEN alokují). právě že směřuji k tomu, že moje novější C aplikace budou používat vlastní mini-knihovnu se základní funkcí na řetězení a současnou alokaci stringů a jejich následnou efektivní masivní dealokaci (obdoba operátoru + v Pythonu či JavaScriptu nebo operátoru . v PHP)
    REDGUY
    REDGUY --- ---
    A hle, stejne jako Zombie Jesus, po trech dnech vstavam z banu a jsem zpet 8)

    Nejdriv troska offtopic, coz?
    XCHAOS: moderátor občas musí holt poněkud offtopic komentovat počíná ostatních Coz by bylo dobre zduvodneni, kdyby ty tvoje off-topic prispevky byly skutecne moderovani, a nikoliv mentalni masturbace nad vlastni kreativitou, nesmyslne obvinovani oponenta z chybne argumentace, podsouvani oponentovi neceho, co nikdy nerekl nebo blaboleni o smyslu zivota Kdybys skutecne jen moderoval, tak ano, mas pravdu. Coz jsi ovsem nedelal. A pokud off-topicujes uplne stejne jako ja, tak kdyz potom vytahnes moderatoske kladivo, je to proste jen zbabelost (a rekneme "neuprimnost", pokud to vydavas za moderovani). Jen tak do zaznamu 8)

    No, ted ale neco k veci, coz?

    Zakladni vec ktera v cele tehle dbate chybi, je kdyz uz ne analyza, tak aspon zduvodneni:

    - Pro koho ma byt xallokator urcen?
    - Pro co je to urceno?
    - Ma to byt nahrada nebo doplnek stavajicich zpusobu alokace pameti?
    - V cem jsou soucasne zpusoby alokace pameti nedostacne a proc?
    - V cem (a jak moc) chces byt lepsi?
    - Jak dobre to ma fungovat s jinejma knihovnama?
    - Jak to celkove koncepcne zapadne do celeho jazyka?

    Chapu ze kdyz si takhle aspon trochu nadefinujeme co vlastne delame, tak se pozdeji bude mnohem hur vyhybat pripadnym namitkam pomoci ukroku stranou, ale toho uz jsme si driv uzili dost, ne?


    XCHAOS: "tradiční" stringovou gymnastiku v C (ta je prováděna na stacku, tradičně vázaná na nějaké to "MAXLEN" - ne, neni. Ze to tak delas ty neznamena, ze to je obecna tradice.

    A btw, dival ses jak funguje alokace pameti v Objective C, jak uz jsem ti nekolikrat doporucoval? Docela by me to zajimalo - kdyz mi vycitas off-topic prispevky, rad bych vedel jaky efekt maji ty on-topic 8)
    ANT_39
    ANT_39 --- ---
    XCHAOS: Ano, co ti chodi zvenku. Uvnitr programu si to zmeris. MAXLEN nepotrebujes.
    XCHAOS
    XCHAOS --- ---
    ANT_39: tak já to chystám přesně jak říkáš - už mám hotovou funkci get_str(), která změří délku všech svých (1 ... n) argumentů, alokuje prostor a nakopíruje do něj obsah stringu (a toto jsem měl mít už dávno a měla by to být podle mě v C norma).

    zdrojem řetězců náhodné délky je vše: stringy přicházející z textových konfiguráků, z databáze, z webových formulářů... string známé délky je naprosto speciální případ a mimo chráněný svět zdrojového kódu programů a počítačových her se prakticky nevyskytuje.
    MYSHAAK
    MYSHAAK --- ---
    Prosím o pomoc, dokázal by někdo z vás zkompilovat toto pod Windows? https://github.com/spekode/sskey, zkoušel jsem CygWin, MinGW, ale nedaří se mi :(
    ANT_39
    ANT_39 --- ---
    XCHAOS: Rekl bych, ze vetsinou vis, jak dlouhe tve retezce budou, a podle toho si alokujes presne tolik mista, kolik potrebujes. Alokovat MAXLEN a pak doufat, ze se to tam vejde, je nerozum. Vyjimkou je urcite pripad, kdy nacitas retezec nezname delky, a delas prubezne realokace, tam bys pomoci nejakeho MAXLEN mohl hlidat, aby ti mamuti retezec nedosnul masinu.
    XCHAOS
    XCHAOS --- ---
    ISTEVE: tak typicky delší životnost než funkce, ve které vznikají, mají "moje" spojové seznamy (viz předchozí flamewar - ale i navzdory argumentům, které zde padly, je to stále moje oblíbená datová struktura...).

    typickým příkladem dočasné alokace jsou pak různé operace na bázi immutable stringů (ve stylu Pythonu), které pokládám za bezpečnější, než "tradiční" stringovou gymnastiku v C (ta je prováděna na stacku, tradičně vázaná na nějaké to "MAXLEN" se kterým je alokován každý string)
    ISTEVE
    ISTEVE --- ---
    DAVIDOWITCH: ...pokud nebude funkce brat ownership toho co je ji predano jako argument, treba proto ze ocekava delsi zivotnost tech dat nez caller (ala multithreadovy aplikace)...

    ...a to s alloca (jak rika janfrog) nemuze vubec, coz je ponekud vetsi omezeni;]
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Tak s mallocem tohle stejne udelat nesmis, protoze si zahodil pointer a nezvladas free, zeano...
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no tak mě v podstatě ne... ale právě třeba moje makro-zápisy často vedly přesně k něčemu podobnému a byl jsem tady za to dost kritizován...
    Kliknutím sem můžete změnit nastavení reklam