Gentoo Linux - Prelink a Psyco (diskuse)

[Pmx]

emerge --update --deep --newuse world - tohle překompiluje celý systém? Nemělo to být emerge -e world?

[Pmx]

Teď jsem si uvědomil, že se změní USE flagy (+pic), takže --update --deep (-uD) bude fungovat taky...

[D-Evil]

Předevšim asi jde o to, že emerge -e (--emptytree) world rekompiluje celej systém - všechny balíky i s jejich závislostma, bez ohledu na to, jestli už jsou nainstalovaný a jestli vyhovujou novejm potřebám (USE flagům). To se používá například při změně CFLAGS a CXXFLAGS. Je celkem logický, že jen kvůli přidání podpory pro ALSA nebudu rekompilovat úplně všechno, třeba takový gcc mě v tu chvíli zajímat opravdu nebude. K tomu slouží parametr -N (--newuse) - zjištuje, s jakejma volbama byl kterej "balík" kompilovanej a zabejvá se pouze tim, co novejm potřebám nevyhovuje.

[Pmx]

To -N jsem do předchozího příspěvku zapomněl připsat, jinak takové věci naštěstí vím (i když teda není moc vidět, že to vím). Takže i přispívání do diskuze si raději budu nechávat až na ráno Sorry za zmatkování.

[Jan Kundrát (jkt)]

Ach jo, mail s pripominkama jsem posilal 9. unora, lec odpoved neprisla, mno nic:

Nejak mi to pripomina http://www.gentoo.org/doc/en/prelink-howto.xml, vubec nevim proc :). At uz to aspon opise poradne, cili ze v $CFLAGS/$CXXFLAGS nesmi byt -fPIC, v $USE naopak musi bejt pic (to je spravne).

Mezi emerge --update --deep --newuse world a emerge -uDN world neni absolutne zadny rozdil, proto nechapu dvoji uvedeni tehoz (snaha o natahnuti clanku?). Proc se stale opakuje su -? Opet to nema vubec zadny vyznam.

Ad python a emerge - ten pythoni kod je spatne, protoze neni odsazen, takhle nebude fungovat.

Dale testovani "rychlosti emerge" pri tretim opakovani emerge -ep world je IMHO nesmyslne, protoze uz jsou tou dobou vsechny udaje nacachovane (cache Portage, ne disku), a navic rozdil 1 sekunda je, ehm, opravdu zanedbatelny. Kdyz uz, tak at si pohraje s emerge --metadata :) .

[Mikos]

Co já si tak z Gentoo pamatuju, tak hlavní problém pomalosti portage v některých operacích rozhodně není Python (to je dostatečně rychlý jazyk), ale způsob jakým portage s daty/metadaty pracuje (už si ale nepamatuju přesně v čem to bylo).

Tzn. Psycem se opravdu získá maximálně pár vteřin, ale to člověka zas tolik nevytrhne, když takový update databáze trvá třeba několik dlooouhých minut (osobní zkušenost z virtual serveru na Pipni.cz ). Snad dokonce existuje i nějaký projekt optimalizace portage (případně použití databázového backendu). V Pythonu bych opravdu problém neviděl, ale v tom jak portage pracuje s (meta)daty ano.

[Spike]

Problém s Psyco je, že sežere strašně moc paměti. Zkoušel jsem ho používat s Gajim'em a dopad byl děsivý. (Mám pouze 256 MB RAM.)

Jinak od té doby, kdy používám Portage 2.1, je update metadat ďábelsky rychlý (neměřil jsem, ale zdá se mi, že na svém Athlon XP 1600+, 256 MB DDR RAM@266 MHz s Portage 2.1 mám cache vytvořenou podstatně rychleji než na Athlon 64 3000+ (Socket 274) s 1 GB DDR RAM@400 MHz se stable Portage (2.0.54 nebo tak nějak)).

Schválně to zkusím změřit, teď se k tomu druhému počítači ale chvíli nedostanu. Třeba se mi to vážně jenom zdá, ale prostě u té 64 mám vždycky pocit, že vyrostu, než se ta cache vytvoří. ^_^;

Na tom Athlon XP 1600+

itsuki spike411 # time emerge --metadata

skipping sync

>>> Updating Portage cache:  100%



real    2m41.791s
user    0m15.869s
sys     0m9.891s

[Michal Čihař]

Ono taky se Psyco doporučuje používat jen na výpočetně náročné funkce a ne na celý program. Použitím na všechno obvykle mnohonásobně vzroste nárok na paměť s minimálním zrychlením běhu.

[Spike]

Ano, to jsem také četl.

Zkoušel jsem to i s Portage (tehdy nějaká verze 2.0.5x) a reálné zrychlení skutečně nic moc.

Dřív jsem měl Portage na reiserfs, teď ho mám na xfs, tak jestli to zrychlení také nemůže být tím, ale nezdá se mi to.

[J]

Presne tak, reseni existuje, je popsany na 4ech Gentoo, hledat portagedbcdb database

trebas http://forums.gentoo.org/viewtopic-t-261580-highlight-portagedbcdb+database.html?.

Sync je bleskovy, zadne minuty cekani.

[kavol]

hm, souhlas, při té rychlosti jsem jen nevěřícně kroutil hlavou ... kdo proboha normálně spouští emerge world třikrát? navíc největší brzda je imho disk, takže nějaká půlsekunda na samotném pythonu má jistě ohromný význam

jinak napotřetí u mě:

# time emerge -uDNpv world > /dev/null

real    0m15.605s
user    0m4.564s
sys     0m0.464s

procesor Athlon64 3000+, slušný kousek RAM, relativně rychlý disk, tak teda nevím, kde autor vzal ty svoje necelé tři sekundy ... žeby se o něčem zapomněl zmínit? jako třeba že si hrál s těmi metadaty nebo že používá unstable portage (jak bylo zmíněno výše, že 2.1 je rychlejší než 2.0.x)? není ten článek potom poněkud zavádějící???

[Věroš]

Psyco je pěkná věc, ale neporadí si se všemi programy. Třeba taková Cheetah bez úprav s Psyco nepoběží. Používá trošku agresivnější práci se stackframe, kterou psyco nepodporuje. V nové Cheetah je sice workaround, ale stejně se tím moc neušetří.

Psyco má smysl používat selektivně na jednotlivé programy, ne na celý systém. Autor programu ví nejlíp, co je v programu pomalé. Jak už někdo psal, Python je docela rychlý jazyk, úzká hrdla leží obvykle jinde. (I když - kdybych věděl o Psyco když jsem psal diplomku s neuronovými sítěmi, možná bych nemusel kódovat v C . )

[Kyosuke]

Měl jste zkusit Ocaml! Bylo by to rychlé a psalo by se v tom určitě líp...

[sudcadred]

Neviem, ci to chapem dobre - 5x som cital vetu "Prelink sa však nemusí nainštalovať, ak na prelinkovanie nemáte pripravený systém." Podla mna tam malo byt skor "Prelink sa však nemusí nainštalovať, ak na prelinkovanie MATE pripravený systém.".

Takze, ak som to pochopil dobre: - bud spravim emerge prelink a ten sa bude starat o rychly spustenie vsetkych aplikacii - alebo prekompilujem cely system s USE=pic (potom mozem ist na tyzden na Kubu:)))

dik za odpoved, ci tomu rozumiem dobre

[Michal Vyskočil]

Celé to vypadá jako překlad prelink howto. Ten prelink musíš mít nainstalovaný (jinak he pochopitelně nespustíš) a v USE musíš mít flag pic, programy přeložené bez něj nepůjdou prelinkovat.

[Spike]

V celém systému jsem našel dva balíky, které mají USE flag pic: glibc a gzip...

[Honza Jaroš]

...u mě ještě libsdl.

[David Watzke]

A uw-imap a c-client... předpokládám, že jde hlavně o glibc. Jednou jsem jí zkompiloval bez pic flagu a pak nešlo zkompilovat nic...

[zde]

Pokud glibc po zkompilování bez pic flagu nefunguje, jde nepochybně o její chybu (resp jednu z mnoha) nebo o chybu distribuce (dtto).

PIC flag je pouze rada pro GCC aby do RO sekcí nestrkalo žádné relokace. Pokud tam ale nějaká relokace přesto bude (např. pro některé moduly na -fpic zapomenu, nebo tam přilinkuju nějakou prasečinu v asm), měla by být knihovna stále plně funkční, pouze dynamický loader bude mít s touto knihovnou víc práce. Na pár RO stránkách zasažených relokacemi udělá COW faulty, takže každý proces bude mít vlastní verzi. Krom nepatrně vyšší spotřeby paměti by to ale nemělo nic podstatného měnit.

[SupuS]

No je to trochu divna veta .. :) Ja prelinkovani chapu tak, ze musis programy pripravit na to ze budou prelinkovany .. a to USE flagem pic ... pak stejne musis pustit prelink -aRmv .. takze odpoved na tvou otazku:

1. pridat USE="pic"

2. emerge -uDNv world

3. prelink -aRmv

hotovo :)

[Jirka]

Ja osobne bych -D nepouzival. Poskodi to zavislosti a pak se ve /var/lib/portage/worl objevi i baliky, ktere nebyly implicitne nainstalovany a to je hodne spatne. Kdyz updatovat world, tak jedine "emerge -uav world". Ono opravit /var/log/emerge.log, aby byl /var/lib/portage/world opet spravne vygenerovan pomoci /usr/sbin/regenworld, neni zas tak uplne trivialni.

[Jan Kundrát (jkt)]

Tohle jsi vzal kde? Neni to pravda, --deep ti rozhodne /var/lib/portage/world neposkodi.

[David Watzke]

To je pravda. Vhodný je ale dát si na emerge alias emerge --oneshot a do worldu přidávat jen to, co opravdu chci Tedy IMHO... můj styl aktualizace je následovný: esync -v a pak když vidím třeba novou glib, tak emerge -u glib.. no a díky aliasu se nepřidá do worldu, což je dobře, protože jí tam nechci a zároveň nechci spouštět emerge -avuNDt world.

[David Watzke]

To je pravda.

Chci říct.. máš pravdu, že nemá pravdu

[Jan Kundrát (jkt)]

To je pravda. Vhodný je ale dát si na emerge alias emerge --oneshot a do worldu přidávat jen to, co opravdu chci

Nerozumim - do worldu se pridava pouze to, co si "explicitne" nainstalujes, tj. vsecko, co instalujes jako emerge foo. Pokud balicek foo zavisi na bar a baz, tyhle dva so do worldu nepridaji. Lidi, ctete ty manualy...

Tedy IMHO... můj styl aktualizace je následovný: esync -v a pak když vidím třeba novou glib, tak emerge -u glib.. no a díky aliasu se nepřidá do worldu,

--update ti do worldu nic neprida

což je dobře, protože jí tam nechci a zároveň nechci spouštět emerge -avuNDt world.

Nejaky duvod (teda krome toho --tree, coz nepouzivam)?

[David Watzke]

Nerozumim - do worldu se pridava pouze to, co si "explicitne" nainstalujes, tj. vsecko, co instalujes jako emerge foo. Pokud balicek foo zavisi na bar a baz, tyhle dva so do worldu nepridaji. Lidi, ctete ty manualy...

Ve výstupu esync vidím novou glib a tak napíšu emerge glib, přestože jí nechci ve worldu. To co píšeš vím.

--update ti do worldu nic neprida

Tak tady je to můj omyl. Ale když nepoužiješ -u, tak přidá.

Nejaky duvod (teda krome toho --tree, coz nepouzivam)?

Protože to trvá a tohle vyjde rychleji. Když těch updatů není moc, což většinou není, protože aktualizuju často. Jinak důvod není, nemám v tom bordel. Třeba dneska jsem to udělal po patlání s GCC 4.1

[Jan Kundrát (jkt)]

Tak tady je to můj omyl. Ale když nepoužiješ -u, tak přidá.

Neprida. -u == --update

[David Watzke]

Ale když nepoužiješ -u, tak přidá.

Neprida. -u == --update

Já psal když nepoužiješ -u, tak přidá a za tím si stojím

[Marián Kyral]

A je nějaký důvod proč nepoužít emerge -uavtDN world ?

[David Watzke]

Třetí odstavec tady.

[Marián Kyral]

Stále nechápu. Nějaký názorný příklad by nebyl?

Co si pamatuju, tak jsem měl spíše problém s tím, že mi emerge --deepclean odinstaloval půlku systému, protože fůra věcí nebyla ve wold. Dal jsem jen emerge k3b krusader, což mi nainstalovalo taky KDE a X, ale ve worldu zapsány nebyly. A nezapsaly se ani při emerge -uavtDN world

Pak stačilo si poplést příkazy a napsat emerge --deepclean místo revdep-rebuild rebuild a ráno bylo vymalováno.

[David Watzke]

Zkrátka to trvá a tak se tomu snažím vyhýbat. Když řekneš emerge k3b krusader, zapíšou se do worldu k3b a krusader.

[SupuS]

Ja pouzivam -D vzdy ... bez negativnich nasledku .. a to uz asi 3 roky ... -D upgraduje i zavisle balicky .. nikde jsem o problemu, ktery popisujes necetl ..

[Lukáš Zapletal]

Portage je pomalý zejména díky intenzivním diskovým operacím (tisíce adresářů a mnoho malých souborů). Už se to Xkrát probíralo na různých diskuzních fórech a chatech Gentoo. V současné době se portage značně předělává a jeden programátor zanáší některé optimalizace do stávající stable řady.

Nejlépe vylepšíte rychlost speciálním oddílem na /usr/portage (bez distfiles) o velikosti max 1 GB, rychlým fs pro malé soubory a také použitím některých záplat (cdb a podobně).

Já osobně navrhuji, aby vývojáři zapracovali na optimalizacích databáze závislostí, vyčistili kód Portage a vážně zauvažovali nad tím, jestli je vůbec nutné stahovat celý strom na lokální dísk. Nic přece nebrání tomu, aby se ebuildy, manifesty a patche stahovaly až před vlastní kompilací. Už jsem to tu jednou zmínil - holt by to znamenalo upustit od rsyncu a vytvořit nějaký vlastní protokol dopravy závislostí na cílový stroj - to ovšem není nijak složité.

Nejdříve je však opravdu nutné přestavět celý program Portage - je to ukázka toho, jak se nemá programovat. Až bude modulární, dají se vymýšlet a zkoušet takovéhle nápady.

[J]

Link na cdb sem hodil vejs, ale to stim nestahovanim stromu bych nevidel jako reseni. System se nejak musi dozvedet ktery balicky muze nainstalovat a kdyby tam byla jen informace o baliccich a kvuli zavislostem by to melo otravovat na nejakym serveru .... to mi neprijde jako dobrej napad.

Spis prenest portage do DB (nebo to umoznit aspon jako oficialni alternativu). Ostatne pokud vim, nejpomalejsi operace je indexace.

[Lukáš Zapletal]

Portage do posledni chvile pred kompilaci IMHO nepotebuje adresar /usr/portage. Staci mu jen zavislosti a cache, ty by byly lokalne v nejake rychlejsi forme (databaze). Prenest po siti pri syncu se muze jen tato informace. Server by nikdo neotravoval, naopak. Kazdy uzivatel jej otravuje pri stahovani stromu a tisicu ebuildu a patchu, ktere vubec ani nebude nikdy potrebovat.

Oficialni alternativa - viz nize (muj komentar).

[J]

Ehm, /usr/portage jsou temer vyhradne jen zavislosti. V ebuildu je popis prave zavislosti a pak instalace (co, kam, jak). Obcas tam sou mensi patche.

Pri sync se prenasi pouze nove/rozdilne soubory a na bezne stanici kterou budu chtit udrzovat opravdu hodne aktualni mi staci sync 1x/den. Tech serveru poskytujicich portage je celkem dost a zatizeni je rozhodne nizsi, nez pri stahovani informaci pri kazde kompilaci. Muzu mit strom klidne tyden, 14 dnu, mesic stary a stale muzu kompilovat co chci, nemusim se nikam pripojovat.

Apropos, pokud se nemylim, kdyz vite ze nebudete nikdy pouzivat napr net-www, neni problem tento adresar ze sync vyhodit.

[Trained.Monkey]

Tady je navod jak pri vyhledavani pouzivat databazi a ne fs, zrychleni je kurva velke.

http://gentoo-wiki.com/Portage_CDB

PS: Arch je stejne lepsi :)

[Lukáš Zapletal]

Alternativou je modul cpickle, ktery je standardni soucasti verze .54 a nemusite ani nic patchovat. Zrychleni je vyrazne, mozna ne, jako v pripade cdb. Nicmene zda se, ze CDB je slepa ulicka - vyvojari jej nechteji do mainstreamu.

Nicmene Savior (Portage 3.0) vypada daleko lepe. Otazkou je, kdy bude hotov a nasazen.

[Jan Kundrát (jkt)]

Viz stranky projektu.

[Zdenek]

Super,

jeste zbyva par malych otazecek.

Kdyz musim rict KDE, ze bylo prelinkovano, tak to musim rikat i jinym aplikacim? Jak se nekteri zminili vyse, tak podporu prelinku z velkych aplikaci ma snad jen KDE. Tady http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2 je z jednoho vypisu poznat, ze mozilla podporu prelinku nema. Ted nemam gentoo, tak nemuzu poznat, zda je podpora prelinku u firefoxu, openoffice?

Prelink ma zrejme smysl jen pro molochy, jak jej tedy pri prelinkovani muzu aplikovat pouze na urcite aplikace? Jak jej tedy puzit pouze na vsechny baliky KDE?

[Spike]

Proč se nastavuje ta proměnná pro KDE se dozvíš v původním návodu http://www.gentoo.org/doc/en/prelink-howto.xml

If you inform KDE that it has been prelinked it will disable the loading of kdeinit (as it isn't required anymore) which speeds up KDE even more.

[Radomír Fojtík]

Kdyz musim rict KDE, ze bylo prelinkovano, tak to musim rikat i jinym aplikacim?

Myslíte tím KDE_IS_PRELINKED="true"? Dle "Gentoo Preling Guide" tímto zakážete natažení kdeinit, které není již třeba a zkrátíte tím start KDE jako takového. Rozumím tomu, že je to spíš takový "bonbónek".

Na druhou stranu, ačkoliv mám KDE prelinklé spolu s tou hodnotou TRUE, htop stejně hlásí jeden proces "kdeinit Running"

a dále několik málo dalších:

4 x  "kio http [kdeinit] http /tmp .... atd"
1 x  "kio pop3 [kdeinit] pop3 /tmp .... atd"
1 x  "kio file [kdeinit] file /tmp .... atd"

- takže nevím. Máte to snad jinak? Prelinkáči / neprelinkáči?

[David Watzke]

Kio_slaves snad znáš... http a file má třeba Konqueror a pop3 používá KMail... Jejich počet závisí na počtu otevřených tabů a tak...

[..... Izak .....]

No ja si pamatuji ze jsem zapomel prelik vypnout a pak mi nefungovala dobre multi-gnome-terminal, icewm, sekali se X windows, fur mi neco padalo na dost divne chyby .... windows hadra, linux naprosto nepouzitelny .... pak odprelinkovat a vse jelo OK bylo to v dobach FC1 nebo FC2 ....

Takze prelik je mozna zajimavy ale diky nechci. Kupodivu kdyz jej zapomenu vypnout v FC4 tak to chodi ... ale stejne jej vypinam.

Skouseno na AMD Athlon 1.8 nejspise vanila kernel ze zdrojaku.

[Red Dog]

Nebyl by někdo z Vás tak laskavý že by mi poslal live CD s Gentoo ? Stáhnul bych to ale Telecom mě omezuje limitem :-/ Nechci to samozřejmě zadarmo.

[Marián Kyral]

http://www.linuxsoft.cz/shop/?produkt=7172

[Red Dog]

Díky, ale neposílají zboží na dobírku. Tak až pojedu do Prahy.

[Marián Kyral]

Na dobírku sice ne, ale poštou ano

    * Zboží zasíláme poštou pouze na území ČR.
    * Z eBanky trvá převod obyčejně několik minut, 
      z jiné banky 2 dny, při platbě Českou poštou i 5 dní...
    * Číslo účtu: 984525028/2400 eBanka.
    * Poštovné a balné:
          o 70 Kč (S DPH) Menší objem (obálka)
          o 140 Kč (S DPH) do 5 [kg] (balík)
          o 200 Kč (S DPH) do 25 [kg] (balík)
          o V případě větších zásilek /servery, desktopy atd./ 
            je cena přepravy stanovena dohodou.
    * Nezasíláme na dobírku.

http://www.linuxsoft.cz/shop/?podminky

[Red Dog]

Šmankote jak jsem to tam četl ? To se omlouvám a zařídím to. Díky za nakopnutí

[zde]

Vy jste mi ale srandisti.. man gcc říká, že -fpic a -fPIC jsou pro i386 target identické.

If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC and 32k on the m68k and RS/6000. The 386 has no such limit.)

Taky mi není moc jasné proč chcete překompilovat VŠECHNO jako PIC, když samotné programy pro prelink být PIC nemusejí, a DSO jsou PIC defaultně (doufám že i na exotu Gentoo). Se mi tak nějak zdá že autor vůbec netuší jak prelink funguje.

Prelink si pouze z nalezených binárek a knihoven vytáhne dependency grafy, z nich spočítá které binárky a DSO jsou potřeba dohromady, podle toho přiřadí jednotlivým DSO preferred load address tak aby se nepřekrývaly, a upraví jejich relokace tak aby se při mapování knihovny na danou adresu nemusely aplikovat.

[Jan Kundrát (jkt)]

Vy jste mi ale srandisti.. man gcc říká, že -fpic a -fPIC jsou pro i386 target identické.

Vis, $CFLAGS a $USE neni az tak uplne to same...

[zde]

Ani v případě flagů 'pic' a 'PIC'? V tom případě by měl někdo autorům portage urgentně vysvětlit zásady principu nejmenšího překvapení.

[Jan Kundrát (jkt)]

bugzilla...

jkt@slon ~ $ grep pic /usr/portage/profiles/use.desc
pic - Build Position Independent Code.  Do not utilize this flag unless you know what you're doing.