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)

XCHAOS: No, kdybys treba na tom FELu vydrzel do ctvrtyho semestru, byl pomerne peknej predmet o OpenGL.

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.

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í)

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)

XCHAOS: Nasobeni matic neni zdaleka jedina vec, kde ti spatna prace s pameti muze zabit vykon. (*cough* pouzivani spojovejch seznamu misto poli *cough*)

XCHAOS: O grafice si nekdy slysel? Veskery transformace v OpenGL/DX (tj. uplne v cemkoliv co se pouziva) jsou skrze nasobeni matic.

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.

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 :-)

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.

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.

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)

(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 :-))

(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)

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")

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

JACHYMKO: tak matica ma byt deklarovana ako jednorozmerne pole, ale pochopil som uz kde je chyba

JACHYMKO: dik uz je to o nieco lepsie, zacnem ale teda odzaciatku. Pred mesiacom som zacal s programovanim a momentalne mam spravit zadanie:

Vytvořte program ve kterém budete moci za běhu programu zadávat rozměry matice a alokovat a uvolňovat pro ní pamět z paměťové haldy (memory heap) pomocí funkcí malloc a free. Vytvořte demonstrační program, kdy prvky matice inicializujte pomocí náhodných čísel. Celou matici uložte do jednorozměrného pole.

Hned sa priznam, ze som uplne dobre nepochopil ukazovatele a momentalne ten program v podstate funguje ale nahodne cisla sa tam stale po sebe opakuju. Kod:

https://docs.google.com/document/d/1RxiMsD9PFqXI10knibLl5x6O6KuEEWDapRBKONlzNFM/edit?authkey=CLbIhusM

preco do doprdele vracia stale tie iste cisla?

srand((unsigned) time(NULL));
matica[i]= rand() % 100;

docela vypjaté emoce, v tom počítačovém světě...

Dennis Ritchie Day - O'Reilly Radar
http://radar.oreilly.com/2011/10/dennis-ritchie-day.html
Sunday, October 16 was declared Steve Jobs Day by California's Governor Brown .... I don't have the convening power of a Governor Brown, but for those of us around the world who care, I hereby declare this Sunday, October 30 to be Dennis Ritchie Day! Let's remember the contributions of this computing pioneer.