Vlákno názorů k článku Gentoo a jeho klony od mirozbiro - Ahoj, kdysi jsem zkusil g. – rikam si – mam maly...
-
mirozbiro (neregistrovaný)
Ahoj,
kdysi jsem zkusil g. – rikam si – mam maly disk a slaby stroj, tohle je ono. Zkusil jsem si spoustu zajimavych veci ohledne staveni systemu, to bylo fajn, ale pak jsem zacal kompilovat X a po 2 dnech to dobehlo a kdyz jsem chtel prikrocit k gnome, tak jsem uz nejak neprosel. Cela instalace by mi trvala asi rok, coz odpovida tomu, ze muj kamos mi asi mesic rikal, ze si kompiluje doma gentoo a ja jsem tenkrat nechapal, co tim presne mysli…Mate nejaky komentar, jak se to ma delat apod?
-
vtech (neregistrovaný)
Jde o to, jak slaby stroj mate. Ty 2 dny na Xka, to vypada na Pentium 90MHz, to asi neni optimalni stroj na build Gentoo. Instalace Gentoo trva a vzdycky bude trvat radove dele, nez u jine distribuce, ale vetsinu casu to bezi samo. U mne je to vetsinou pul hodiny prace, pak 8–10 hodin kompilace (samo), pak pul hodiny donastaveni a hotovo. Je pravda, ze nepouzivam Gnome ani KDE a OpenOffice zasadne z binarniho baliku. Dulezite je si rozmyslet, co na tom systemu chcete a nastavit patricne USE flagy na zacatku. Pokud mate dost RAM (2G+), tak doporucuji /var/tmp na tmpfs. Je to v mem pripade 2× rychlejsi, nez RAID-0 z 15k SCSI320 disku. U slabsich disku to bude predpokladam jeste vetsi rozdil.
-
scarabeus (neregistrovaný)
To pujde jedine pomoci distcc kdy se ta slaba masinka pripoji na nejakej silnejsi stroj. Treba ja si vsechny balicky pro laptop pripravuji na svem ctyrjadrovem desktopu protoze proste 5 minut vs. 20 je rozdil.
No je pravda ze se to da kompilovat lokalne, ale ja osobne bych nemel nervy na to to instalovat tejden :]
-
Ash (neregistrovaný)
A ma hodně slabém stroji krom distcc ještě přichází v úvahu spíš komplet cross-compiling na jiném stroji a výsledek nakopírovat na ten slabší, protože i při tom distcc má lokální stroj dost práce se stahováním, ./configure, rozdělováním, slučováním.. Ale je otázka proč potom vlastně Gentoo.
-
mirozbiro (neregistrovaný)
Diky za oznaceni blb. Moc si ho necenim, ale vim, ze pro nektery geeky je to vrchol schopnosti v jejich socialni interakci. Obsahem tveho postu je, ze jsi trochu hrube shrnul poznatky, ktere jsem jiz predestrel vyse.
Pro ostatni – pouziju li gentoo, dostanu vetsi vykon ze stroje, nez pri std distribuci?
-
trubicoid (neregistrovaný)
no mel by byt o trochu vetsi, ale zase je problem, ze pouzivas stejny optimalizace pro vsechny programy
nektery programy jsou proste rychlejsi s -O3, nektery s -O2 a nektery s -Os; nehlede na dalsi moznosti -ftree-vectorize, -ffast-math, -funroll-loops, -fprofile-generate/-fprofile-use…
jo, kdyz jsme u -fprofile-generate/use, proc se to vlastne nepouziva systematicky? sice se program defacto kompiluje dvakrat, ale to zas neni takovej problem; vysledna binarka je vzdy rychlejsi a kupodivu i mensi
-
Výkonový rozdíl většiny voleb je minimální, s výjimkou optimalizace pro vhodný procesor, zvlášť v porovnání s i386.
Kdyby byly ostatní volby tak bezproblémové, jistě by je autoři gcc aktivovali automaticky.
-ftree-vectorize se automaticky zapíná s -O3
-ffast-math Zrychlí některé programy. Programy, které spoléhají na matematické funkce přesně podle IEEE/ISO, však rozbije.
-funroll-loops je poněkud sporná. Snaží se zrychlit kód za cenu jeho zvětšení, což někdy paradoxně vede ke zpomalení (pokud se nový kód už nevejde do cache).
Pokud není na stroji mnoho paměti, lepší než -O3 je -Os, třeba v kombinaci s -fexpensive-optimizations -frename-registers.
-fomit-frame-pointer: Poměrně účinná, ale velmi problematická volba. Na mnoha platformách a v mnoha situacích uvolní jeden registr procesoru. Ovšem za cenu praktické neladitelnosti programů.
Aby bylo profilování k něčemu, musí se aplikace profilovat při reálném použití. U konzolových aplikací to lze udělat pomocí profilovacího běhu, u GUI aplikaci to jde hůř.
-
Pouzivam na AMD Phenomu vychozi optimalizace z
http://en.gentoo-wiki.com/…/Safe_CflagsCHOST=„x86_64-pc-linux-gnu“
CFLAGS=„-march=amdfam10 -O2 -pipe“da se to nejakyma volbama vylepsit, pro vyssi vykon?
-
--hash-style=gnu vylepší start programu. Popravdě řečeno, viditelnou změnu jsem nepozoroval ani na svém PDA.
--as-needed může ušetřit linkování s knihovnami, které aplikace nepoužije. S pomalým diskem to při nedostatku paměti také někdy ušetří pár desítek milisekund (občas i stovek) při startu. Ovšem některé programy se špatným makefile to zmate a spadnou.
--sort-common ušetří pár bajtů v tabulce symbolů. Možná, že OpenOffice žrát o pár kilobajtů méně.
-s (strip) se hodí, když máte málo místa na disku a nechcete posílat chybová hlášení.
-fno-ident ušetří asi 30 bajtů na každý objektový soubor. Odstraní informaci o použitém kompilátoru.
Mohu se zeptat, k čemu je -Wl,–O1? Podle mně to jen vypíše při každé kompilaci varovavání, že je to k ničemu.
-
Když už honíte milisekundy při startu programu, můžete si hrát s volbami linkeru (za -Wl,):
Třeba -zcombreloc (setřídí relokační tabulky). Pak také -Bdirect (namísto interposingu se provede linkování thread safe/unsafe verze natvrdo v čase kompilace), -zlazy (pozdrží nahrávání dynamických knihoven). Ty jsou poněkud nebezpečné, ale pokud zafungují, máte pár milisekund k dobru.A u C++ programů byste neměli zapomenout zkusit -fno-rtti a -fno-exceptions. Pokud autor náhodou nepoužívá RTTI resp. výjimky, slušně tím program zrychlíte.
-
petr_p (neregistrovaný)
Není hash-style GNU standardně zapnut od binutils-2.18. Já jsem s tím měl na MIPSu problém.
Nestripnuté symboly zabírají také místo v paměti a v cache za běhu. Nebo ne? Vzhledem k tomu, že rozdíl ve velikosti ELFu je značný, tak pokud nejsou uložený nějak chytře (že by jádro při execu mapovalo jen některé sekce, jsem neslyšel).
-
trubicoid (neregistrovaný)
ad –hash-style=gnu: defaultni je –hash-style=both a to dela delsi binarky
k vylepseni casu startu programu je potreba kombinovat s prelink
ad –as-needed: netsina veci (vsechny co mam instalovny) s tim ted jedou, takze neni duvod to nepouzit
ad -s: toto prej neni podporovany, portage by mel sam stripovat binarky, ale nicemu to nevadi, takze to tam mam
ad -Wl: toto uvozuje celou radu LDFLAGS oddelenych nasledne carkami
ad -O1: This tells ld to optimize the hash table. As a side effect the hash table gets larger. This optimization is usually safe. For more information see http://lwn.net/…cles/192082/
-
BLEK. (neregistrovaný)
-ftree-vectorize má bohužel bugy — viz zde: http://gcc.gnu.org/…show_bug.cgi?…
Předpokládá, že zásobník je zarovnaný, což ovšem pro některé programy není pravda (ty, co mají kusy napsané v assembleru), a pak hrozí náhodné padání.
Bohužel názor některých vývojářů GCC je „my gcc opravovat nechceme, ať se přepíšou všechny ty programy“ :-(
-
trubicoid (neregistrovaný)
no ja to myslel tak, ze v make.conf mas „bezpecny“ CFLAGS, ktery ti zaruci, ze se vsechno zkompiluje jak ma
ale nektery programy jedou rychleji s jinejma CFLAGS, musi se to proste vyzkouset
jinak na amd64 -fomit-frame-pointer je zapnuty defaultne, na x86 se to vrele doporucuje a je to bez problemu, az na debugging
ad profilovani: vetsina slusnych programu ma predse make test; to vetsinou staci na nabrani statistiky pro profiler
-
Profilovací běh by měl být co nejvíc podobný běžnému používání. To účelem běžných „make test“ nebývá.
Výsledkem může být nákladné rozvinutí smyčky v prakticky nepoužívaném místě programu, jen proto že „make test“ jí prošel milionkrát. Příště vám zcela jistě poběží rychleji „make test“.
Pokud máte dokonale odladěný systém, kde nic nepadá a není potřeba hlásit chyby, pak je jistě -fomit-frame-pointer výborná volba. V obráceném případě je lépe kompilovat bez ní, a navíc důsledně používat -g. Jen u vybraných aplikací ji můžete zapnout (např. mplayer).
Pokud chci aplikaci ladit, vůbec nejlepší je překompilovat ji s -O0 – nemusíte řešit inline a místa, kde optimalizátor vynechal kód, a můžete jít rovnou k jádru problému.
-
trubicoid (neregistrovaný)
no a co teda podle vas dela spravnej „make test“?
nemyslim si, ze vetsinou dochazi k „nakladnemu rozvinuti smycek“, staci se podivat na velkost binarky bez -fprofile-generate/use a s
profilovana binarka je vestinou o dost mensi a o trochu rychlejsi, staci kdyz si to zkusite
proc by se s tim jinak namahali treba developeri firefoxu?
jinak si myslim ze mit zapnutej debbuging -g uplne u vseho je dost blbost, ja debugguju jen veci co nefungujou, nebo svoje vlastni programy
-
Profilování samozřejmě smysl má, a výkon zvýší.
Jenže typický make test zkouší nejpodivnější kombinace parametrů a vstupních dat. Většina testů vzniká jako vedlejší produkt řešení chyb nebo bezpečnostních děr, a snaží se zajistit, aby se stejná chyba nikdy v budoucnosti neobjevila.
Exploity na starou verzi, kde vstupy překračují povolené meze, nejsou dobrým vstupem profileru. Kontrola na vstupní parametry se může optimalizovat přesně obráceně, než je třeba.
Profilování v kombinaci s -funroll-loops, případně -fpeel-loops se snaží rozvíjet ty smyčky, které jsou vykonávány často. Ostatní profilové optimalizace (if/else větve, pořadí funkcí,…) asi na velikost velký vliv nemají.
U binárních distribucí je často dokonce povinnost vše kompilovat s -g. Nové gdb umí pracovat s externími tabulkami symbolů, takže symboly se uloží jako samostatný balík, a nainstalují se, když je potřeba. (-debuginfo a -debugsource v RPM distribucích a -dbg v distribucích odvozených od Debianu)
U kompilované distribuce to nejde jednoduše vyřešit. Pokud ladící symboly jednou odstraníte, už je nemáte. Abyste pak vyrobili hodnotný backtrace, musíte rekompilovat s -g aplikaci a všechny použité knihovny, a pak čekat, než to znovu spadne.
-
trubicoid (neregistrovaný)
no -fprofile-use zapne automaticky navic (gcc4.3) -fbranch-probabilities, -fvpt, -funroll-loops, -fpeel-loops, -ftracer
pritom -funroll-loops vzdy zvetsuje vyslednou binarku; pak porad nechapu proc s -fprofile-use je binarka vzdy mensi?
ad make test: jasne ze je lepsi pouzit statistiku z beznyho provozu nez make test, ale myslim si, ze i jednoduchy make test a profilovani (coz by slo jednoduse udelat u vetsiny programu) by prineslo zvetseni vykonu a snizeni velikosti binarky
-
Ash (neregistrovaný)
Za blba se omlouvám, reagoval jsem na „mam maly disk a slaby stroj, tohle (Gentoo) je ono“, připadalo mi to jako flame starter, neboť mi nepřipadalo pravděpodobné, že by někdo dobrovolně na slabém stroji šel do KOMPILOVANÉ distribuce, a protože jste si říkal „to je ono“, dalo by se čekat, že jste věděl, že budete muset dost kompilovat.
Čili pro Tebe: Gentoo nezvedne výkon stroje tolik, aby mělo smysl ho instalovat na slabý stroj a myslet, že tím získám nějaký extra výkon. Výhoda je, že lze velmi snadno vytvořit systém z vybraných komponent aniž by tam bylo navíc cokoliv dalšího, například můžete použít nějaký nenáročný WM místo kompletního DE jako KDE nebo GNOME. Ale nemá smysl to kompilovat na tom slabém stroji, dá se to udělat na jiném stroji přes cross-compile, nebo u stroje který je „na hranici“ lze použít distcc.
-
Ash (neregistrovaný)
Co se týče výkonu apolikací jako takových, nějaký zanedbatelný výkon navíc můžete získat naopak u silného stroje, na který nejsou standardní distra optimalizované (ta jsou optimalizované právě pro slabší stroje). Monhem větší (tentokrát viditelná) úspora je ale prostě instalovat méně náročné aplikace.
