Hlavní navigace

Názor k článku Fraktály v počítačové grafice X od Pavel Tišnovský - Je pravda, ze ja jsem se o architekturu...

  • Článek je starý, nové názory již nelze přidávat.
  • 3. 1. 2006 9:10

    Pavel Tišnovský
    Je pravda, ze ja jsem se o architekturu modernich procesoru prestal zajimat uz od Pentia - o nem jsem jeste prelouskal par clanku venovanych optimalizacim, ale potom jsem si uvedomil, ze nebudu mit cas a chut provadet rucni optimalizaci pro jednotlive pipeliny (je to taky zbytecne, protoze kazda nova generace procesoru je v tomto odlisna). Od te doby jsem prakticky na assembler nesahl :-|

    Pravda je, ze pokud prekladac cecka preklada podle normy, mel by vysledek kazdeho vyrazu prevest na dany datovy typ, v nasem pripade z extended na doubly, coz opravdu muze vypocet zpomalit (dalsi vysledky jsem uvedl nize).

    Ano, obecne vim, jak funguje JIT (samozrejme ne do hloubky, ale unroll-loops apod. je mi jasne), ale stejne byl ten vysledek pro "java -server" nejaky divny. Posilam vysledky dosazene na jinem (lepsim) stroji, ale zvedl jsem pritom pocet iteraci na desetinasobek:

    c-neoptimalizovane (gcc)
    time 1: 187.000
    time 2: 151.000

    c-optimalizovane (gcc -O3 -march=pentium)
    time 1: 143.000
    time 2: 143.000

    c-optimalizovane (gcc -O3 -funroll-all-loops -march=pentium)
    time 1: 145.000
    time 2: 144.000
    [^ kupodivu pomalejsi nez predchozi]

    c-optimalizovane (gcc -O3 -funroll-all-loops -ffast-math -march=pentium)
    time 1: 0.000
    time 2: 0.000
    [^ tady je chyba ve vypoctu, evidentne vnitrni smycku vynechalo]

    java server
    Time1: 1
    Time2: 1
    [vysledek je ok, ale ten cas opravdu nechapu]

    java client
    Time1: 183
    Time2: 148
    [zhruba na polovine cesty mezi optimalizovanym a neoptimalizovanym gcc]