• ú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 --- ---
    DAVIDOWITCH: To maskovani funguje jak? Na pristi instrukci, pristi store, dokud ho nevypnu, nebo jinak?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    REDGUY: Jako, je husty jak mi tohle vubec nedoslo, protoze ted programuju pro GPU a tam se takovyhle maly tela resej maskovanim.
    tj. if by jen nastavil predikat jestli zapsat vysledek nebo ne, a tudiz skok by vubec neprobehl (to samy bych delal v SIMD)
    REDGUY
    REDGUY --- ---
    DAVIDOWITCH: Rekl bych ze jo. Navic stejnej efekt je udajne videt i v Jave.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    (ne, necekal sem to, myslel sem ze to bude opacne)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    REDGUY: Tyjo, ze by se tohle CELY dalo svyst na branch prediction?
    REDGUY
    REDGUY --- ---
    Hehe, tohle je docela legracni. Sice se desim ze si z toho XChaos vezme uplne spatne pouceni a bude z toho zase zaplava jeho zmatecnejch vizi, ale je to tak zajimavy ze to risknu:

    [C] WTFC - Pastebin.com
    http://pastebin.com/E2vHyXjU

    Cckovej program kterej vygeneruje pole nahodnejch cisel a pak ho mnohokrat projizdi a pocita soucet tech nahodnejch hodnot, ktery jsou vetsi nez RAND_MAX/2. Na zaver rekne jak dlouho mu to trvalo. Nic slozityho. Jedina vec zajimava vec je, ze pokud mu na prikazove radce reknete "WTF", tak predtim, nez to pole zacne projizdet a scitat ho setridi, coz na vysledny soucet nema zadnej vliv.

    Za domaci ukol se na ten kod podivejte a zkuste si odhadnout, jak se bude vysledny cas lisit v zavislosti na tom, jestli tomu programu reknete nebo nereknete "WTF". Pak si to vyzkousejte a uvidite 8)
    XCHAOS
    XCHAOS --- ---
    ANT_39: dík, to jsem možná teď napodruhé přehlédl, už jsem to ale měl nastudovaný... řetězící alokátor get_str() a formátující alokátor get_strf() u mě každopádně budou hlavní stringové nástroje (začal jsem diplomaticky používat označení "můj toolkit", protože cokoliv jiného působí jako rudý hadr :-)

    (jo a připomínám, že rozhodně nečekám reputaci, dokud to nereleasnu...)
    NECROMAN
    NECROMAN --- ---
    Dokazal byste nekdo prekompilovat Cckovou knihovnu LUA do WinRT / C++ ? WinRT jak asi vite je novy runtime ve Windows 8 pro beh Metro aplikaci. Lze v nem programovat pomoci C++, C# nebo HTML5/JavaScriptu.
    Pro zkusene C++ matadory by to predpokladam nemel byt takovy problem, neni tam skoro nic platform-specific, jen obecne algoritmy :)
    Dik
    LUA library compiled in WinRT C++
    http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/f4621710-2cdf-4fc5-a04e-44ecb25c6769
    ANT_39
    ANT_39 --- ---
    XCHAOS: ten asprintf se da naemulovat celkem trivialne, pustis vsnprintf(NULL, 0) abys zmeril, kolik to potrebuje, alokujes bafr dane delky + 1, a pak podruhe vsprintf(buf).
    REDGUY
    REDGUY --- ---
    XCHAOS: něco, co se použije místo malloc() když programátor uzná za vhodné - jen tak pro kontrolu, vis ze malloc sam o sobe je dost chytrej a jaksi kondenzuje zkusenosti a znalosti spousty programatoru? A cilem tveho pry na uziti jednodussiho alokatoru je tuhle chytrost zahodit a nechat na programatorovi at premejsli co pouzit? Chapu to spravne?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Ja chtel rict, ze i uplne obycejnej vanilla malloc co se provede kdyz proste vemes gcc a udelat malloc, je zatracene draha sranda.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: tak minimálně je to obvykle ta funkce, která se nahrazuje, když místo běžného malloc() použiješ nějaký složitější, s nějakým sofistikovanějším GC... takže tady jsem neměl na mysli ten konkrétní standardní, ale mluvil jsem "co se děje na místě, kde se volá malloc()" - kde můžou být použité různé implementace správy paměti, které lze srovnávat, viz [ ANT_39 @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ]

    když se použije místo standardní správy paměti nějaká sofistikovanější, tak se pak nahrazuje i volání toho malloc() voláním jiné knihovní funkce (ať už to řeší pomocí #define nebo prostě tak, že jen použiješ jiný header file a samotná funkce se jmenuje stejně... ).

    jinými slovy se chci dobrat k tomu, že "každý malloc() dělá něco jiného" - a můj projekt pak není v kategorii "1000+první náhrada za malloc() implementovaná jako diplomka" (které další diplomky mezi sebou co nejobjektivněji porovnávají", ale spíš v kategorii "něco, co se použije místo malloc() když programátor uzná za vhodné".
    XCHAOS
    XCHAOS --- ---
    ANT_39: resp. srovnáním jeho výkonu. no, u mě by ten výkon přeměřit dost dobře nešlo, protože je to určené jen na speciální použití...

    ANT_39: no já tak trochu předpokládám, že si načtu nějaký ten get_rlimit a vyjdu třeba z velikosti stacku jako základní jednotky pro alokaci...

    (taky je zajímavé zvolit vhodnou strategii pro tu formátovací alokaci ve stylu asprintf - viz man sprintf - dělá se to pomocí jakéhosi vsnprintf a víceméně se zkusmo testuje, jestli se do řetězce dané délky vejde...)
    ANT_39
    ANT_39 --- ---
    XCHAOS: Ta diplomka se nezabyva garbage kolekci, ale klasickyma alokatorama.
    ANT_39
    ANT_39 --- ---
    XCHAOS: Tak mohl bys povolit realloc vrchniho chunku, ale zalezi, jestli tam bude operace free pro jednotlive chunky (musel by sis nekde drzet delku tech jednotlivych bloku).
    JANFROG
    JANFROG --- ---
    REDGUY: :-) OSX (resp. ObjC runtime) nemuze pouzit nic lepsiho nebot nezna strukturu dat. Navic, co neresi cyklicke reference nepovazuji za GC.

    Dalsi problem pocitani referenci co si malo lidi uvedomuje je ze vicevlaknovych aplikacich je treba zvusit counter pri kazdem predani parametru funkci a snizit kdyz volani skonci.
    To to take dost prodrazi...
    REDGUY
    REDGUY --- ---
    XCHAOS: Nevim jestli to chapu spravne, ale ty planujes mit jednu alokacni funkci, ktera na zaklade nejakeho globalniho stavu bude delat dve nebo tri zasadne ruzne veci? To je imho velmi spatne.
    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...
    Kliknutím sem můžete změnit nastavení reklam