REDGUY: ad ten XOR reg, reg; Tohle je presne duvod, proc je celej x86 a compatible v prdeli. Tohle je vesmes kvuli legacy kodu, kterej v drevnich dobach mazal takhle xorem, protoze to bylo rychlejsi.
A jelikoz to je furt vsude nekde, tak je tam kus kremiku kterej resi aby to bylo rychlejsi, kterej by tam bejt nemusel, kdyby se udelal cistej rez. (Nerikam ze je to dobrej napad, jen proste tohle je krasnej priklad)

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