Gentoo: Proč do CFLAGS nedávat -march

10.8.2014 23:35 | Přečteno: 1820× | linux/unix |

Při instalaci Gentoo jsem tak nějak ze zvyku a ostatně i dle dokumentace nastavil -march=corei7 na základě zjištění, které klíčové slovo nejvíce odpovídá mému procesoru. Všechno bylo fajn do té doby, než se stroj porouchal a bylo potřeba bez zbytečného zdržení přenést systém na starší stroj.

Konkrétně se jednalo o přenos systému z Lenovo x201 na Lenovo x61. Podle všech indicií to vypadá, že se na novějším stroji porouchala detekce přiklopení víka, což má za následek jednak zhasínání displeje i v případě, že je víko odklopené, jednak probouzení (a tedy vybíjení a přehřívání) počítače v zavřeném stavu v batohu. Pokud se tedy v diagnóze nemýlím, půjde o hardwarovou chybu, kterou se mi ani moc nechce zkoušet obcházet softwarovou cestou. Ještě vůbec netuším, co s tím budu dělat.

Systém nebyl schopný na x61 s Core 2 Duo nabootovat. Protože nemám žádný zvláštní zájem o optimalizace na konkrétní procesor a ani si nemyslím, že by pro mě byly nějak zvlášť užitečné, rozhodl jsem se nenastavovat -march=core2, ale místo toho volbu -march úplně odstranit. Úprava konfigurace je triviální, konverze celého systému už bohužel nikoliv. Jak tedy přizpůsobit celý systém novému nastavení?

Naivní řešení

Je vcelku zjevné, že je cílem, aby měl člověk k dispozici sadu balíků, které potřebuje a aby žádný balík nezůstal zkompilovaný s původně používanou volbou -march. Nejdřív jsem aktualizoval portage[1], ať nekompiluju některé balíky zbytečně. Řešením by tedy teoreticky mělo být překompilovat všechny potřebné balíky[2] a odstranit balíky nepotřebné, aby se člověku nepletly pod nohy[3]. Problém je, že je během této akce potřeba provozovat systém na původním stroji a tedy s externím monitorem (nebo problém řešit z live systému, což se mi tuplem nechtělo), řešení trvá neúměrně dlouho a navíc by stejně selhala, což je poznat na obdobných selháních popsaných v dalších odstavcích.

[1] emerge --sync
[2] emerge --emptytree @world
[3] emerge --depclean

Základní systém

Mým prvním cílem tedy bylo přenést systém v co nejkratším možném čase, hodit plně funkční notebook se systémem do batohu a pokračovat v oživování během víkendu mimo domov. K tomu měl posloužit rebuild pouze základního systému[1]. Vzhledem k tomu, že používám stable větev, jsem u této akce očekával velkou pravděpodobnost úspěchu, ale zřejmě na základě use flagů se mi do updatu základního systému připletlo GTK, které se navíc čert ví proč nebylo schopné překompilovat. To se naštěstí podařilo obejít jeho přeskočením[2]. Kvůli mé práci (Fedora, RHEL) používám na Gentoo systemd, které bylo po tomto kroku schopné dosáhnout alespoň emergency shellu* a po reinstalaci balíku sys-fs/lvm2[3] (a možná dalších krocích, které jsem zapomněl) nabootovalo i do regulérního systému s konzolovým přihlášením.

* Ve skutečnosti dvou shellů, ale cokoliv v tom druhém systemd vždy nesmyslně obratem zlikviduje nebo naopak z nějakého záhadného důvodu zamrzne i první shell a je potřeba restartovat.

[1] emerge --emptytree @system
[2] emerge --resume --skipfirst
[3] emerge --oneshot sys-fs/lvm2

Co se zbytkem balíků?

Systém tedy bylo možné na náhradním stroji nabootovat, připojit k síti přes ethernetový kabel a nebyl jsem tedy už vázaný na dostupnost externího monitoru. Bylo na čase vyřešit rebuild zbytku software. Rebuildoval jsem tedy jednotlivé nástroje, které jsem chtěl mít k dispozici a připravoval se na rebuild zbytku systému. Podařilo se mi získat seznam balíků (včetně kategorie, upstreamové verze a případné revize), které byly zkompilované s původním nastavením[1]. Chtěl jsem je všechny reinstalovat rovnou v aktuální verzi, ale neuměl jsem bezpečně oddělit označení upstreamové verze a revize. Zvolil jsem tedy odlišnou metodu, a to nejdříve všechen software aktualizovat[2], pak odstranit všechny nepotřebné balíky[3] a nakonec udělat jednoduchý rebuild balíků, kterých se upgrade nedotkl[4].

[1] find /var/db/pkg -name CFLAGS -exec grep -H march {} \; | awk -F/ '{print $5"/"$6}'
[2] emerge --update --newuse --deep @world
[3] emerge --depclean
[4] emerge --oneshot $(find /var/db/pkg -name CFLAGS -exec grep -H march {} \; | awk -F/ '{print $5"/"$6}' | sed 's/^/=/)

Dokončení

Bohužel i toto řešení z různých důvodů* selhává a je potřeba ho trochu vylepšit. Vzhledem k tomu, že už teď se snažím držet prázdný /var/lib/portage/world a mít nadefinované skupiny software v /etc/portage/sets, usoudil jsem, že bude nejlepší tyto skupiny odstranit z /var/lib/portage/world_sets[1], postupovat dle výše uvedených kroků a nakonec software doinstalovat jako při nové instalaci. Při troše snahy (nepamatuju si všechno) lze takový systém aktualizovat[2], vyčištění ovšem selhává a jsou potřeba další dva kroky[3][4] které už tak nějak vyplynou z výstupu předchozího příkazu, aby se nakonec vyčištění podařilo[5] a bylo možné provést rekompilaci[5]. Opět v postupu chybí vyřešení konkrétních problémových balíků, které většinou spočívá v jejich odstranění a opětovné instalaci na základě závislostí.

* Jedná se mimojiné o live ebuildy a další odchylky od čistého stabilního Gentoo.

[1] >/var/lib/portage/world_sets
[2] emerge --update --newuse --deep @world
[3] emerge @preserved-rebuild
[4] emerge --update --newuse --deep --with-bdeps=y @world
[5] emerge --oneshot $(find /var/db/pkg -name CFLAGS -exec grep -H march {} \; | awk -F/ '{print $5"/"$6}' | sed 's/^/=/)

Nyní je systém opraven v tom smyslu, že neobsahuje žádné balíky zkompilované s původní konfigurací a už je potřeba už jen dostat do systému vše, co mi tam chybí. To v mém případě vedle samotné instalace skupin software pomocí emerge spočívá především v opravě různých live ebuildů, které běžně přestávají fungovat kvůli změnám v upstreamových repozitářích a potřebují nějakou tu údržbu.

Stojí to za to?

Pro mě je poučení z toho celého, že na strojích z poslední doby (x61 je tuším z roku 2007) není doba kompilace celého systému nijak drastická (už jen tím, že nevyžaduje pozornost člověka) a že největší zpoždění vzniká, když emerge svoji práci zastaví s chybou a člověk zrovna není u počítače, aby s tím něco udělal. V mém případě se oprava natáhla na několik dní právě tím časem, kdy počítač vůbec nic nedělá a čeká se na zásah administrátora.

A to vše jsem si mohl odpustit, pokud bych měl systém od začátku připravený běžet na náhradním notebooku, tedy bez optimalizace na konkrétní typ procesoru, konkrétně bez volby -march. Co je horší, nejsem si vědom, že by mi optimalizace na konkrétní procesor kromě problémů vůbec něco přinesla a vážně uvažuju o tom, že se budu konfigurace bez této volby držet.

       

Komentáře

[Václav "Darm" Novák]

Jako člověka který kdysi utekl k Archu, aby optimalizace musel řešit jen tam kde to chce by mě zajímalo… Stojí dneska Gentoo za ten obětovaný čas?

[Václav Vanc]

Myslím, že jo. Asi už ne kvůl optimalizacím (na 32b to bylo vidět mnohem víc), ale např. USE flagy jsou pěkná vlastnost. :)

[pavlix]

Velmi pěkná vlastnost, která posouvá značnou část rozhodování od maintainera k uživateli. Ale není to zdaleka jediná věc, kvůli které má smysl o Gentoo uvažovat.

[pavlix]

Viz zde...

[pavlix]

Jako člověka který kdysi utekl k Archu, aby optimalizace musel řešit jen tam kde to chce by mě zajímalo…

Vzhledem k tomu, že je celý zápisek o tom, že považuju za chybu, že jsem procesorové optimalizace vůbec zapínal, tak si zjevně můžeš vybrat, zda a kdy optimalizace řešíš. Já osobně jsem kdysi Arch zkoušel, ale ty tooly se mi nelíbily, zatímco v Gentoo mám pocit, jako kdyby byly udělané téměř podle mého vlastního myšlenkového modelu.

Stojí dneska Gentoo za ten obětovaný čas?

Osobně jsem Gentoo začal používat dvakrát a v obou případech to bylo proto, aby mi čas ušetřilo. Je pravda, že mě tenhle incident stál možná čtyři hodiny času během tří dnů, ale zase na druhou stranu je to moje chyba (že jsem moc nepřemýšlel před nastavením CFLAGS) a docela bych řekl i zajímavá zkušenost. A v globálním měřítku to vůbec nejde srovnávat s ušetřeným časem (bráno oproti běžným binárním distribucím).

[psi noha]

"Stojí dneska Gentoo za ten obětovaný čas? "

Nestoji, presel jsem na svem pracovnim PC z Gentoo na Linux Mint, a zadny rozdil v rychlosti jsem nezaznamenal. Akorat veci zacly fungovat a vzajemne spolupracovat ve vychozi konfiguraci, a nemusim se po instalaci kazdeho softwaru zkoumat, jak to vlastne zprovoznit. Gentoo je dobry pro lidi co si chteji hrat, Mint pro lidi, co potrebuji pracovat.

[pavlix]

Nestoji, presel jsem na svem pracovnim PC z Gentoo na Linux Mint, a zadny rozdil v rychlosti jsem nezaznamenal.

Nikdy jsem nechápal cargo kult lidí, kteří věřili, že instalace Gentoo nějak magicky zrychlí jejich systém.

Gentoo je dobry pro lidi co si chteji hrat, Mint pro lidi, co potrebuji pracovat.

V tom případě mám to štěstí, že je po letech opět mojí prací hraní ;).

[kavol]

Nestoji, presel jsem na svem pracovnim PC z Gentoo na Linux Mint, a zadny rozdil v rychlosti jsem nezaznamenal.

Nikdy jsem nechápal cargo kult lidí, kteří věřili, že instalace Gentoo nějak magicky zrychlí jejich systém.

jsou tací, co věřili, že se to nestane magicky, nýbrž v důsledku optimalizací ... které se na Gentoo realizují významně snadněji, než v jiných distrech

[pavlix]

Pointou mého komentáře bylo, že nepovažuju za správné odsoudit Gentoo jen kvůli tomu, že nepřinese právě ono magické zrychlení. Jak je jasné z blogu a dalších komentářů, u mně osobně rychlost provádění binárek nepatří mezi motivaci používat Gentoo vůbec.

[kavol]

mno, asi to nebylo zcela zjevné, nicméně pointou mého komentáře nebyl výsledek optimalizace, nýbrž to, jak snadné je ji učinit, což je myslím docela v souladu s tvojí motivací používat Gentoo ...

[Hans1024]

To by se dalo pouzit i jako argument proc kompilovat jenom 32bit binarky

Proste si staci pri kompilaci uvedomit, jake mam nejhorsi zelezo na kterem bych to eventuelne chtel spustit a podle toho optimalizovat.

[pavlix]

To by se dalo pouzit i jako argument proc kompilovat jenom 32bit binarky

Pro mě je 32bit x86 mrtvá, takže v mém prostředí nikoliv. Ale jinak bych to vůbec nebral jako vtip a v určitém prostředí může mít výhodu provozovat jednotné 32bitové prostředí i přesto, že některé instance poběží na procesoru s 64bitovým režimem.

Proste si staci pri kompilaci uvedomit, jake mam nejhorsi zelezo na kterem bych to eventuelne chtel spustit a podle toho optimalizovat.

Ve skutečnosti by člověk musel optimalizovat na průnik, protože ne vždy funguje lineární uspořádání. Na druhou stranu u těch thinkpadů předpokládám, že by optimalizace na core2 fungovala. Ale jak již bylo řečeno, zatím si nejsem vědom, že by mi to něco přinášelo. Samozřejmě budu rád za každou informaci, která povede k mému osvícení :).

[Hans1024]

Z me zkusenosti je prinos vetsinou v jednotkach procent, takze prakticky nepostrehnutelny. Jedinny markantni prinos, ktery jsem videl, byl WINE, ktery se mi viditelne zrychril - ale to asi jen diky tomu, ze WINE je 32bit, takze defaultne asi musel pocitat jen s instrukcemi 386ky.

Na phoronixu delali nejake testy, ze kterych je videt, ze s pridanim nekterych instrukci muze byt zrychleni nekterych operaci dost vyrazne, ale asi se to nestava tak casto a u multimedialnich aplikaci, ktere z novych instrukci casto tezi, se to vetsinou vyresi runtime detekci CPU.

[pavlix]

Mimochodem, zapomněl jsem v článku uvést, že vůbec netuším, co dělá --with-bdeps=y, ale vypadlo to jako doporučení z emerge a nedostal jsem se bez toho dál.

[kavol]

mělo by to brát v úvahu i všechny[*] build závislosti, nejen runtime ... je pravda, že u Gentoo je to prakticky skoro totéž[**], ale bohužel právě jen skoro

[*] je pravda, že také nechápu, co má vlastně znamenat "that are not strictly required"

[**] provozovatelé binárních distribucí nechť si to představí tak, že mají ke každému balíčku instalován i příslušný -devel balíček; no a v tomto případě něco potřebuje právě ten -devel balíček ke zbuildění, ale už nepotřebuje ten základní (ne-devel) balíček k provozu

[Marián Kyral]

Já mám za to, že se ti zaktualizuje třeba cmake i když jej žádná, právě aktualizovaná, aplikace nepotřebuje. Bez --with-bdeps by se cmake zaktualizovalo až v případě potřeby - tedy aktualizace nějaké aplikace, která cmake potřebuje.

[pavlix]

Pořád nemám jasno v tom, co to přesně dělá a proč bez toho následný emerge --depclean nefunguje.

[kavol]

hm, posun od "vůbec netuším, co dělá" k "nemám jasno v tom, co to přesně dělá" vidím jasně pozitivně

[pavlix]

To rozhodně.

[Marián Kyral]

Pořád nemám jasno v tom, co to přesně dělá a proč bez toho následný emerge --depclean nefunguje.

No nejsi jediný. Ovšem jednoznačná odpověď tam není.

[petr_p]

--depclean rekonstruuje strom závislostí od world. Takže když máš starý dev-util/cmake, který máš v systému jenom jako DEPEND, tak emerge --update --deep jej nezaktualizuje, kdežto --depclean si vezme novější dev-util/cmake a tím vytvoříš nesoulad mezi tím, co chce --depclean a co máš nainstalované. --with-bdeps=yes vpodstatě doplní množinu závislostí na úroveň, která je podobná (ideálně shodná) s --depclean. (Je to trochu složitější, protože PMS podporuje dočasnou instalaci build-time závislostí jen po čas aktualizace a následné odinstalování, ale to není tady důležité.)

[pavlix]

Jestli to dobře chápu, tak je to tedy výjimka z nerozlišování build a runtime závislostí a default je nastavený tak, že sekvence --update --newuse --deep a --depclean není bez dalších voleb podporovaná.

[Bedňa]

Však to nieje Microsoft :) Máme zdrojáky.

# Pull in build time deps as requested, but marked them as
# "optional" since they are not strictly required. This allows
# more freedom in the merge order calculation for solving
# circular dependencies. Don't convert to PDEPEND since that
# could make --with-bdeps=y less effective if it is used to
# adjust merge order to prevent built_with_use() calls from
# failing.

# If rebuild mode is not enabled, it's safe to discard ignored
# build-time dependencies. If you want these deps to be traversed
# in "complete" mode then you need to specify --with-bdeps=y.

# For --with-bdeps, ignore build-time only blockers
# that originate from built packages.

Ako nePythonista v tom nemám moc jasno, ale vyzerá že preskakuje problémy a na záver odstraňovaním a doťahaním balíčkov problém vyrieši, ale to by sa do toho musel pozrieť niekto iný ja som vytiahol len pár komentárov, ktoré dokonca znejú inak ako dokumentácia, ale je nad nimi a pod nimi kód s tým súvisiaci.

[pavlix]

a na záver odstraňovaním a doťahaním balíčkov problém vyrieši

Nikoliv. Pokud by problém na závěr vyřešil, neměla by volba --with-bdeps vliv na následný emerge --depclean. Zjevně to celé trochu hapruje.

[Josef Kufner]

No vidíš, kdybys tam měl Debian, tak jen přendáš disk a funguješ prakticky hned

[pavlix]

To už teď platí i o tom Gentoo.

[Max]

Optimalizace přímo na cpu, to je velká zrada, která nevím, zda má nějaké větší výhody pro běžného smrtelníka.
Zdar Max

[Grunt]

U aplikací jako je Mplayer docela jo.

[pavlix]

Můžeš to trochu rozepsat? Pokud by se jednalo o jeden nebo několik málo programů, tak lze samozřejmě v Gentoo nastavit CFLAGS speciálně pro ně a je celý problém vyřešený. Na druhou stranu když se sse/sse2/sse3/ssse3 zapíná use flagy a nikoliv CFLAGS, tak by mě docela zajímalo, jak mplayer využije optimalizaci na procesor v rámci architektury amd64.

[Grunt]

No měl jsem v defaultu ještě kdysi dávno přeložený mplayer na -march=i386 a v mém případě to znamenalo oproti -march=prescott rozdíl mezi přehráním či nepřehráním HD H.264. Víc o tom není moc co psát. Víc o tom není potřeba co rozepisovat.

tak by mě docela zajímalo, jak mplayer využije optimalizaci na procesor v rámci architektury amd64.

Aspoň co se mplayeru týče, tak si to můžeš lehce vyzkoušet. Přepínač -benchmark je to co hledáš.

[pc2005]

Jj třeba u ARM xscale je potřeba speciálně povolit -march (na ffmpegu), jinak selže autodetekce iwmmxt instrukcí (MMX hybrid na intel ARM).

[Halis]

Myšlenka přenositelnosti zkompilovaných binárek ještě nutně neznamená ztrátu optimalizací. Proč nepoužít například něco jako -march=generic -mtune=corei7 ?

[pavlix]

Předpokládám, že -march=generic je default. Ale jaké výhody mi poskytne ten -mtune=corei7, když (1) to neumožňuje využívat specifické vlastnosti procesoru a navíc (2) systém na takovém procesoru teď ani neběží.

Onanie nad tím, že jsem ulil bohům a zapnul nějaké pochybné neškodné optimalizace pro mě asi není dostatečnou motivací pro další rebuild celého systému.

[Semo]

-mtune by malo ovplyvnit radenie instrukcii tak, aby vyhovovali zadanemu procesoru (s ohladom na velkost cache, dlzky instrukcnej pileline atd.), pricom ale pouziva iba "zakladne" (generic) instrukcie. Ci to ma meratelny vykonovy rozdiel, to netusim.

Ja mam vsade -march=native a zatial som si hubu nenabil. Ked ja uz prenasam system na iny pocitac, tak mam spravidla aspon o generacie novsi CPU, takze spatna kompatibilita to riesi.

[pavlix]

Tak nebudu si jako záložní počítač držet o generaci novější. Navíc na -march=native mi vadí to, že se nezaznamenává, s jakou volbou je balík skutečně zkompilován, takže stejně nakonec optimalizace na konkrétní procesor vůbec nedosáhneš a máš každý balík zkompilovaný pro jiný procesor. Pokud je ti to jedno, pak mi to přijde jako úlitba bohům, že jsi pro optimalizaci jakože něco udělal, ale přitom nejsi schopný ani auditovat, který balík je jak zkompilovaný.

Osobně se mi koncept -march=native pro kompilaci vůbec nelíbí. Když se procesor nemění, je to k ničemu a není problém nastavit konkrétní typ, když se mění, tak člověk ztrácí přehled o tom, co je jak zkompilované.

[Semo]

Asi by na ten prenos stacilo mat "system" skompilovany nejak defenzive, ono to aj tak su veci, ktore su sice zivotne dolezite, ale nejak vela casu na CPU netravia, alebo nevyuzivaju nove instrukcie (SSE pre gcc je asi nevyuzitelne). A "world - system" mat -march=native. Ani drtic hw nemeni poctace tak rychlo, aby si nemohol po preneseni disku prekompilovat niektore veci. A s defenzivnym systemom nemusi zhanat hw kompatibilny s odidenym, aby si pripravil prostredie.

[pavlix]

Nevidím důvod kompilovat system a všechny jeho závislosti odlišně od zbytku systému a popravdě ani nevím, jak by se to dělalo.

[Heron]

radenie instrukcii

Má to vůbec smysl, když už i x86 procesory sami umí (už skoro 20let) out of order execution a sami si to přeskládají k obrazu svému?

[Semo]

Neviem, preto pisem o pochybnostiach ohladne meratelnosti zlepsenia. Ale nie je out-of-order logika v CPU obmedzena velkostou pipeline a riesi iba poradie mikroinstrukcii? Takze iba (radovo) male desiatky mikroinstrukcii pri sucasnych to procesoroch. Ked tak ma nejaky hardwarista opravte.

"-march=native" je pre mna riesenie, pri ktorom nemusim presne studovat ktory zo 100 optionov pre gcc je pre mna optimalny, to si poriesi gcc samo. A v desktope menim CPU tak zriedka, ze pre mna neznamena problem si dopredu spravit "emerge system" s novymi nastaveniami a preniest disk az potom. Nahle a neriesitelne mi v doterajsom zivote chcipli len disky, nie iny hw. A vtedy sa problem s prenasanim starych binariek vyriesil tak nejak sam ich hodenim do kosa.

Pri LibreOffice si ale namyslam, ze vidim rozdiel v rychlosti nabiehania binarnej a kompilovanej verzie. Ale mozno je to use-flagmi a nie CXXFLAGmi. Na starom nb mam binarny balik (pretoze by sa tam kompiloval 12 hodin), ale nie som sekretarka, takze ho potrebujem len parkrat mesacne. To si mozem na start troska pockat.

[Patvor]

(V jednom gcc bug reportu mi jeden z Gcc maintainerů natvrdo napsal, ať -march=native -mtune=native nikdy nepoužívám. Místo toho mám užívat konkrétní model CPU. Vysvětlení jsem nežádal, radu respektuji.)

[petr_p]

Vím o dvou problémech: native funguje jen na intelu a při distribuovaném překladu každý builder může mít jinou představu o tom, co je native.

[pavlix]

Třetí, zvlášť důležitý pro Gentoo je, že native nenese informaci o tom, jak bude kód přeložený.

[Seraph]

Vliv to má. Správné přeskládání instrukcí ma vcelku velký vliv na rychlost. OoO má omezené možnosti a nevidí situaci z větší perspektivy.

[pc2005]

Tak pokud chceš porovávat i7 s něčím jako P6, tak nejspíš jo. Už jen proto, že i7 bude mít větší buffery (frontu instrukcí, cache mikroinstrukcí, pipeline, ...) a tedy bude moci dělat OoO operace s více daty.

Rozdíl mezi dvěma skoro sousedníma generacema bude ale asi malý. I když v kritických aplikacích to může být znát (třeba viz Grunt), což jsem pocítil při pokusech s x264, kdy kompilace přímo na míru nonSSE Duronu snížila dobu enkódování tak na polovinu (sice to bylo stále nepoužitelných 10 hodin, ale pokrok je pokrok ).

[Jendа]

x264 by taky mělo umět runtime detekci procesoru, ne? Alespoň mně to řekne

[libx264 @ 0x1094480] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

[rADOn]

IMO vsechny programy ktere pro to maji rozumne vyuziti maji nejakou detekci. Nejak se mi nechce verit ze by vyrobci spinaveho kremiku zatezovali s novymi instrukcemi kdyz by je mohli vyuzit jen "march" gentooisti…

[Jendа]

No já nevím… před deseti lety už taky byly všechny desktopy (alespoň ty s AMD) 64bit, a přitom to využila jenom malá část z toho 1 % linuxáků. Windowsáci začali víc používat 64b systémy až od W7.

[Šangala]

No to je jasné, první CPU AMD 64bit 2003 a první CPU Intel 64bit 2004 a ono už byly všechny desktopy 64bit (Merced-a neberu v potaz) .

[pc2005]

No už si to pořádně nepamatuju, ale myslím, že tam byl problém buď v tom, že se ignorovalo 3dnow a nebo se při detekci -mfpmath zjistilo, že duron nemá SSE a tak se disablovalo úplně. Možná obojí. Vím, že nakonec jsem byl zoufalý a natvrdo nastavil v Makefile věci na -mfpmath=387 -m3dnow -mmmx apod. A výsledkem bylo, že místo 2fps to enkódovalo tak 4fps .

P.S. Téměř všechno ve Slackwaru je (bylo) kompilované pro i486.

P.P.S. Nevím zda to je na x86 stejný, ale třeba na PXA27x, když dáš -mcpu=xscale, tak by se rozšiřující iwmmxt instrukce nikdy nezkompilovaly (potřebujou -mcpu=iwmmxt a například při inline assembleru jinak hlásí kompiler chybu).

[Jendа]

Já zase narazil na to, že mi volk na A20 sveřepě nutí „jenom“vfpv3-d16, i když to umí NEON. Ale teď jsem asi narazil na vysvětlení:

If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=‘neon’), note that floating-point operations are not generated by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.

[kavol]

A výsledkem bylo, že místo 2fps to enkódovalo tak 4fps .

mno, já mám při konverzi z foťáku na web často tak jenom kolem 1 fps a nějak mě to nepálí

- na Core i5 750 (čtyři plnohodnotná jádra, 2,67 GHz), ffmpeg kompilován s -march native (s přenosem systému na jiný stroj nepočítám, nainstaluju na čisto, ono přece jen čas od času se v distru něco změní, co se špatně opravuje nad existujícím systémem, např. teď už na mě nějakou dobu řve, že /var/run není symlink nebo něco takového)

páč tomu nerozumim, tak místo špekulování nad optimálníma parametrama jsem si do skriptu fláknul -preset placebo, stroj běží furt, tak ať si počítá

[Grunt]

To je ještě dobrý. Já si stáhnul a zkompiloval x265 a předložil jsem tomu jeden obrázek o rozměrech 1920x1080 pixelů s parametry -profile mainstillimage -preset placebo. Doba běhu: 56 sekund. Takže tak 1fpm. Možná že kdybych to přeložil s -march=prescott, že bych něco málo ušetřil

s přenosem systému na jiný stroj nepočítám, nainstaluju na čisto, ono přece jen čas od času se v distru něco změní, co se špatně opravuje nad existujícím systémem, např. teď už na mě nějakou dobu řve, že /var/run není symlink nebo něco takového

Tak to jám mám vždycky několik verzí ffmpegu(libav), mplayeru na každém systému (vč. nativního binárního).

[Jendа]

Tak to jám mám vždycky několik verzí ffmpegu(libav), mplayeru na každém systému (vč. nativního binárního).

A já mám zase víc gnuradií. Každý má nějakou úchylku :).

[pc2005]

No já jsem míval asi 6 verzí Xilinx ISE .

[radeczek]

Čest, při takových těch delších updatech systému používám --keep-going kde pokud se naskytne chyba, daný balík se přeskočí a jede se dál. Pak jen k tomu sednu a vyřeším chybky...

[Marián Kyral]

Jo, většinou to funguje. Ovšem když to vyhučí na nějaké základní knihovně, tak se přeskočí všechno, neb to na tom závisí a jsi tam kde jsi byl

[mimi.vx]

tak -march ja pouzivam jen tam kde vim ze nic podobneho jako prenos systemu delat nebudu . jinak se pouzije -mtune .. a u me je to uz -march=native

[pavlix]

Co by mě tedy zajímalo je, zda ten -mtune stojí za úvahu.

[mimi.vx]

to netuším a ani nehodlám měřit , mezi různými systémy přenáším max data , reinstalce gentoo je stejně pro mě otázka jen pár hodin během kterých člověk stejně na daném hw může v klidu pracovat s Live sytémem .. takže k čemu přenositelnost OS ..

[pavlix]

takže k čemu přenositelnost OS ..

Já s live systémem pracovat nemůžu, nesplňuje moje potřeby. Navíc nechci zničit existující systém a přitom chci instalaci podržet na stejném fyzickém disku.

Jinak řečeno, malé riziko, že systém při úpravách poškodím natolik, že ho budu muset oživovat z live systému je pro mě jakž takž přijatelné, už jen proto, že mi nic jiného nezbývá. Na druhou stranu nedržím si vždy podobný starší stroj v zásobě jen tak pro legraci a nechci při každém problému provádět nové instalace a naněkolikrát přenášet konfiguraci roztahanou různě po filesystému.