Programovani - shared libraries na Linuxu

Středa Září 5 21:14:37 CEST 2001

Pavel Kankovsky wrote:

> On Wed, 5 Sep 2001, Martin `MJ' Mares wrote:
> 
>> [1]  | 08048000-08049000 r-xp 00000000 03:06 540904     /tmp/test
>> [2]  | 08049000-0804a000 rw-p 00000000 03:06 540904     /tmp/test
>> [3]  | 40000000-40014000 r-xp 00000000 03:06 34469      /lib/ld-2.2.4.so
>> [4]  | 40014000-40015000 rw-p 00013000 03:06 34469      /lib/ld-2.2.4.so
>> [5]  | 40015000-40016000 rw-p 00000000 00:00 0
>> [6]  | 4001c000-40132000 r-xp 00000000 03:06 34472     
>> [/lib/libc-2.2.4.so
>> [7]  | 40132000-40138000 rw-p 00115000 03:06 34472     
>> [/lib/libc-2.2.4.so
>> [8]  | 40138000-4013d000 rw-p 00000000 00:00 0
>> [9]  | bfffe000-c0000000 rwxp fffff000 00:00 0
> [...]
>> [5] je podle vseho pamet alokovana za behu dynamickym linkerem (ten jeste
>> nemuze pouzivat normalni malloc(), tudiz si naalokuje svou vlastni
>> stranku na data), [8] jsou ostatni malloc()-em alokovane promenne (neni
>> mi ovsem jasne, kde se jich vzalo tolik; podezrivam stdio) a [9]
>> zasobnik.

 Clovek se porad uci, tohle neznam. A koukam k tomu v dokumentaci kernelu 
ani nemuzu najit dokumentaci. No, kazdopadne, pro treba tu zminovanou 
libkdeui to vypada asi takhle :

40245000-40248000 rw-p 000aa000 03:02 164498 libksycoca.so.3.0.0
40248000-40433000 r-xp 00000000 03:02 164494 libkdeui.so.3.0.0
40433000-4044b000 rw-p 001ea000 03:02 164494 libkdeui.so.3.0.0
4044b000-4044d000 rw-p 00000000 00:00 0
4044d000-4046f000 r-xp 00000000 03:02 164495 libkdesu.so.1.0.0

Cesty ke knihovnam jsem usekal, at se to vejde na radek. Takze, jestli to 
dobre chapu, rozdil tech prvnich dvou cisel je zkratka velikost pameti pro 
ten blok. Zbytek cisel nechapu, ale to je ted asi fuk. Pro ta 
(potencionalne, ale povetsinou i realne) nesdilena data, zhruba 100kB.

> 
> Mensi oprava: [8] je spis z vetsi casti (ne-li uplne) .bss od glibc, nez
> dynamicky alokovana pamet -- pokud se neco nezmenilo, tak glibc by male
> bloky (a takovych alokaci je asi vetsina) umistovalo za [2] (brk()).
> Ostatne velikost .bss zaokrouhlena na cele stranky je u glibc 2.2 asi tech
> 5 stranek.
> 
>> [1], [3] a [6] jsou urcite sdilene; [5], [8] a [9] urcite nesdilene;
>> [2], [4] a [7] by mohly byt sdilene, pokud do nich jeste nikdo nezapsal,
>> ale u vetsiny z nich (mimo casti [7]) to neni moc pravdepodobne.
>> Celkem tedy 16 stranek potencialne nesdilene pameti po 4KB.
> 
> Pohled do /proc/*/statm (posledni cislo "dirty pages"...pozor: nemusi
> nutne davat smysl, kdyz se zacne swapovat) odhali, ze ve skutecnosti je
> je to asi jen 14 stranek. (Tedy "jen"...stare ZX Spectrum se 48 kily RAMky
> by s tim melo problemy... :> )

 Celych 223 stranek pro program slinkovany s -lkparts (tj. asi 30 knihoven).

> 
>> >  Jednu z tech knihoven (libkdeui) jsem dokonce rucne kontroloval,
>> >  nenasbira
>> > se tam ani na 4kB globalnich promennych a podobnych veci, pritom
>> > libkdeui dela rozdil 100kB, takze 96kB z toho jde na vrub tomu, co
>> > vyplodi gcc a binutils. No neni to nadhera ? Pak ze KDE team pise
>> > neoptimalizovany kod a trapaci v ruznych prispevcich vsude mozne trousi
>> > blbosti o minimu 256MB na beh KDE a podobne.
>> 
>> Ehm, myslim, ze by Vasim nazorum prospelo, kdybyste se nejdrive podival
>> (napriklad stejnou metodou, jakou jsem ja pouzil vyse), co tu pamet
>> _opravdu_ zabira a pripomenul si, ze existuje i dynamicky alokovana
>> pamet a ze na to, aby se pouzila, neni potreba ani explicitne zavolat
>> jakoukoliv funkci z prislusne knihovny, nebot (i v gcc, nejen v C++)
>> existuji i konstruktory.

 Uz jsem si tu namahu takhle prospet svym nazorum dal drive. Kontroloval 
jsem tu libkdeui rucne, kod primo generovany ze zdrojaku neda dohromady 
10kB, ani kdyby se na hlavu postavil.

> 
> Take existuji veci jako .got a .plt, ktere zrovna u toho libkdeui zabiraji
> odhadem tam 30 kilo a narozdil od glibc je mala sance, ze by mohly byt
> konstantni, protoze nejmene 1000 symbolu v .dynsym je nedefinovanych,
> a tudiz bude muset dyn. linker udelat zhruba stejny pocet relokaci.
> (I kdyz u toho .got nevim, jestli se nemusi relokovat vzdycky.)
> 
>> > nebo jak skvele konstatni je v ELF PIC kodu vec
>> > jako 'const char* const txt[] = { "raz", "dva" };',
>> 
>> Uznavam, nic moc ... Vite o nejakem lepsim reseni?
> 
> V zasade by melo jit udelat neco takoveho:
> 
> static const char base[1];
> static const char s1[] = "raz";
> static const char s2[] = "dva";
> static const ptrdiff_t txt_off[] = { s1-base, s2-base };
> 
> a misto txt[i] psat (base+txt_off[i]). :)

 C programatory tohle mozna bavi, ale ja bych rad delal i neco uzitecneho. 
Kdybych se chtel takhle bavit, zustanu u assembleru. Jinak neco takovehleho 
mozna skonci v Qt3, protoze tam se generuji kvanta takovych poli.

> 
> Jinak se opravdu neda vyhnout absolutnim adresam, ktere nemohou byt
> v pripade PIC kodu "konstantni"...at uz je to ELF nebo neni.
> 
> (Jina vec je, ze gcc mi na tom stejne drzkuje, ze rozdil sN-base neni
> konstantni, coz ale nema tak uplne pravdu.)
> 
>> Jen sam urcite ne, ale tomu, ze z 90% sam, bych uz klidne veril :-)
>> Nevim, jak StarOffice, ale Mozilla je opravdu priserny bloatware ...
>> za vse mluvi jedna veta z ChangeLogu ve stylu "prave jsem usetril
>> 400000 alokaci pameti pri startu, coz je asi 20%" :-)

>>Kdyby to naivni tvrzeni nahore byla pravda, KDE na 64MB masine lita jak z 
>>praku. A kdyby v KDE nebyl nejaky ten workaround na tahle priserna cisla, 
>>nejspis by se na 64MB masine nedalo pouzivat naprosto vubec.
>
>Souhlasim, ale s vyjimkou toho, kdo za ta priserna cisla muze :-)

 Tahle veta si ale sama sobe odporuje :).

> 
> Strasny problem tehle programu spociva v opojeni C++ konstruktory.
> Vysledek je ten, ze maji jakasi staticka konstantni data, ktera pri startu
> pomoci konstruktoru prezvykaji na jine datove struktury, coz 1. trva
> dlouho, 2. sezere strasne moc pameti na neco, co uz v te pameti vlastne
> je, akorat se to prelozi do jine formy.

 Viz. jinde. Jestli nejake opojeni bylo, tak uz davno preslo, konstruktoru 
tam je minimalne. Navic podle ISO C++ se nemusi konstruktory volat hned po 
nahrani knihovny do pameti; kdyz se pro nektere nepotrebne objekty 
konstruktor nezavola pri behu programu vubec, je to naprosto v poradku.

>>pripadne o tom ze kazda 
>>KDE aplikace spotrebuje pres 100kB pameti pri inicializaci XIM ( to je 
>>takova vec, ktera je pro nas dobra asi jen na to, aby fungovaly mrtve 
>>klavesy ),
>
>A neni to jen a pouze priznak toho, ze by se nekdo mel podivat na zoubek 
>XIM?

 Asi je.

>>(jinak, to je dobry eufemismus rikat 3 sekundam pri startu textoveho 
editoru
>>na pentium200 'trochu problem' - jeste i na Thurderbirdu850 je to skoro
>>sekunda).
>
>A jaky textovy editor mate na mysli? A je to uz z cache nebo z disku?
>Pokud z disku, nejspis to vubec nezavisi na rychlosti procesoru -- zatim
>jsem to poradne nemeril, ale odhaduji, ze tehdy se vetsinu casu ceka
>na pristupy k disku, ktere jsou bohuzel "diky" on-demand loadingu
>vice mene nahodne. Mozna by stalo za pokus pouzit na spustitelne programy
>a knihovny nejaky vetsi prefetch, myslim, ze by mohl vyrazne pomoci.

 Spousteno nekolikrat za sebou, pak uz je to vsechno z cache, CPU jede na 
maximu. Dynamicky loader se zkratka poti pri relokacich a tak podobne. Ten 
editor je jinak Kate (byvaly KWrite), ldd na tom vypise cca 35 knihoven.

>>To je odstranitelny performace problem v dynamickem loaderu a uz se resi, 
>>po tom, co jeden z KDE vyvojaru napsal 
>>http://www.suse.de/~bastian/Export/linking.txt a pustil to do sveta
>
>Pokud vim, Jakub Jelinek na zrychlovani dynamickeho linkeru uz nejaky
>cas pracuje, rozhodne daleko dele nez co existuje zmineny clanek ...
>uz se na vysledky docela tesim.

 No ja nevim jak zrychlovani dynamickeho linkeru, ale po tom, co Waldo 
Bastian napsal tu vec o linkeru (a to uz je par mesicu), zacal Jakub 
Jelinek psat prelinker, nebo aspon tak to vypada podle archivu binutils 
mailing listu. Kdyz jsem to zkousel, tak jsem mu taky poslal par mailu o 
tom prelinku, a, chudak, asi jich jeste par dostane (ja vim, to je hrozne, 
kdyz otravujou lidi, co tomu vubec nerozumi a maji stupidni dotazy :) ). Ja 
uz jedu castecne prelinkovany system, to je najednou zmena, kdyz se na te 
K6/188 dynamicky loader najednou rozhodne, ze Kate spusti jen za 0,03s 
misto 3 sekund. Jeste to tedy ma drobne musky, ale uz je to pouzitelne, a 
urcite to KDE dost dobre pomuze (i kdyz to bude jeste asi drobet potrebovat 
pomoct v gcc, aby ten efekt byl vetsi).

>>Kdyz si nekteri, kdo si tohle precetli, priste odpusti 
>> blaboly o KDE, budu si rikat, ze sem to sem nepsal zbytecne.
>
>Ja bych rekl, ze co se nabubrelosti KDE tyce, vsechno, co jsem na toto tema
>zatim slysel, byla cista pravda. Jen vetsina diskutujicich opomnela dodat,
>ze KDE v tom zdaleka "nejede" samo, ze nabubrele jsou i knihovny, ktere
>pouziva, a ze GNOME, no, darmo mluvit. (I kdyz po strance funkcnosti jsou
>jak KDE, tak GNOME pekne projekty, na efektivitu pri jejich programovani
>opravdu mysli malokdo...)

 To se ale mylite. Netvrdim tedy, ze kazdy zurive optimalizuje, jak to jen 
jde, ono to napred musi nejak fungovat, optimalizovat ma smysl obvykle az 
to hotove a funkcni ('Premature optimization is the root of all evil.'). 
Ale urcite to neni ignorovana vec. Treba odklon od pouzivani CORBA (jo jo, 
KDE zkouselo tuhle vec pouzivat jeste pred GNOME), byt ted KDE zalozene na 
CORBA, asi by se to ani do 128MB pocitace slusne neveslo. Spousta veci v 
KDE jsou dynamicky nahravane moduly (tj. sdilene knihovny), zase hlavne 
proto, ze vlivem "vnejsich" vlivu kazdy proces navic hodne stoji. Nebo 
kdeinit, spousta aplikaci je vlastne prekladanych jako sdilene knihovny, at 
se tim aspon castecne snizi ty priserne startovaci doby a mnozstvi 
nesdilene pameti kvuli knihovnam. Ted nedavno se prave diskutoval icon 
cache server, protoze nahravani ikon asi zabira slusnou cast startovaciho 
casu. Zatim co jsem slysel, tak kdykoliv nekdo zvenku mluvil o KDE2.2, tak 
tvrdil, ze je to rychlejsi nez 2.1 .

>> ale myslim, ze uz dalsimi detaily nebudu obtezovat.
>Jen obtezujte, myslim, ze mnoho z nich bude zajimavych.  (Kdyby nic jineho,
>rozptyli se tim nektere hluboce zazite myty...)

>>Jednak bych pri tom asi hodne nadaval, a tady s tim asi stejne nikdo nic
>>neudela ( nebo snad ano ? ).
>
>A proc ne? Preci jen z .cz pochazi nezanedbatelne mnozstvi lidi, kteri
>na kernelu, dynamickem linkeru, glibc, gcc ci XFree pracuji, a mnozi
>z nich (mne nevyjimaje) by radi prilozili ruku k dilu a nektere z techto
>problemu prozkoumali blize.

 A, skvele, tak se hlaste co kdo umite a stavte se do rady, ja porozdeluju 
ukoly :). Vazne, jestli se tedy nekdo hlasi, tak si zatim poreagujte na 
tohle, ja si tu zatim zkusim dat dokopy poznamky.

 Lubos Lunak
--
 l.lunak na email.cz ; l.lunak na kde.org
 http://dforce.sh.cvut.cz/~seli

Linus Torvalds :
'No fake - I'm a big fan of konqueror, and I use it for everything.'