abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 14:22 | IT novinky

    Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.

    Ladislav Hagara | Komentářů: 0
    včera 22:33 | Nová verze

    Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.

    Ladislav Hagara | Komentářů: 2
    2.5. 22:22 | Komunita

    Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).

    Ladislav Hagara | Komentářů: 0
    2.5. 19:11 | IT novinky

    Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.

    Ladislav Hagara | Komentářů: 3
    2.5. 11:22 | Zajímavý projekt

    Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.

    Ladislav Hagara | Komentářů: 2
    2.5. 09:11 | Bezpečnostní upozornění

    Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.

    Ladislav Hagara | Komentářů: 2
    1.5. 20:00 | Komunita

    V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.

    Ladislav Hagara | Komentářů: 3
    1.5. 19:22 | IT novinky

    Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).

    Ladislav Hagara | Komentářů: 0
    30.4. 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

    Ladislav Hagara | Komentářů: 0
    30.4. 17:44 | Zajímavý článek

    Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.

    karkar | Komentářů: 0
    Jaký filesystém primárně používáte?
     (57%)
     (1%)
     (9%)
     (22%)
     (4%)
     (2%)
     (3%)
     (0%)
     (1%)
     (3%)
    Celkem 516 hlasů
     Komentářů: 19, poslední 30.4. 11:32
    Rozcestník

    Občas není od věci vyslovit něco, za co se upaluje nebo ukamenovává. Nic není totiž tak jednoduché, aby byla pravda vždy jediná a na první pohled zřejmá.


    NAVRCHOLU.cz
    Kategorie zápisků
    Aktuální zápisy

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

    2.8.2006 00:40 | Přečteno: 1674× | Rouhání největší | Výběrový blog

    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):

    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á.

           

    Hodnocení: 88 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    Josef Kufner avatar 2.8.2006 02:14 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    Jaké jsou ony nevýhody prelinku?
    Hello world ! Segmentation fault (core dumped)
    Luk avatar 2.8.2006 10:56 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.
    Šifrování je absolutní nutnost a pomáhá chránit před nekalými živly
    2.8.2006 03:48 VícNežNic | skóre: 42 | blog: Spáleniště | Ne dost daleko
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.
    Copak toho není dost?
    2.8.2006 08:27 ajikdpoe | skóre: 23 | blog: dvh
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.
    2.8.2006 08:42 Luboš Luňák | skóre: 19 | blog: Seli
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.
    2.8.2006 08:39 Luboš Luňák | skóre: 19 | blog: Seli
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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
    2.8.2006 09:21 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    2.8.2006 10:31 Lubos Lunak
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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 avatar 2.8.2006 11:37 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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ší.
    Šifrování je absolutní nutnost a pomáhá chránit před nekalými živly
    3.8.2006 07:21 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.
    2.8.2006 11:38 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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?

    2.8.2006 12:02 Tom.š Ze.le.in | skóre: 21 | blog: tz
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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í?
    2.8.2006 12:06 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.

    2.8.2006 12:32 Tom.š Ze.le.in | skóre: 21 | blog: tz
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny

    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.

    2.8.2006 12:43 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny

    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.

    7.8.2006 12:14 Tom.š Ze.le.in | skóre: 21 | blog: tz
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.
    2.8.2006 12:02 Luboš Luňák | skóre: 19 | blog: Seli
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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 ... :-/
    2.8.2006 12:15 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny

    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í.

    2.8.2006 14:11 Luboš Luňák | skóre: 19 | blog: Seli
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.
    2.8.2006 14:46 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny

    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.

    2.8.2006 14:57 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny

    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.

    2.8.2006 23:40 hub | skóre: 26 | blog: bg
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.
    2.8.2006 16:00 zdenek
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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ý.
    2.8.2006 10:28 Miloslav Ponkrác | blog: miloslavponkrac
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.
    2.8.2006 10:34 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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) :-)
    When your hammer is C++, everything begins to look like a thumb.
    Luk avatar 2.8.2006 10:53 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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.
    Šifrování je absolutní nutnost a pomáhá chránit před nekalými živly
    2.8.2006 15:13 Miloslav Ponkrác | blog: miloslavponkrac
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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á.
    2.8.2006 21:45 disorder | blog: weblog
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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
    3.8.2006 01:19 Miloslav Ponkrác | blog: miloslavponkrac
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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á.
    3.8.2006 08:27 Luboš Luňák | skóre: 19 | blog: Seli
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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 avatar 3.8.2006 09:19 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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ě.
    Šifrování je absolutní nutnost a pomáhá chránit před nekalými živly
    msk avatar 8.8.2006 11:14 msk | skóre: 27 | blog: msk
    Rozbalit Rozbalit vše Re: Proč mám rád sdílené knihovny
    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) ).

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.