• ú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 --- ---
    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 ] )
    KEYMASTER
    KEYMASTER --- ---
    +1
    já si dovolím odvážně tipnout, že ten overhead sčítání bude neměřitelnej proti tý branch misprediction...
    JANFROG
    JANFROG --- ---
    2 odpovědi+1
    Dovolim si mirny oftopic :-) Sem tam se sem podivam a nemuhu se zbavit dojmu, ze nekteri lide proste nevynechaji jedinou moznost XCHAOSe insultovat. Nerikam, ze s XCHAOSem souhlasim, nekdy mam pocit, ze je hodne mimo, ale...

    REDGUY: komu se to nikdy nestalo, necht hodi kamenem!

    K optimalizacim GCC: jak pravi klasik, kdo pouziva -O2 a si musi hodne verit a -O3 uz je hazard :-) Prikladny vyklad asi nikdo neda, nebot myslim, ze nikdo moc nevi co se v GCC deje
    REDGUY
    REDGUY --- ---
    1 odpověď
    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?
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    REDGUY: ne, vy mě ukážete. já vám ukázal, že s -O3 se to chová jinak :-) teda na 64bit CPU.
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    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.
    REDGUY
    REDGUY --- ---
    1 odpověď
    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)
    REDGUY
    REDGUY --- ---
    1 odpověď
    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?
    XCHAOS
    XCHAOS --- ---
    2 odpovědi
    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? :-)
    REDGUY
    REDGUY --- ---
    +3
    XCHAOS: příkladný výklad toho, co dělá -O3 místo použití té ASM magie, by mě taky zajímal.: njn. To uz rovnou muzes chtit aby ti nekdo vysvetlil jakej je rozdil mezi vznetovym a zazehovym spalovacim motorem aniz by pri tom pouzil magicka slova "horeni", "valec", "pist" a "svicka".
    REDGUY
    REDGUY --- ---
    1 odpověď
    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.
    ISTEVE
    ISTEVE --- ---
    XCHAOS: Ber to jako prilezitost pro studium :)
    XCHAOS
    XCHAOS --- ---
    2 odpovědi
    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.
    REDGUY
    REDGUY --- ---
    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?
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    (odpovím si sám: po změně seedu jsou výsledky úplně stejné. a tartarus jsem radši přejmenoval na tartaros ... římský militarismus mi není blízký, to už jsou lepší klasičtí řečtí sofisté, ze kterých si řada online diskutérů bere příklad dodnes)
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    KEYMASTER: a sakra, vida... :-)

    REDGUY: hele... jak to tedy doopravdy je, s tím ovlivněním benchmarku tím, že ta čísla pro jistotu budou stejná ? :-))
    KEYMASTER
    KEYMASTER --- ---
    1 odpověď+4
    jo, protože jinak by se mohly náhodně vygenerovat čísla s moc bity, a pak by sčítání trvalo dýl :D
    XCHAOS
    XCHAOS --- ---
    REDGUY: no, tak myslím, no.
    REDGUY
    REDGUY --- ---
    2 odpovědi
    XCHAOS: seeduje to pořád tím samým Coz je zcela umyslne, protoze u benchmarku mi to prijde jako velmi vhodne, nemyslis?
    REDGUY
    REDGUY --- ---
    DAVIDOWITCH: ad ten XOR reg, reg; Tohle je presne duvod, proc je celej x86 a compatible v prdeli. - jo, to me vzdycky pobavi, ta predstava ze soucasny nekolika GHz hyperthreadovy multijadrovy superpipelinovany x64 procesory jsou s primhourenim oci kompatibilini jeste s prastarou 8008 8)
    Kliknutím sem můžete změnit nastavení reklam