NE0: mě to taky nejde narozum... ale:




xchaos@tartarus:~$ gcc -O2 test.c -otest
xchaos@tartarus:~$ ./test WTF
Sum: 403504454559365000
Time: 0.450687
xchaos@tartarus:~$ ./test
Sum: 403504454559365000
Time: 2.36595
xchaos@tartarus:~$ ./test WTF
Sum: 403504454559365000
Time: 0.475942
xchaos@tartarus:~$ ./test
Sum: 403504454559365000
Time: 2.49658

FYI

xchaos@tartarus:~$ cat /proc/version
Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sun May 6 04:00:17 UTC 2012
xchaos@tartarus:~$ gcc --version
gcc (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

DAVIDOWITCH: dal jsem to už i do záhlaví, sorry :-) navzdory tomu, jak moc mi občas štve troll REDGUY, tak musím přiznat, že tuto konkrétní prerekvzitu splňuje (tedy občas se fakt šťourá v nějakých C ptákovinkách a přeloží si je)

XCHAOS: Asi sem te hricce venoval vic casu nez mas k dispozici, tak te tim nebudu zatezovat.

XCHAOS: Tvoje velmi fluidni definice toho co je on a off topic mne uz taky serou.
Takze to je ANSI C/C99 v podani gcc na Debian-style boxu? Co kdyz mame BSD? Nebo Gentoo? Nebo ArchLinux? Nebo pouzivam ICC, protoze GCC je pomalej kram?

(no jo rejpalové... si to samozřejmě kompilujte i na CentOSu nebo Gentoo, když musíte... jen jsem chtěl poskytnout vodítko začátečníkům, co mají nějaké to Ubuntu nebo Mint a chtějí rychle přejít ke kompilaci ukázkových C zdrojáků...)

je to přesněji řečeno sudo apt-get install build-essential (pro úplné Ubuntu-lamy)

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