XCHAOS: Dekuju ti za ochotu.


REDGUY: Uz sem ten cmovge nasel. Je fakt ze to moje rucni maskovani je horsi (resp. snazi se dalat prave tohle, akorat "manualne").

DAVIDOWITCH: tak si to překompuluj.

REDGUY: toto je přesně už moc low-level, na mě :-) mě stačí, že s různými -O přepínači se to chová jinak. souhlasím s tím, že je to překvapivé chování. programovat v C už dávno nestačí, aby člověk chápal, "co se děje pod kapotou" (což opravdu víceméně stačilo ještě např. v éře 16bit CPU bez onchip cache...)

XCHAOS: viz REDGUY

DAVIDOWITCH: ASM je na mě moc lowlevel, fakt sorry... někdo to třeba dodá a dostane od mě velký moderátorský palec nahoru.

gcc(1): GNU project C/C++ compiler - Linux man page
http://linux.die.net/man/1/gcc
hledej
"Options That Control Optimization"

-O2 Optimize even more.

zajímavé.. při optimalizaci na velikost výsledného kódu (tedy zablokování většiny těch inline-loop apod. optimalizací...) to dělá furt to samé:

xchaos@tartarus:~$ gcc -Os test.c -otest
xchaos@tartarus:~$ ./test WTF
Sum: 403504454559365000
Time: 0.471624
xchaos@tartarus:~$ ./test
Sum: 403504454559365000
Time: 2.23573

DAVIDOWITCH: Kdyz se podivas na ten stackoverflow, tak je tam super odpoved, kde ten clovek mj. pise ze Intel Compiler 11 dokaze dokonce prohodit ty dve smycky 8)

XCHAOS: Muzes to nejak rozvest?
Pripadne po mne hodit ASM vypisem, protoze si nemyslim ze by compiler mel bejt schopnej nahradit ten skok maskovanim, coz je asi jediny jak stahne ty 2 casy tak blizko k sobe (pokud si teda nezkousel tu moji modifikaci)

REDGUY: jako ano, už jsem asi objevil, že jsem ve slepé uličce, s touto úvahou :-)

myslel jsem, že třeba sečtení 33+33 by trvalo stejně jako sečtení 33+0 nebo 0+33. ale sečtení 8+8 by bylo rychlejší :-) (tedy někde by byl nějaký pomocný bitcounter, kolik z aktuálních bitů na sběrnici je "dirty" a musí se s nimi počítat v následující instrukci

ale nemám to ničím podložené, tohle je na mě moc lowlevel :-) je to jen moje divoká spekulace "jak bych vymýšlel CPU"...

DAVIDOWITCH: to už mi taky došlo


DAVIDOWITCH: jiný -O switch compileru

REDGUY:
http://en.wikipedia.org/wiki/Carry-lookahead_adder (je logN misto N)
http://en.wikipedia.org/wiki/Carry_bypass_adder
Carry-select adder - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Carry-select_adder

Ale priznam, musel sem zkonzultovat spoluzaka, protoze uz to je 5 let co sem se to ucil, 4 roky od posledniho pouziti.

DAVIDOWITCH: Neznam terminus technicus, ale takovou tu uplne obycejnou. I kdyz nepochybuju ze zaimavy budou i ty chytrejsi 8)
Zkusim najit kde jsem o tom cetl...

REDGUY: Myslis Carry-lookahead, nebo nejakou z tech chytrejsich, nebo obecne proste tyhle bordely?

REDGUY: A btw, navrh hw scitacek co pracujou v konstatnim case, aniz bys musel nejak postupne v nekolika krocich propagovat carry zleva doprava je docela zajimavej a elegantni. Doporucuju si o tom neco najit,

XCHAOS: sčítání čísel obsahujíích různý počet nastavených bitů prostě trvá různě dlouho - ale kdeze. Delka scitani integeru je konstantni, na poslednich intelech trva tusim dokonce efektivne 0.5 taktu. Navic ty cisla co scitas jsou stejna, jen v jinem poradi. A konecne tuhle teorii lze snadno vyvratit tak, ze si to vyzkousis scitanim jinejch cisel.

nebo trváte na compile-time optimalizacích - netrvame, protoze compile-time optimalizace s tim nemaji nic spolecneho (*) a nikdo tady nic takoveho nerikal. Naopak, tohle je nasledkem v podstate run-time optimalizace, ktera probiha primo v procesoru. Podrobne vysvetleni i s obrazkama: http://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-an-unsorted-array

(*) tedy, c-t-o s tim maji spolecneho to, ze maji vliv na to jak vyrazny je ten efekt a pokud mas fakt hodne chytrej prekladac, dokazou ho eliminovat. Ale na ten rozdil v casech vliv nemaji.

XCHAOS: Cim se lisej tyhle dva behy?

XCHAOS: scitani cisel obsahujicich ruzny pocet bitu trva uplne stejne, jeden takt.

xchaos@tartarus:~$ ./test WTF
Sum: 403504454559365000
Time: 0.444335
xchaos@tartarus:~$ ./test
Sum: 403504454559365000
Time: 2.32974

....a tohle je nejlepší:

xchaos@tartarus:~$ ./test WTF
Sum: 403504454559365000
Time: 0.658788
xchaos@tartarus:~$ ./test
Sum: 403504454559365000
Time: 0.687157

ok, přiznávám se - dostali jste mě :-)

(jen podotýkám, že můj mini-toolkit zahnrnuje i dávkový soubor "bake", který se má používat místo "make" a Makefile - a že budu používat při volání gcc ty optimalizace, který mě nejlíp dopadnou s mými typy zasmyčkování, která chystám... ale to je offtopic, tohle byl hezký vtípek, uznávám ...)

xchaos@tartarus:~$ gcc -O1 test.c -otest
xchaos@tartarus:~$ ./test WTF
Sum: 403504454559365000
Time: 0.43624
xchaos@tartarus:~$ ./test
Sum: 403504454559365000
Time: 2.3264

huh


xchaos@tartarus:~$ gcc -O0 test.c -otest
xchaos@tartarus:~$ ./test
Sum: 403504454559365000
Time: 3.60948
xchaos@tartarus:~$ ./test
Sum: 403504454559365000
Time: 4.5604
xchaos@tartarus:~$