XCHAOS: no, nečetl. chjo. Co dodat. Dokonce i kdyz ve zprave primo tobe urcene napisu link na podrobne a srozumitelne vysvetleni nejakeho jevu, tak se ani neobtezujes si ho precist a misto toho spradas vlastni, samozrejme mylne teorie.

Do prdele prace, jeste se mi nekdo divi ze jsem na XChaose hnusnej?

REDGUY: no, nečetl. teď koukám, že to "With O3, both versions (sort/non sort) are the same speed (4.5) but with O2, both are differen" píší i tam... takže je to napadlo zkusit taky.

XCHAOS: můžeš tady zpovídat ostatní, jestli to pochopili. - ja te nezpovidam. Ja mel proste dojem, ze duvod proc se ten program chova tak jak se chova uz tady byl velmi dobre vysvetlen, minimalne v tom linku na stackoverflow co jsem sem daval (cetl jsi ho?) a vsichni pritomni tomu rozumi. Takze ted me mate, kdyz najednou mluvis o nejake onchip cache, ktera s tim nema nic spolecneho. Jestli nechces vedet proc se to chova jak se to chova, staci rict.

JANFROG: klub vznikl totiž tak, že jsem před lety dostal ban v klubu o C++ ... důvody si už přesně nepamatuji, ale chtěl jsem ukázat, že to jde i bez (trvalých) banů, a navíc čisté C pokládám za více srozumitelnější pro "začátečníky" (rozuměj: lidi,kteří dosud nic nekompilovali, ale třeba jen skriptovali v PHP apod. - i když třeba i hodně rozsáhlé projekty), než C++ se všemi se všemi jeho romantickými zákoutími a pětihvězdičkovými turistickými atrakcemi.

JANFROG: Guilty as charged. Na moji obranu budiz receno, ze podobny veci predvadi prilis casto a ze v tomhle konkretnim pripade neslo ani tak o preklep ve velikosti pismenek, ale ze se nezamyslel nad tim, proc mu to dava stejnej vysledek (dve setiny sekundy jsou v tomhle kontextu "stejne") a proc o tom s D. mluvime jako o necem zajimavej. Ale jo, mas pravdu. Byt to s nekym jinym, s kym mam lepsi zkusenosti, jsem milejsi, prijemnejsi a slunickovatejsi 8)

REDGUY: no.. min. jestli se použije ta mýtická instrukce, tak s -O3 se nepoužije... na 32bit platformě se taky nepoužije.

hele, mě je to jedno. můžeš tady zpovídat ostatní, jestli to pochopili. na mě je čtení ASM moc lowlevel... nicméně k testování svých různých "minioptimalizací" na úrovni použitých algoritmů jste mě donutili testovat to proti různým -O switchům už dříve.

jinak ladění přepínačů compileru je koukám zábava pro pokročilé...podobného typu jako vymýšlení klíčů do SQL tabulek :-)

XCHAOS: já vám ukázal, že s -O3 se to chová jinak - a my ti uz taky rekli proc [ DAVIDOWITCH @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] )

XCHAOS: Pockej, ty porad jeste nevis proc ten test dava ruzne vysledky? Ja myslel ze uz se to tady dostatecne vysvetlilo? Proc do toho tahas nejakou cache?

REDGUY: ne, vy mě ukážete. já vám ukázal, že s -O3 se to chová jinak :-) teda na 64bit CPU.

REDGUY: no... prostě se sčítají čísla. nemůže hrát roli to, že když jsou blízko sebe, tak se v některých režimech projeví onchip cache - prostě že se rychleji tahají z paměti? ne, to je blbost. blízko sebe jsou furt.

XCHAOS: napíšeme druhý test, zda se různě velká čísla sčítají stejně rychle? to veru nepotrebuju benchmarkovat, to vim. Ale jestli chces, klidne si to napis, rekl bych ze je cca 30% sance ze nejdriv dostanes vysledky ktere budou vypadat ze potvrzuji tvoji predstavu o ruzne delce scitani a pak ti ukazeme, ze to byla jen nejaka optimalizace prekladace. Coz by mohla bejt docela zabava 8)

XCHAOS: měří se čas, ne součet. - meri se cas dvou ruznych behu jednoho programu. Kdybys generoval skutecne nahodna cisla, v kazdem behu by se jich scitalo ruzne mnozstvi, na coz by se spotrebovalo ruzne mnozstvi operaci, tudiz by srovnani nemelo smysl (tedy, melo, protoze ten pocet by se lisil max o pul procenta, ale uvazujme teoreticky).
Precetl sis ten testovaci program? Vis co se v nem deje? Vsiml sis ze se nescitaji VSECHNA nahodna cisla v tom poli, ale jen NEKTERA?

REDGUY: měří se čas, ne součet. resp. rozdíl času. relativní. tento relativní rozdíl je stejný.

(dokud se neshodneme, co bylo vlastně měřenou veličinou, je dost nesmysl bavit se, zda jsou výsledky stejné, nebo ne)

...a jak je to teda s tím benchmarkováním sčítání? napíšeme druhý test, zda se různě velká čísla sčítají stejně rychle? :-)

XCHAOS: po změně seedu jsou výsledky úplně stejné. - ne, nejsou. Vysledny soucet je jiny 8), stejne jako pocet scitanejch cisel.
Ale samozrejme, vzhledem k tomu kolik tech nahodnejch cisel generuju, tak ruzne seedy nemaji nejak zasadni vyznam. Co jsem si prave vyzkousel, tak pocty scitanej cisel se pro ruzne seedy lisi max o cca 0.6%, coz bude asi pod chybou mereni.

Cili prakticky vzato, ten seed neni potreba. Teoreticky vzato tam ale patri. A tech par pismenek me nezabije.

XCHAOS: Ber to jako prilezitost pro studium :)

ještě co mi nejde na rozum, že s tím -O3 jsou fakt výsledky pro setříděné i nesetříděné pole nejen stejné - ale v obou případech o polovinu pomalejší, než to sčítání setříděného pole s -O2 :-) příkladný výklad toho, co dělá -O3 místo použití té ASM magie, by mě taky zajímal.

XCHAOS: Moment, ted nerozumim na co se ptas. Resp, mozna rozumim, ale prijde mi to tak trivialni otazka ze se mi nechce verit 8)

Opravdu se ptas proc generuju ta cisla pokazdy stejny? Nebo je to jen nejakej vtip co mi unikl?