Proč mám rád sdílené knihovny

2.8.2006 00:40 | Přečteno: 1677× | Rouhání největší |

Občas se můžeme dočíst, že pomalost nějakého programu se dá odstranit tím, že se slinkuje "přímo do binárky". Je to nepříjemný omyl, o to horší, že jeho přijímáním se člověk připraví o celou řadu výhod, které poskytují sdílené knihovny.

Využíváme-li nějaký kód (funkci, objektovou třídu apod.) opakovaně, je vhodné ho umístit do knihovny. Máme v zásadě dvě možnosti: statickou knihovnu (která není v podstatě nic jiného než archiv objektových souborů), a knihovnu sdílenou (též dynamickou). Statická knihovna se použije při linkování, kdy se použitý kód stane součástí spustitelného souboru. Sdílená knihovna se sice při linkování použije také, ale kód v ní zůstane a o spojení se postará loader při spuštění programu.

Nejprve k oné pomalosti. Použití dynamické knihovny obecně nepřináší žádné významné zpomalení. Vzpomínám-li si dobře, tak volání funkce z knihovny znamená o dvě instrukce skoku více (znalce prosím, aby mě opravili, pokud se mýlím). U některých architektur to může být mírně jinak, ale nikoli výrazně. Proto zde o zpomalení příliš hovořit nelze.

Další věc, která by někoho mohla napadnout, je zpomalení při startu. Zde se jedná jednak o samotné načítání souborů (ve smyslu jeden versus více), kde ale opět není žádný problém. Pak je tu také relokace, ovšem k tady zase poslouží prelink, který upravuje umístění v adresním prostoru tak, aby nevznikala zbytečná relokační režie (ano, prelink má i své nevýhody, ale podle mého názoru výhody převažují).

Naopak používání sdílených knihoven může způsobit i zrychlení. Pokud totiž stejnou knihovnu používá více programů, načte se pouze jednou. Navíc je vyšší pravdědobnost, že se její kód udrží ve fyzické paměti a nebude odswapován.

Nyní uvedu hlavní důvody, proč mám sdílené knihovny tak v oblibě a nedám na ně dopustit (a snažím se každého přesvědčit, aby je používal):

• Menší objem. Kód je v systému pouze jednou, zabírá proto méně místa na disku i v paměti. Může to přinést i výhodu v rychlejším běhu (viz výše).
• Snadné aktualizace. Pokud se v kódu zjistí chyba, u sdílené knihovny to znamená vyměnit pouze tuto knihovnu - do programu se sahat nemusí (není nutné ho znovu linkovat). Je to tedy jednodušší, rychlejší a nemusí se přenášet velké objemy dat.
• Možnost explicitní manipulace. Pokud se program s knihovnou neslinkuje, nýbrž si ji sám načítá podle potřeby, nemusí se knihovna za běhu programu leckdy načíst vůbec. Lze ji také dynamicky uvolnit a bez restartu aplikace třeba nainstalovat novou verzi.
• Licenční záležitosti. Když je sdílená knihovna pod LGPL (nebo třeba GPL se zvláštní výjimkou), může být program pod libovolnou licencí. To při statickém slinkování nelze, což může být značně omezující.

Prostě považuji sdílené knihovny za výbornou věc a za metodu volby pro většinu případů opakovaně použitelného kódu. Tím samozřejmě nezatracuji možnost statického linkování (ať už přímo nebo ze statické knihovny), ale považuji ho za řešení pro speciální případy, např. pro velmi malé kusy kódu nebo tam, kde by byla manipulace se sdílenou knihovnou problematická.

       

Komentáře

[Josef Kufner]

Jaké jsou ony nevýhody prelinku?

[Luk]

Jsou dány hlavně tím, že zapisuje do příslušných souborů. Takže může vyvolat fragmentaci (viz níže v diskusi) a brání používání nástrojů, které kontrolují soubory, zda do nich někdo nezasáhl.

[VícNežNic]

Nevím kolik je to instrukcí, ale k té řežii ještě tolik, že ta funkce se musí ještě (při prvním volání) najít, což bude trvat podstatně déle než dvě instrukce. Ne, že by na tom nějak moc záleželo.

[ajikdpoe]

Ahoj.

Toto si priam pyta hello world ukazku. Myslim to vazne. Spravit jednu kniznicu s dvoma funkciami hello() a world(). Spravit z nej dynamicky linkovanu kniznicu a potom spravit nejaky ukazkovy program ktory tie dve funkcie zavola. Popripade namiesto hello a world nech vypise 5kb statickeho textu nech je vidno potom na velkosti toho execka ze ma menej ako 2x5kb lebo tie data su v tej kniznici. Zatial som robil len so statickymi kniznicami (.a). Vdaka.

[Luboš Luňák]

Problem je v tom, ze hello world ukazky tady casto vubec nereprezentuji prakticke pripady z reality. Ja jsem tedy liny to merit, ale klidne bych se vsadil, ze v tomhle hello world pripade budou staticke knihovny vyhodnejsi.

[Luboš Luňák]

Ty jo, takhle po ranu videt tohle, no to se proste neda odolat, jdu psat "Proc nemam rad sdilene knihovny" :).

Disclaimer (radeji tady nahore, pro jistotu): Uz nekolik let se krome jineho venuji i optimalizaci KDE, ktere hodne sdilene knihovny pouziva (a dost trpi nedostatky jejich implementace na Unixech), takze docela vim, o cem mluvim. A ano, v konecnem souctu je porad lepsi sdilene knihovny mit nez nemit (kdyby KDE pouzivalo staticke knihovny, tak snad na dnesnich normalnich pocitacich ani nepujde pouzivat), ale proste takovyhle oslavny zapis takhle po ranu ve me vyvolava vlnu sarkasmu.

Proc nemam rad sdilene knihovny

Obcas se muzeme docist ... ok, az tak daleko jit nemusim. Asi takhle: Slinkovani primo do binarky opravdu nektere veci vylepsuje:

• Volani funkci z jine sdilene knihovny je opravdu pomalejsi nez z te same binarky. Krom tech par instrukci navic pro skok pres PLT je tu ale treba jeste navic nastavovani registru pro PIC (adresovani nezavisle na umistneni v pameti), coz krom jeho nastavovani jeste navic zabere jeden registr (obzvlast vzacna vec na x86). Pokud se nepletu, PIC kod sam o sobe bezi asi o 10% (?) pomaleji, treba nvidia proto AFAIK odmita jejich libGL tak prelozit (proto s tim nefunguje dobre prelink). Navic skoky mezi sdilenymi knihovnami zabranuji nekterych optimalizacim, ktere by sly udelat v ramci jedne binarky.
• Zpomaleni pri startu. Byly casy, kdy nejvetsi cas spotrebovany pri startu KDE aplikace byl prave pri relokacich sdilenych knihoven [1]. Uz je to lepsi, ale porad je to vyznamna cast. Napr. OpenOffice porad tim travi udajne minimalne polovinu startovaciho casu[2].
• ELF, format sdilenych knihoven na Unixech, co se rychlosti tyka je docela spatne navrzena vec (navrzeno aby se to chovalo podobne jako staticke knihovny a navic v dobach, kdy snad nikdo ani takovou vec jako linkovani vuci 10 sdilenym knihovnam nedelal - my jsme byli ti, kdo si vyzrali prvni problemy s tim, ze to spatne skaluje na vetsi pocet vetsich knihoven). Treba pro kazdy jeden vyhledavany symbol se postupne prohledavaji vsechny sdilene knihovny, dokud se symbol nenajde -> kazda jedna dalsi sdilena knihovna pouzita programem ma vliv. A me jde trefit slak, kdyz vidim veci jako 14k velka libXfixes.so obsahujici zhruba 30 naprosto primitivnich funkci.
• Pamet - relokace sdilenych knihoven stoji nejen cas, ale i pamet - vsechny relokaci se musi nekam zapsat a navic pro kazdy proces znovu. Kazda KDE aplikace by kvuli tomuhle mela skoro 1MB nesdilene pameti, kdybychom na to nemely vlastni hack kdeinit, ktery se snazi ten problem omezit.
• Prelink je sice hezka myslenka, ale v soucasne podobe je to prakticky nanic. Je moc hezke, ze to funguje na jednodussi programy, kde to nema moc velky vliv, ale u velkych aplikaci to zase tak velka slava neni:
  • Nefunguje to s dlopen, takze treba u OpenOffice to je skoro nanic [2]. I KDE aplikace jsou hodne modularni, takze i tam je porad tenhle problem s rychlosti videt (v konecnem vysledku je lepsi s KDE pouzivat kdeinit nez prelink).
  • Prelink zpusobuje zvetseni knihoven, takze krom jineho zpusobuje i fragmentaci na disku. A, i pres ten casto omylany mytus "Linux defragmentaci nepotrebuje", je vykon Linuxu pri (nelinearnim) cteni z disku tak slaby, ze nejaka pomalost pri relokaci knihoven je potom uz jen detail. Stejne tak neni v uplne v poradku tvrzeni, ze zpomaleni nahravanim vice sdilenych knihoven neni zadny problem.
  • Pamatuji se, ze prelink ma jeste nejake dalsi problemy, ale nevim presne, co to bylo, musel bych se zeptat prislusnych lidi ze SUSE (prelink nikdy nebyl v SUSE defaultne zapnuty a ted se dokonce zvazuje jeho kompletni vyhozeni).

Vetsina z toho by byla spravitelna, alespon do rozumne podoby, jenze tam je potom zase drobny problem s tim, ze dotycni vyvojari casto tyhle problemy vubec nevidi, pokud tedy vubec jsou ochotni pripustit, ze existuji, navic casto trpi podivnymi predstavami o tom, jak by aplikace mely vlastne fungovat (Michael Meeks, ktery se snazi zrychlit start OpenOffice, tak nejak Ulrichu Drepperovi, maintanerovi glibc, nemuze prijit na jmeno; kernelovi vyvojari ze SUSE, po litem boji, konecne uznali, ze neco jako degragmenter by se mozna opravdu hodilo). Ironii je, ze uz i vyvojari GNOME zacinaji resit problemy se sdilenymi knihovnami (kdyby nekdo chtel vedet proc, staci porovnat "ldd | wc -l" na treba Nautilovi a Konqueroru).

Jinak, jak uz jsem rekl, v konecnem souctu je porad lepsi sdilene knihovny mit nez nemit, ten zbytek duvodu je samozrejme v poradku. Jen nejsou v poradku uplne vsechny.

[1]http://www.suse.de/~bastian/Export/linking.txt [2]http://sourceware.org/ml/binutils/2005-10/msg00436.html

[Michal Kubeček]

pohled z druhé strany

[Lubos Lunak]

V prvni rade, ja netvrdim, ze staticke knihovny jsou lepsi nez sdilene, sdilene jsou samozrejme obecne lepsi, ale rozhodne to neni takova idealni vec bez chyby, jak je to tu prezentovane (alespon jejich soucasna implementace, jak uz jsem rekl, spousta toho by sla spravit nebo alespon zlepsit). I v tomhle Drepperove dokumentu je vetsina z toho pravda, na druhou stranu to jenom potvrzuje moje tvrzeni, ze lide delajici tyhle nizkourovnove veci maji obcas divne predstavy o tom, jak by je vyssi vrstvy mely pouzivat.

"There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case." - Nikdy nerikej nikdy. Prikladu, kdy staticke linkovani je lepsi, se urcite par da najit:

• Security aplikace - schvalne se linkuji staticky, aby nesly pouzivat ty vyhody z toho seznamu typu LD_PRELOAD, ktere se najednou stavaji nevyhodami.
• Portabilita - Drepperovi evidetne unika varianta dynamickeho linkovani libc (coz vyresi vsechny jim zminovane problemy a nemelo by zpusobovat zadny problem s portabilitou) a statickeho linkovani zbytku kvuli portabilite.
• No a pak si staci nahore projit ten seznam problemu se sdilenymi knihovnami a ono se urcite jeste neco najde. Treba pro neco ve stylu tady navrhovaneho hello world pripadu by se staticke linkovani taky urcite hodilo.

[Luk]

A ano, v konecnem souctu je porad lepsi sdilene knihovny mit nez nemit ..., ale proste takovyhle oslavny zapis takhle po ranu ve me vyvolava vlnu sarkasmu.

Můj blog se jmenuje Kacířské myšlenky. Takže je to snad jasné, ne (tím spíš, že jsem to zařadil do kategorie Rouhání největší).

Sdílené knihovny samozřejmě trpí řadou neduhů. Ale některé výhody jsou tak drtivé, že je těžko něco převáží. Například ta snadná aktualizace - nedovedu si představit, že kvůli bugu např. v ZLIB budu muset přeinstalovat prakticky celý systém. Druhá drtivá výhoda je licenční, i když to ortodoxní zastánci free-SW neradi slyší.

[Aleš Kapica]

S přístupem p. Luňáka už chápu proč je KDE takové zvěrstvo jaké je. Nejde mi ani tak o funkčnost - nepoužívám, nekritizuji, ale co mi vždy silně vadilo, tak že kvůli sebemenší blbiny která vede k zvednutí release se updatuje skoro 200MB dat.

Když se to spojí s oním "win uživatelům na ruku jdoucím" vzhledem a funkčností, tak bych.. no ale to už raději spolknu. Bohužel neovlivním fakt že tu jsou na desktopech KDE, ačkoliv se z nich používá jen minimum věcí. Nejpoužívanější aplikace totiž jsou Thunderbird, Firefox, OpenOffice a Acrobat Reader (8-P)

Bohatě by jim stačilo XFCE.

[Michal Kubeček]

Volani funkci z jine sdilene knihovny je opravdu pomalejsi nez z te same binarky. … Pokud se nepletu, PIC kod sam o sobe bezi asi o 10% (?) pomaleji.

Nedalo mi to a rozhodl jsem se, že si vyzkouším, jak to vlastně je. Napsal jsem si zmíněný prográmek, který vypisuje, "Hello, world!" tak, že na každé slovo si zavolá knihovní funkci. Jedna verze používá staticky linkovanou knihovnu, druhý dynamicky. Pro zájemce jsou ke stažení zdrojáky. Testováno na Athlon 64 3500+ (CFLAGS='-march=k8 -m64 -O3 -fomit-frame-pointer', LDFLAGS='-s') z běžícího KDE, měřeny jsou celkové časy příkazem time. Prográmek vypisuje "hello, world!", tolikrát, kolik dostane jako parametr, byl opakovaně spouštěn for cyklem bashe (kromě třetího testu, kdy byl spuštěn jen jedou). Pro solidnější test by to samozřejmě chtělo věrohodnější metodiku, ale i tak jsou výsledky docela zajímavé:

iterací     parametr      static        dynamic
10^4        1             10.1±0.3      13.1±0.4
10^2        10^6          15.9±0.3      14.5±0.3
1           10^8          15.6±0.6      14.7±2.0

První řádek víceméně odpovídá tomu, že spuštění dynamicky linkované aplikace je o něco pomalejší, hodnota 0.3 ms ale IMHO není nějak závratně vysoká. Zajímavější jsou ale další dva řádky, které naznačují, že v tomto konkrétním případě je volání funkce z dynamicky linkované knihovny v průměru rychlejší. Je tu samozřejmě rozdíl v tom, že kód dynamické knihovny byl překládán s -fPIC, ale to by podle vašich slov mělo také vést spíš k jeho zpomalení. Něco by mohl nasvědčovat i poměrně vysoký rozptyl hodnot u třetího testu (zvláště u dynamicky linkované verze) - jako by záleželo na tom, kam se relokace "trefí".

Mohl by někdo zkusit totéž na jiném systému?

[Tom.š Ze.le.in]

Plácnu od boku: měří opravdu prográmek rychlost práce procesoru a režii volání paměti, nebo spíš rychlost výstupu (která by neměla být až tak závislá na způsobu linkování - i když data naznačují něco jiného)

Pro testování režie volání bych zkusil volat jednoduchou funkci typu htonl, kde by režie mohla být vůči samotnému provedení nezanedbatelná (pokud se to přímo neinlinuje).

Pro testování proklamovaného 10% zpomalení uváděného jako důsledek chyubějícího registru bych zkusil něco, kde jsou registry potřeba - více lokálních proměnných či tak něco. Uvedený příklad možná všechny registry nevyčerpá. A nejsem si teď jist, zda se to zpomalení netýká jen kódu knihovny přímo překládaného s -fPIC.

A možná nechápu metodiku, ale jak se počítá směrodatná odchylka z jednoho měření?

[Michal Kubeček]

měří opravdu prográmek rychlost práce procesoru a režii volání paměti, nebo spíš rychlost výstupu

Výstup šel v obou případech do /dev/null a byl realizován stejnými funkcemi. Takže tady by rozdíl být neměl.

A možná nechápu metodiku, ale jak se počítá směrodatná odchylka z jednoho měření?

Měření nebylo jedno, u prvních dvou řádků byla tři, u posledního devět. Samozřejmě pro větší vypavídací hodnotu by bylo potřeba udělat měření více (a odfiltrovat zátěž generovanou zbytkem systému), ale jako námět k zamyšlení stačí i tohle.

[Tom.š Ze.le.in]

Měření nebylo jedno, u prvních dvou řádků byla tři, u posledního devět. Samozřejmě pro větší vypavídací hodnotu by bylo potřeba udělat měření více (a odfiltrovat zátěž generovanou zbytkem systému), ale jako námět k zamyšlení stačí i tohle.

Aha, myslel jsem, že "iterací" je počet měření - už to chápu.

Výstup šel v obou případech do /dev/null a byl realizován stejnými funkcemi. Takže tady by rozdíl být neměl.

Nečekal jsem tady rozdíl, ale spíš zašumění všech ostatních rozdílů takovým způsobem, že budou nepozorovatelné :)

Tenhle výsledek mne každopádně trochu překvapil (můj tip by byl, že časy vyjdou nastejno v rámci chyby měření). Asi se na to večer podívám a zkusím to trochu vyprofilovat. Pořád bych si totiž vůbec nejsem jistý, co se vlastně měří. Časová úspora může být způsobena natahováním většího programu (i když se nejspíš cachuje) - jaké jsou velikosti programů?

Uvedený čas je předpokládám reálný čas? Možná by ostatní časy naznačily, kde se tráví většina doby.

[Michal Kubeček]

Dynamická verze má 5192 B, statická 517736 B. Všechno je vzhledem k velkému počtu opakování samozřejmě z cache. Tabulky ukazují reálný čas, tedy přesněji elapsed time - zkusím to ještě předělat, aby se měřil skutečně jen vlastní user+system čas relevantních procesů, ale vzhledem k tomu, že ten systém jinak vykazuje zátěž procesoru pod jedno procento, nemělo by to na celkovém vyznění nic zásadního změnit.

Co se týká rozložení user/system, u prvního testu činí system něco kolem 6 sekund u statických, kolem 8 sekund u dynamických, u druhého testu je v obou případech lehce přes 0.1 :s a v posledním pod 0.1 s.

[Tom.š Ze.le.in]

Jak jsem už psal, měl jsem výhrady k některým aspektům testu, a tak jsem zkusil testování upravit. Shrnutí: pozoruji stejné chování jako Vy - sdílená knihovna běhá (při delším běhu) rychleji, ať dělám co dělám. Pořád mne to překvapuje, ale žádné hypotézy o příčině mi nezbyly :)

1. Nelíbilo se mi, že test spočívá v podstatě v I/O. Změnil jsem testovací funkce na volání fuknce crypt () se solí typu "$1$neco", což by IMHO mělo vytěžovat hlavně procesor. Žádná kvalitativní změna v pozorovaných datech.

2. Zvažoval jsem, zda není libc (a vzhledem k výsledku předchozího testu i crypt) knihovna různě optimalizovaná pro statické a dynamické linkování. Zavedl jsem komplikovanější výpočet přímo ve volané funkci a nechal linkovat staticky/dynamicky pouze novou knihovnu. Žádná kvalitativní změna v pozorovaných datech.

[Luboš Luňák]

Jenze ten test nerika vubec nic, protoze je spatne a vlastne meri rychlost vypisovani textu "hello, world!".

• casu dominuje samotne vypisovani toho textu, takze nejake instrukce pri skoku do sdilene knihovny pres PLT se v tom naprosto ztrati
• pomaly start kvuli sdilenym knihovnam je videt pri pouziti vetsiho poctu vetsich knihoven, treba jako v KDE, pri pouziti jedne miniaturni knihovny se to zase ztrati
• navic, jestli dobre chapu, ze ta cisla jsou doby behu programu v ms, tak to jsou tak mala cisla, ze cokoliv merene bude silne ovlivnovane sumem

Holt prace na optimalizacich neni zadna trivka ... :-/

[Michal Kubeček]

Ad 0. To sice měří, ale rychlost knihovní funkce fputs() i driveru zařízení /dev/null je v obou případech stejná. Jediný rozdíl je v tom, že v jednom měření je libwords i libc linkována staticky, ve druhém dynamicky.

Ad 1. Byl jste to vy, kdo dnes v 8:42 napsal: "Ja jsem tedy liny to merit, ale klidne bych se vsadil, ze v tomhle hello world pripade budou staticke knihovny vyhodnejsi."? Byl jste to vy, kdo dnes v 8:39 jednoznačně tvrdil, že je jasné, že volání funkce z dynamicky linkované knihovny bude pomalejší než ze staticky linkované knihovny? Pokud ano, míč je na vaší straně.

Ad 2. To samozřejmě ano, ale bude to tak významné, aby to vyvážilo zpomalení dané větším spustitelným souborem? Bude to tak významné, aby byl rozdíl pozorovatelný (tj. řekněme aspoň jedna sekunda)?

Ad 3. Časy jsou v sekundách, měření bylo vícekrát opakováno (proto jsou tam i odchylky). Ano, pro solidní závěry by bylo potřeba metodiku trochu vylepšit. Ale tak nevěrohodné, abyste nad tím bez přemýšlení mávnul rukou, to rozhodně není.

[Luboš Luňák]

0) Hmm, pravda - no jo, splest se u tohohle jde strasne snadno. Stejne tak asi slo snadno se splest u toho mereni, chyba pak proste musi byt nekde jinde. U me staticka verze potrebuje jen 80% casu te dynamicke a porovnani assembleru ukazuje peknych par instrukci navic v dynamicke verzi. To je 32bit x86, tam hodne vadi ten zabrany registr a nastavovani PIC. 64bit x86_64 ma hodne dobrou podporu pro PIC (udajne AMD pro to pridali specialni instrukci po konzultacich s gcc lidmi ze SUSE, kteri na tom pracovali), takze tam se jen v assembleru vymeni jedna instrukce za druhou slozitejsi. I tak je to porad tady drobet pomalejsi. Proste pouzivani kodu ze sdilene knihovny za behu musi byt alespon trochu pomalejsi, z principu.

2) Tezko rict, ani tohle se mi nechce merit. Navic na tom nezalezi, pointa je proste to, ze tenhle test to vubec nemeril.

[Michal Kubeček]

Tak jsem dopsal měřič, který provede n měření, každé spočívá v tom, že se n_iter-krát (první sloupec) spustí program s parametrem param a změří se celkový čas (user, system, součet). Výstupem jsou pak hodnoty průměru a střední odchylky pro user, system a total (total je user+system, takže to na rozdíl od původních výsledků neovlivňuje zbytek systému). Výsledky:

iterací verze         param      n   u_avg    u_dev  s_avg    s_dev  t_avg    t_dev 
 100000 ./hw-static   1          10   3.078   0.126  15.024   0.236  18.102   0.222
 100000 ./hw-dynamic  1          10  13.942   0.307  29.101   0.535  43.043   0.441

    100 ./hw-static   1000000    10  14.956   0.568   0.046   0.010  15.002   0.561
    100 ./hw-dynamic  1000000    10  13.798   0.195   0.075   0.021  13.873   0.194

      1 ./hw-static   100000000  10  16.300   0.136   0.032   0.016  16.332   0.125
      1 ./hw-dynamic  100000000  10  14.993   2.051   0.048   0.010  15.041   2.054

Výsledky prvního testu, kdy převažuje režie spouštění programu, teď vypadají daleko přesvědčivěji pro statickou verzi, ale je to je dáno tím, že se zredukovala režie bashového cyklu, rozdíl zůstává přibližně na stejné hodnotě jako předtím (0.25 ms na jedno spuštění).

Výsledky druhého a třetího testu opět vycházejí lépe pro dynamickou verzi. Rovněž se opakuje obrovský rozptyl hodnot u dynamické verze ve třetím testu. Pohled na jednotlivé hodnoty pak ukazuje, že nejsou rozprostřeny nijak rovnoměrně, ale spíše "ode zdi ke zdi". To podporuje hypotézu, že záleží na tom, kam se při daném spuštění programu s knihovnou "trefíme".

Balíček je ke stažení tamtéž, co předtím. Pro testy na pomalejších procesorech doporučuji hodnoty trochu snížit.

[Michal Kubeček]

Tak ještě jedny výsledky, tentokrát z druhého počítače:

iterací verze         param      n   u_avg    u_dev  s_avg    s_dev  t_avg    t_dev
 100000 ./hw-static   1          10   3.486   0.077  15.017   0.135  18.503   0.174
 100000 ./hw-dynamic  1          10  15.889   0.391  30.366   0.248  46.255   0.384

    100 ./hw-static   1000000    10  14.701   0.085   0.086   0.017  14.787   0.083
    100 ./hw-dynamic  1000000    10  15.708   0.094   0.088   0.021  15.796   0.091

      1 ./hw-static   100000000  10  16.219   0.597   0.051   0.016  16.270   0.588
      1 ./hw-dynamic  100000000  10  18.592   1.970   0.074   0.027  18.666   1.966

Tentokrát druhý a třetí test vycházejí opačně, jinak je vše velmi podobné. Přitom jediný rozdíl je v procesoru (první byl Athlon 64 3500+ se starším 130 nm jádrem, tohle je Athlon 64 3000+ s 90 nm jádrem Venice). Základní deska je stejná, operační systém také (SuSE Linux 10.1), jen na prvním počítači byl test spouštěn z běžícího KDE, zatímco na druhém z textového terminálu v runlevel 3.

[hub]

Přidám svůj výsledek:

iterací verze           param             n   u_avg    u_dev  s_avg    s_dev  t_avg    t_dev
 100000 ./hw-static     1                 10   2.601   0.073  12.295   0.119  14.896   0.090
 100000 ./hw-dynamic    1                 10  12.963   0.083  24.959   0.140  37.922   0.148

    100 ./hw-static     1000000           10  20.427   0.030   0.098   0.022  20.525   0.023
    100 ./hw-dynamic    1000000           10  25.862   0.335   0.104   0.027  25.966   0.321

      1 ./hw-static     100000000         10  20.802   0.375   0.090   0.010  20.892   0.371
      1 ./hw-dynamic    100000000         10  27.377   2.681   0.066   0.020  27.443   2.679

Procesor, který si dal tu práci byl Athlon 64 3000+ (jádro Manchester, tj. 130 nm). Operační systém, pod kterým jsem to zkoušel, je Debian testing (i386) a také to bylo spuštěno z běžícího KDE.

[zdenek]

Plný souhlas.. asi takhle: dynamické linkování by byla super věc, kdyby fungovalo jak fungovat má. Funguje blbě, protože:

1) x86 neumí PC-relativní load a store instrukce, musejí se složitě emulovat, což znamená typicky 4 instrukce navíc v prologu a epilogu funkce, a jeden registr v háji.

2) ELF vždy hashuje jméno funkce, neumí rychlejší bind přes ordinální čísla. Navíc je ten elf hash dosti pomalý, a neumí hierarchická jména (namespaces). V kombinaci s velmi neefektivními manglovanými C++ jmény je výsledek malá katastrofa.

3) PLT má zbytečně velkou režii- přidává jeden přímý a jeden nepřímý skok. Například ve windows je režie podstatně menší- tam je pouze přímý skok změněn na nepřímý.

[Miloslav Ponkrác]

Mimochodem, právě některé zmíněné výhody jsou pro mě nevýhodami.

Třeba možnost, aby někdo cizí vyměnil knihovnu, což v praxi dopadá často tak, že začnou chyby úplně jinde, protože nová verze knihovny jen málokdy pouze opraví chybu, ale udělá řadu jiných zásahů. Nehledě na to, že třeba v případě knihoven pro jazyk C++ je nutné použít také stejný kompilátor, stejné volby kompilátoru a kompatibilní verzi, jinak to sletí. Právě toto je pro mě důvodem, proč omezit používání sdílených knihoven.

Jinak sdílená knihovna prakticky vždy zvětší spotřebu paměti, pokud běží jen jeden program, který jí využívá. Je to proto, že sdílená knihovna obsahuje vždy i věci, které program nepotřebuje, a které by při statickém linkování v programu vůbec nebyly.

[Michal Vyskočil]

Nehledě na to, že třeba v případě knihoven pro jazyk C++ je nutné použít také stejný kompilátor, stejné volby kompilátoru a kompatibilní verzi, jinak to sletí.

Anebo si člověk musí naimplementovat vlastní komponentový model (už jsem s takovým programem dělal)

[Luk]

což v praxi dopadá často tak, že začnou chyby úplně jinde, protože nová verze knihovny jen málokdy pouze opraví chybu, ale udělá řadu jiných zásahů

Jenže za to nemůže knihovna, ale vývojář, který takhle prasí.

Nehledě na to, že třeba v případě knihoven pro jazyk C++ je nutné použít také stejný kompilátor, stejné volby kompilátoru a kompatibilní verzi, jinak to sletí.

O tomhle jsem tu už kdysi psal a byl jsem za to některými lidmi i dost nevybíravých způsobem kritizován. Ale pořád to není dostatečný důvod, proč se sdílených knihoven bát.

[Miloslav Ponkrác]

Jenže za to nemůže knihovna, ale vývojář, který takhle prasí.

No samozřejmě, za všechno můžou programátoři, kteří neumí něco naprogramovat bez chyby. Je tu jenom takový drobný háček, zatím se ještě nenašel programátor, který by napsal absolutně bezchybný program. Takže utopická hesla jsou prima věc.

Jinak samozřejmě na to, aby se dala přímo nahradit knihovna je potřeba taky tu knihovnu přeložit se stejnými volbami a splnit řadu dalších podmínek, které občas vývojáři ani neovlivní. Takže já náhradu za jinou verzi nevidím až tak reálnou a bezproblémovou, jak se tu naznačuje. Naopak je dost riskantní operace pro toho, kdo si cení svých dat.

A pokud chcete spolehlivý program a otestujete ho se svojí knihovnou, tak potom samozřejmě nemůžete zaručit tu samou funkčnost s jinou verzí knihovny, kterou tam někdo nabastlí. Zákazník pak samozřejmě vinu klade na autora programu, nikoli na svojí blbost, že si vyměnil knihovny. Ne náhodou proto mnoho programátorů kontroluje, zda sdílené knihovny jsou ty, které tam dodal a pokud ne, odmítne se spustit. Pokud někdo po mě chtěl funkční program, detekuji po spuštění programu zda někdo nevyměnil sdílené knihovny a v případě, že ano, program končí s chybovou hláškou.

O tomhle jsem tu už kdysi psal a byl jsem za to některými lidmi i dost nevybíravých způsobem kritizován. Ale pořád to není dostatečný důvod, proč se sdílených knihoven bát.

Je to naprosto zřejmý důvod proti sdíleným knihovnám. To není o strachu a nich, ale o reálné zvážení pro a proti. Mimochodem, dokážu si představit sdílenou knihovnu i v C, která při překladu jinými volbami se stane nekompatibilní.

P.S.: A to nemluvím o tom, že z hlediska bezpečnosti a dalších věcí jsou sdílené knihovny hazard. Já dnes tvořím sdílené knihovny jen ze dvou důvodů - buď licenční problémy stylu LGPL, a nebo prostě tvořím mnoho programů se stejnou knihovnou, ale i tam leckdy dám přednost statickému linkování.

Mít jeden program ze svými specifickými sdílenými knihovnami, které se v jiných projektech nepoužijí zase používám jen tehdy, pokud jsou to pluginy, jinak zase statické linkování.

Neříkám, že jsem proti sdíleným knihovnám, ale odsaď pocaď. Sdílené knihovny jsou nebezpečnější, pomalejší, zabírají více paměti, pokud je náhodou nepoužívá více programů, způsobují mnoho problémů s nekompatibilními verzemi. Naproti tomu jsou báječné jako prostředek pro základní API systému a hojně používaných standardních API, taktéž jako prostředek pro pluginy. Ale rada stylu používejte je vždy a všude je dosti jednostranná.

[disorder]

takze by som mal svoje programy sirit len v binarnej forme so statickymi kniznicami alebo aj so zdrojakmi vsetkych kniznic a skriptom, ktory to spravi, tak ako som to otestoval ja? pekne

[Miloslav Ponkrác]

Není třeba zacházet do extrémů. Jen je třeba upozronit pana Luka na mírné nepřenosti v jeho argumentacích a ukázat opačnou stránku.

Můžu přidat další nepřenosti, jen prostě se nechci upsat, třeba:

Možnost explicitní manipulace. Pokud se program s knihovnou neslinkuje, nýbrž si ji sám načítá podle potřeby, nemusí se knihovna za běhu programu leckdy načíst vůbec.

Toto je sice pravda, ale úplně to samé platí i pro staticky linkované programy. Každý slušný operační systém stejně zavádí a načítá do paměti jen to, co se provádí a kód, který se nikdy neprovede nemusí být vůbec načten. Takže tohle není výhoda sdílených knihoven ačkoli to autor říká.

[Luboš Luňák]

Toto je sice pravda, ale úplně to samé platí i pro staticky linkované programy. Každý slušný operační systém stejně zavádí a načítá do paměti jen to, co se provádí a kód, který se nikdy neprovede nemusí být vůbec načten.

Kdepak, kazdy slusny operacni system naopak se snazi cist z disku ve vetsich blocich, aby se pri strankovani do pameti neuseekoval k smrti (nebo spis k pomalosti). Bohuzel Linux+glibc k nim bez opatchovani nepatri :(.

[Luk]

Možná jsem se nevyjádřil dostatečně přesně. Měl jsem samozřejmě na mysli možnost načítat knihovny pomocí dlopen(). Hodí se to pro programy, kde hlavní program (ve spustitelném souboru) obsahuje jen základní funkcionalitu, kdežto všechno ostatní (třeba velice různorodé věci) je v knihovnách a málokdy se používají věci z různých knihoven současně.

[msk]

takze by som mal svoje programy sirit len v binarnej forme so statickymi kniznicami alebo aj so zdrojakmi vsetkych kniznic a skriptom, ktory to spravi, tak ako som to otestoval ja?

Takymto "uzasnym" smerom sa pobrali programatori studia Wired, ktore sa nedokaze prelozit na ziadnej distribucii bez rekompilacie/upgradu niektorych kniznic. Fakt nadhera, ked to clovek chce zbuildit ( nie ze by to uz fungovalo, ale zvedavost neda spat :o) ).

Píšeme jinde

ISSN 1214-1267   www.czech-server.cz

Redakce | Inzerce | Podmínky použití | Osobní údaje

© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.