• ú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 --- ---
    REDGUY: což nedělám (resp. problém vznikne, pokud něco zmíním bez uvedení zdroje, a dvacet lidí se zeptá "a to si vzal kde?" a já musím zpětně hledat, kde to na té wiki bylo).
    REDGUY
    REDGUY --- ---
    XCHAOS: Ne, xchaosi. Kdyz jako "zdroj" napises ctyri pismena "wiki", bez nejakeho linku, jsi trouba. Stejne jako kdyz nedokazes vygooglit tutorial na pouzit matic 8)

    A btw, neni zac.
    XCHAOS
    XCHAOS --- ---
    XCHAOS: tedy dvě jediné abstrakce, chci říct :-)
    XCHAOS
    XCHAOS --- ---
    REDGUY: ... zato když jako zdroj uvedu wikipedii, tak jsem amatér, že :-)
    XCHAOS
    XCHAOS --- ---
    jako jo, s polem pointerů na objekty (indexem) se dají dělat téměř stejně pěkné věci, jako se spojovým seznam. myslím, že nejlepší protipříklad, který jsem uvedl, je vložení nového prvku poblíž začátku setříděného seznamu (a naopak u jednosměrného setříděného spojového seznamu má podobně brutální režii vložení prvku poblíž konce)

    odtud se dobereme k tomu, že vyšší jazyky typu Python, které nabídnou uživatelům jednu jedinou abstrakci dynamického kontejneru (pole proměnné délky a "slovník"), asi nebudou na některé věci úplně ideální: resp. bude dobré si u nich změřit, jak rychlé je přidávání prvku na začátek vs. na konec dlouhého pole, apod.

    a zejména zajímavé téma je otázka správy paměti pomocí reference counterů použitého u spojového seznamu objektů... z toho by mohl myslím být docela dobrý nový flejm :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: ale nějak si mě pořád nepřesvědčil, že spojový seznam není výhodný nikdy, za žádných okolností. - to myslim uzce souvisi s tim, ze jsem se nikdy o nic podobneho nesnazil, protoze to je pitomost.

    typicky jsme opět u toho, že když víš kolik toho bude, tak je pole docela výhodná struktura. - uhm. To neni pravda. Ve spouste pripadu predem vim "kolik toho bude" a presto je pole spatna struktura a naopak, ve spouste pripadu nevim kolik toho bude a pole je dobra struktura.

    abstrakce kterou nabízí spojové seznamy může mít nezanedbatelné výhody - ano, muze.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Ja musim do prace, ale kdyz si vygooglis OpenGL transformations, tak urcite najdes pekny vysvetleni.
    Pripadne koukni do moderni pocitacove grafiky 2, tam je v zadu appendix o matice v grafice
    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 :-)
    Kliknutím sem můžete změnit nastavení reklam