DAVIDOWITCH: -O3 tedy zřejmě do kódu cpe více cmovge instrukcí, než ostatní optimalizace? :-)

XCHAOS: Vsechno tohle bylo mnohem delsi nez to prelozit s -s a hodit na pastebin. Ale, u tebe sem si uz zvykl..

DAVIDOWITCH: sorry, ale i tak jsem této hříčce věnoval víc času, než jsem dnes měl v plánu. je to ... zajímavé. je jistě zajímavá hra zjišťovat, kdo přijde na to čím to je, jaké k tomu použije nástroje. mě se to líbí, atd. - ale pro dnešek končím.

ještě jednou jsem to prověřil, a výsledek s -O3 (oba časy krátké) nebyl náhodný, fakt se vyskytuje opakovaně (statistický rozptyl mezi více spuštěními je pak podobný rozptylu mezi oběma režimy výpočtu, v rádech setin sekundy)

dle manuálové stránky:

-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options.

pokud by to někoho zajímalo dále, tak postupnou kombínací -O2 a některého z těchto flagů by mělo jít zjistit... něco (nevím co :-) to už je trochu vyšší dívčí :-)

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,