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...

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]