Vlákno názorů k článku Arch Linux: rychleji už to nejde od R - Optimalizacia sa nerobi tak, ze sa nieco skompiluje...

Ale není to zadarmo. Často zaplatíte také několikanásobnou velikostí binárky.

Další možnost je používat v programech vhodné knihovny. Někde jsem viděl matematickou knihovnu pro C++ s jejíž pomocí byly matematické operace zhruba stejně rychlé v C++ jako s Fortranem. Nicméně se za to platí použitím dosti nestandardních technik a rozkopírováním kódu místo jeho voláním z funkcí.

blitz++

Zas tak uplne to neni, napriklad optimalizace pro cpu s malou cache binarku zmensi. Kdyz se nahodou stane, ze Vam cache s ramkama zacne hrat ping-pong, tak se beh velmi znatelne zpomali.
A optimalizace pro architekturu (zde i686) zapina pouziti "lepsich" instrukci typu sse, mmx atd a tim se binarka take moc nezvetsuje (mozna dokonce naopak).
Co ji zvetsi je rozbaleni cyklu, zarovnani kodu a inlineování funkcí. Bohuzel prekladac se nemuze uplne dobre rozhodnout, ktere cykly rozbalit a u kterych je to zbytecne, protoze se jimi projede jen jednou za 10 let, nicmene napriklad nerozbalene vymazavani pameti (pole) je zatracene pomale :-)

tak co nejaky profiler, na jehoz zaklade by pak bylo mozne podstrcit gcc vhodna data? :)

Ano je, ale nesetkal jsem se moc s tím, že by se používal.

Pomaha to cca 10%. http://www.suse.de/~gcctest/SPEC/CINT/sb-huckleberry2-fdo-64-FDO/
http://www.suse.de/~gcctest/SPEC-britten/CFP/sandbox-britten-FDO/index.html
navic to casto zmensuje binarky, zejmena tu cast co se po startu nahraje do pameti. S temer nulovou uzivatelskou zakladnou je problem, i kdyz ohackovat bezny balik, aby se prelozil byva tak snadne jako

CFLAGS="-O2 -fprofile-generate" make
make test
make clean
CFLAGS="-O2 -fprofile-use" make

Kdyby se to jednotlive utilitky naucily pouzivat, bylo by to fajn. Chybi nejakapodpora automake...

dik za tip, ty vysledky jsou opravdu brutalni.... na jedne aplikaci me to dalo 20% a to uz je vcelku pekne cislo

Co já vím, tak i když je dnes distro kompilované pro i386, neznamená to, že by tam nebyla podpora pro "lepší fíčury". Je to složitější.

1. Podpora "zrychlovacích" instrukcí jako sse, 3dnow. Většinou je zapnutá, i když se kompiluje pro i386. Binárka však obsahuje i náhradní kód pro procesory bez těchto instrukcí. proto i386. Arch zdá se tento kód neobsahuje (kompilátor ho může vynechat), to znamená, že musíte mít minimálně fpu a mmx. Ale i i386 binárka může mít podporu pro sse4.

2. optimalizace na architekturu. Při tomhle se se binárka sestavuje tak, aby to vyhovovalo danému procesoru. Různé procesory různě "reagují" na kód. To se asi týká hlavně out-of-order kousků. Zkrátka se použije řazení instrukcí, které dané Pentium nebo Athlon nejméně zblbne... Binárka je ale pořád univerzální. Myslím, že jedna z možností optimalizace je taky i686, ale toto je stále kompatibilní s i386.

3. O1 O2 Os O3 - tohle jsou úrovně optimalizace gcc. Mezi O1 a O2 je IIRC rozdíl jen v času, který kompilace věnuje řešení. Os se snaží zmenšuit velikost binárky, O3 dělá různé věci, které můžou zvýšit velikost binárky ale i výkon. Potenciálně problémové. Tyhle binárky jsou stále univerzální.

Pak jsou ještě další volby, které můžou zvednout výkon a zbořit stabilitu :)

> 1. Podpora "zrychlovacích" instrukcí jako sse, 3dnow. Většinou je zapnutá, i když se kompiluje pro i386. Binárka však obsahuje i náhradní kód pro procesory bez těchto instrukcí. proto i386. Arch zdá se tento kód neobsahuje (kompilátor ho může vynechat), to znamená, že musíte mít minimálně fpu a mmx. Ale i i386 binárka může mít podporu pro sse4.

Pokud vím, tak tohle umí např. překladač od Intelu, ale GCC ne.

Mě se zdá, že umí i GCC. Jsou tam tuším dva přepínače - jeden udělá binárku bez a jeden s kódem pro obyčejné 386.

Pokud mate sifrovany souborovy system tak velmi casto, pak to s prehledem udela mnohem vic nez Vasich 5%

Co je to za blabol? Cetl jste vubec na co reagujete? Peter mluvil o zoptimalizovanem systemu - tzn. command line utility, samba, xka, kde a ja nevim co jeste.... Rychlost sifrovaneho FS bude zaviset jen a pouze na tom, jak je prelozeno jadro a nejaky fuse modul. To mi vysvetlete, jak KDE nebo Apache prelozeny pro 686 muze mit vliv na rychlost desifrovani filesystemu?? Souhlasim, ze v tomto konkretinm pripade to muze mit dost velky vliv, ale na to, abych tohoto dosahl, nepotrebuju instalovat arch. Ten CryptoFS modul si se vsema moznyma optimalizacema prelozim i v ubuntu a vysledek bude stejny. O zbytku si stejne jako Petr nemyslim, ze by melo nejaky podstatny vliv (tech 5%).

Ja ano, ale Vy bohuzel asi ne. Odpovidal jsem na to, jak casto poustim rutiny pro kryptovani. Na tu druhou cast jsem uz nereagoval, protoze jsem nechtel zbytecne vyvolavat hadku.

Moje zkusenosti ukazuji, ze optimalizovat pro architekturu se vyplaci, napriklad diky tomu mi bezpoblemu funguje pocitac s via c3 jako video (bez optimalizace se celkem casto trhalo). Tez arch krasne slape na mem starem notebooku, vizte http://petris.webhosting.klfree.net/archnastarymhw.avi . Predtim jsem dlouho pouzival slackware, a narust rychlosti pri prechodu na arch byl znatelny.

Samozrejme vliv KDE na rychlosti desifrovani je velmi maly, konkretne zde se vliv optimalizace projevi spise opacne. Optimalizace programu X se totiz projevi zejmena v behu programu X a v behu aplikace Y az zprostredkovane, pokud jsou obe ulohy casove multiplexovany na stejna CPU. Tento vliv se velmi meni podle druhu aplikace, nejznatelnejsi je prave na sifrovani pripadne treba pri sledovani videa. Doufam, ze jsem Vam to vysvetlil dostatecne pochopitelne, jinak se ale klidne jeste zeptejte!

A nesnazte se mi prosim cist mezi radky, ze ubuntu je spatne, nic takoveho mezi ne totiz nevpisuji. Je mi zcela jedno, co maji ostatni na svych pocitacich, do te doby, nez s temi pocitaci musim pracovat ja.

Ale ja se v tomto s Vami v zadnem pripade nehadam! Sice jste v podstate opsal to co jsem psal ja, ale presto dekuji za nabidku dalsiho vysvetleni ;-)

Peter psal, ze optimalizovat cely system na architekturu je v zasade nesmysl, protoze to v celku prinese tak 5% zlepseni, coz je pri normalni praci nepostrehnutelne. Neminim se hadat, ze u nekterych konkretnich aplikaci to muze pomoct velmi vyrazne, ale tvrdit, ze je DISTRIBUCE dobra proto, ze je CELA prelozena pro 686 podle me nema moc smysl.

A vy jste na to napsal (alespon takto to vyznelo), ze to dulezite je, kvuli sifrovanemu filesystemu. A ja Vam na to oponoval, ze kvuli tomu nemusim mit zoptimalizovanou celou distribuci, ze si staci zkompilovat tu jednu danou aplikaci.

A v to cteni mezi radky jste expert Vy, protoze ja jsem Vam absolutne nepodsouval ze byste tvrdil, ze je ubuntu spatne (to by me skutecne zajimalo, kde jste na tohle prisel). Vzal jsem ho pouze jen jako priklad.

kde konkrétně prosím tvrdím toto: "DISTRIBUCE dobra proto, ze je CELA prelozena pro 686"

Nikde (a ja ani nepsal, ze to tvrdite Vy), ale oponujete clovekovi, ktery tvrdi, ze to tak neni. Ano, ve skutecnosti jste reagoval na jeho otazku, jak casto poustite sifrovaci algoritmy, ktera byla z casti recnicka (viz. ten smajlik) a dale vysvetluje, ze opravdu nema na mysli konkretni rutiny, ale cely operacni system (v cemz jsem s nim za jedno).

Vase nasledna reakce se tedy dala brat dvema zpusoby:

a) neosouhlasite, ze cely OS prelozeny pro 686 je zbytecnost, protoze pri pouziti sifrovaneho FS je optimalizace potreba. Tak jsem to pochopil ja a proto jsem Vam oponoval (zvlast kdyz je z ni citit lehke invektivum).

b) byla naprosto zbytecna,protoze jste se s Peterem vlastne shodl. Pak ovsem nechapu, proc jste to vlastne psal, protoze on sam se nikterak nehada, ze u konkretnich specializovanych rutin ke znacnemu zrychleni skutecne dojde.

Reagoval jsem na to, jak často se pouštějí ony šifrovací algoritmy, protože někoho třeba hned takový případ nenapadne (tím nemyslím konkrétně Petera, čte to tu více lidí).

A svým prvním příspěvkem ve vlákně Optimalizacia jsem podpořil názor vgt, který se vůbec netýkal konkrétní optimalizace pro i686 či zda se vyplatí optimalizovat celý systém, ale optimalizace pro architektury obecně. Odporoval jsem proto, že moje zkušenosti s optimalizací jsou jiné a totiž, že se mi dvakrát vyplatila:
1) Používám EPIU jako videopřehrávač a bez optimalizace se některá videa trhala, po optimalizaci se netrhají. Konkrétní číselný nárůst výkonu tady neodhadnu, ale i kdyby to bylo to 1%, tak se to sakra vyplatilo. (Spíš to bude víc, protože CPU má malou cache -Os a většinu doby tráví chroustáním multimédií -march=c3). Zde by samozřejmě stačilo přeloži s optimalizací jen některé aplikace, ale než se s tím zabývat, tak jsem radši nasadil gentoo a nechal přeložil vše.
2) Můj starý notebook po přechodu na arch ožil, subjektivně se zrychlil tak o čtvrtinu - start aplikací (X+KDE nabíha 10s) i odezva. Samozřejmě, že čím je CPU lepší, tím je výkonový zisk z optimalizace méně znatelný a limitem se postupně začne stávat rychlost přístupu do RAM.

No, pokud to mají dobře naprogramované, tak ty největší žrouty mají ručně napsané v assambleru, protože tak se dá docílit největší zrychlení (aspoň s gcc). A to samozřejmě kompilátor nezrychlí. Takhle to dělá xvid a x264.