• ú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
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: naopak... když už si zmínil to vynásobení matic, tak bych právě hrozně rád viděl nějaký kus kódu/algoritmus, který to reálně používá a je k něčemu užitečný...
    XCHAOS
    XCHAOS --- ---
    REDGUY: typicky jsme opět u toho, že když víš kolik toho bude, tak je pole docela výhodná struktura. ale nějak si mě pořád nepřesvědčil, že spojový seznam není výhodný nikdy, za žádných okolností.

    většina algoritmů, se kterými pracuji, se točí kolem dvou hlavní požadavků na přístup k datům: 1) nalézt prvek splňující určitá kritéria 2) procházet všechny prvky. víceméně neuvažuju tak, že bych měl datové struktury navržené tak, že vyžaduju přístup k n-tému prvku: a pokud seznam obsahuje odkaz do jiného seznamu, tak zase spíš použiju přímo pointer na prvek seznamu než index (mj. mi to umožňuje udržet integritu dat i při setřídění kteréhokoliv z těch seznamů podle libovolných kritérií).

    Výkonnostní výhody polí v prostředí kdy CPU nabízí onchip cache chápu... ale současně trvám na tom, že abstrakce kterou nabízí spojové seznamy může mít nezanedbatelné výhody zvlášť pokud máme více složitějších, vzájemně provázaných datových struktur.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: No, tak to asi ne. V tom pripade bych to pouzil jako jasnou ilustraci toho, ze to ze nejaka vec co te v matice ucej neni okamzite a jasne patrna jeste neznamena ze to za 2-3 roky nebude superdulezitej kus pocitacovejch ved. (disclaimer: jakozto hardwarar + grafik muzu mit na tohle nestandardni nazor)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: kdybych tam vydržel hned po gymplu, psal by se rok 1994 (resp. 1995, kdybych býval opakoval první ročník, což se mi nechtělo ale možná bych to i dal, těžko říct). popravdě, myslíš že v roce 1994 by mě učili OpenGL? (možné to je, těžko říct)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: No, kdybys treba na tom FELu vydrzel do ctvrtyho semestru, byl pomerne peknej predmet o OpenGL.
    REDGUY
    REDGUY --- ---
    XCHAOS: A uz jsme si taky vysvetlili, ze realloc se provadi pomoci prehozeni stranek pameti jen nekdy, typicky kdyz mas ty pameti fakt velky kusy. A co se rezie tyce... no, to dost zalezi na konkretnim problemu, nez aby bylo mozne rict co ma podstatne vetsi rezii, ze.
    XCHAOS
    XCHAOS --- ---
    REDGUY: no... já jsem začínal s programováním v éře, kdy CPU neměly (AFAIK) prakticky žádnou onchip cache - ale naopak alokování tak velkého pole, kvůli kterému se část RAM odswapovala na disk, mohla program spolehlivě zabít a uvrhnout celý systém do mnohaminutového chroustání.

    už jsem si myslím vysvětlili, že realloc() provedený pouze pomocí přehození pořadí stránek paměti pokládám za vcelku elegantní řešení. (pokud jsem realokaci pole prováděl já "ručně", tak to znamenalo kopírovat poměrně velké kusy paměti, což tedy mělo podstatně větší režii, než nějaký rozdíl mezi rychlou/pomalou pamětí)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: jo... asi mě někdo zapomněl naučit, jak se dělá 3D grafika pomocí násobení matic :-) (nebo jinak: ačkoliv jsem v tom věku běžně programoval v C, tak se kladl velký důraz na to, naučit mě násobit matice tužkou na papíře - ale menší důraz na to ukázat, k čemu je to dobré - pokud tenhle klub ten deficit napraví, nebudu se vůbec zlobit)
    REDGUY
    REDGUY --- ---
    XCHAOS: Nasobeni matic neni zdaleka jedina vec, kde ti spatna prace s pameti muze zabit vykon. (*cough* pouzivani spojovejch seznamu misto poli *cough*)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: O grafice si nekdy slysel? Veskery transformace v OpenGL/DX (tj. uplne v cemkoliv co se pouziva) jsou skrze nasobeni matic.
    ANT_39
    ANT_39 --- ---
    XCHAOS: Asi tak tri roky zpatky tu ALMAD poprve posilal link na drepperuv paper o cachich. (Potom to tu probehlo jeste tak trikrat.) Porad jeste to stoji za precteni.
    XCHAOS
    XCHAOS --- ---
    ISTEVE: jj, chápu. akorát že pro mě je častější zadání "pracuju s něčím, čeho nevím při startu programu, kolik toho přesně bude", než že bych násobil matice (popravdě, toto je přesně věc, kterou mi ve VŠ matice nikdy nenaučili: do zblbnutí mě pokaždé v nižších ročnících nutili násobit matice nebo - jinak s nimi operovat - samozřejmě ručně, co na tom, že jsem takový program uměl napsat už div ne na základní škole, který by to dělal - ale nikdy mi nevysvětlili, k čemu je to dobré v praxi :-)
    ISTEVE
    ISTEVE --- ---
    XCHAOS: Zkus si nasobeni matic (takovy to "radek krat sloupec"). Pak si zkus nasobeni matic s tim, ze si tu matici kterou bych prochazel po sloupcich transponujes. Zmer rozdil.
    XCHAOS
    XCHAOS --- ---
    Tenhle klub jsem právě zakládal proto, aby člověk co se cítí doma v C (tedy je třeba si sám ochoten řešit správu paměti, nebo aspoň přemýšlení o ní - a tedy řeší např. co se mu doopravdy vejde do paměti a u čeho naopak hrozí, že mu to na slabším stroji (nebo při větším množství paralelně spuštěných procesů) vyswapuje na disk, mohl nahlédnout odbočky na nižší i vyšší level: nižší level znamená zrovna třeba přihlédnout k propustnosti sběrnice a optimalizovat směrem na cacheování uvnitř CPU - a ten vyšší level je zase poohlédnout se po sofistikovanějších abstrakcích, které nabízí různé vyšší jazyky a ukázat, jak by se srovnatelná funkce dala implementovat v C.
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: jako právě tohle je level optimalizací, na který já jako "čistý céčkař" (ale ne assemblerista) už běžně nedohlédnu (stejně jako uživatel vyššího jazyka nedovede posoudit, jak mu ten jazyk zvyšuje režii oproti třeba právě C)
    XCHAOS
    XCHAOS --- ---
    (jinak souhlasím s id JACHYMKO, že matici je asi moudré v C reprezentovat jako vícerozměrné pole, protože ta architektura je rovnou navržená aby to bylo stejně efektivní, jako vypočítat si ze souřadnic index v nějakém jednorozměrném bufferu.... u vyšších jazyků to z různých důvodů nemusí být pravda - např. by tam mohl dvakrát volaný nějaký kód pro kontrolu zda indexy nepřekračují hranici pole, apod. - nechci rozpoutat flejm, jak to na které architektuře je jak moc optimalizované... ale zrovna nad implementací vícerozměrných polí v jazycích připouštějících re-alokaci pole za chodu a /nebo kde je dvourozměrné pole implementované jako kontejnerový objekt obsahující jiné kontejnerové objekty bych se klidně s chutí zasmál :-))
    XCHAOS
    XCHAOS --- ---
    (asi to hodím do záhlaví, resp. přečtěte si man highlight, ono to toho umí daleko víc... troufám si říct, že i víc, než pastebin... a výstup lze snadno inlineovat)
    XCHAOS
    XCHAOS --- ---
    k tomu jak sem pastovat fragmenty zdrojů (nejen Cčkových) ... toto je tak napůl posixové/unixové/linuxové fórum, takže:


    apt-get install highlight
    echo "for(i=0; i<n; i++) { printf("%d\t", matica[i]); if ((i+1)%cols==0)" | highlight -S c --inline-css


    výsledek:
    for(i=0; i<n; i++) { printf(%dt, matica[i]); if ((i+1)%cols==0)


    (poznámka: NYX vyžaduje vyhodit z vygenerovaného inline CSS na začátku atribut "font-family")
    LUDO
    LUDO --- ---
    JACHYMKO: tak teraz mam ten vypis takto a funguje to

    [C] for(i=0; i<n; i++) { printf("%d\t", matica[i]); if ((i+1)%cols==0) { - Pastebin.com
    http://pastebin.com/muXqtX9c
    LUDO
    LUDO --- ---
    JACHYMKO: tak matica ma byt deklarovana ako jednorozmerne pole, ale pochopil som uz kde je chyba
    Kliknutím sem můžete změnit nastavení reklam