Programovani - shared libraries na Linuxu

[Martin `MJ' Mares]

Zdravim!

>  No tak takhle naivni jsem byl taky. Do te doby nez jsem to zkusil zmerit. 
> Muzeme si to klidne spolu zkusit znovu, potreba je jen KDE2.x a g++. Takze, 
> napiseme primitivni program, neco jako
> 
> #include <unistd.h>
> int main()
>     {
>     sleep( 30 );
>     }
> 
> a prelozime gcc test.cpp -O2 a spustime a zmerime spotrebu nesdilene (tj. 
> per-process) pameti. Ja to pocitam v 'top' jako rozdil SIZE-SHARE, jestli 
> nahodou nekdo zna lepsi zpusob, rad se poucim. No ne, 56kB, a to je to 
> slinkovane jen s glibc.

Podivejme se na to trochu podrobneji:

     | mj na albireo:/tmp$ gcc test.c -o test -O2 -g
     | mj na albireo:/tmp$ ./test &
     | [1] 1292
     | mj na albireo:/tmp$ cat /proc/1292/maps
[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

Zde je krasne videt, ze jak program samotny, tak sdilene knihovny jsou
vlastne obycejne pametove mapovane soubory, a to jednak s pravy "r-xp"
(read, no write, execute, private -- to jsou bloky kodu) a jednak s "rw-p"
(read, write, no execute, private -- to jsou copy-on-write mapovani, ktera
odpovidaji read/write datum). [1] je tedy nas program, [2] jeho staticka
data, [3] dynamicky linker s [4] daty, [6] libc s [7] daty.

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

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

Samotne dynamicke linkovani a ELF za nic nemohou, snad mimo toho, ze dynamicky
linker ma take nejakou vlastni rezii (1 stranka na jeho staticka data +
1 stranka na dynamicka data; to by se pravdepodobne dalo spojit do 1 stranky)
a ze veskere mapovani pameti se nutne deje po strankach, takze i kdyz nejaky
program (napriklad nas testovaci) ma statickych dat malicko (u naseho
testu zjistime:

     | mj na albireo:/tmp$ objdump --all test
     | [...]
     |     LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
     |          filesz 0x00000464 memsz 0x00000464 flags r-x
     |     LOAD off    0x00000464 vaddr 0x08049464 paddr 0x08049464 align 2**12
     |          filesz 0x000000e0 memsz 0x000000f8 flags rw-
     | [...]

tedy ze staticka data maji 248 bajtu), prideli se mu alespon jedna stranka.
To jsou ale veci, na kterych se tezko da neco vyresit lepe.

Jiny pribeh je rozhazovacnost samotnych knihoven -- glibc by jiste nepotrebovala
tolik statickych dat (nebo by je alespon mohla mit usporadane tak, aby veci,
ktere se malokdy pouziji, byly blizko sebe, a tak se opravdu alokovalo jen
nekolik malo stranek s temi pouzivanymi) a take by se obesla bez takoveho
mnozstvi dynamicky alokovane pameti ... ale tohle vsechno uz jsou veci
nezavisle na samotnem principu statickeho/dynamickeho linkovani, ty se
tykaji autoru jednotlivych knihoven a sebelepsi "globalni" strategie
je nemuze vyresit.

(Zajemce odkazuji na projekt `diet libc' (http://www.fefe.de/dietlibc/)...)

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

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

>  Ted bych jeste mohl rict treba neco o tom, proc skoro vsechno v KDE se 
> preklada s -fno-exceptions,

Exception info u Ceckovych programu je dan za kompatibilitu C a C++.
Zde s maintainery GCC nesouhlasim, -fno-exceptions by melo byt defaultni
a pokud si nekdo preje sve Ceckove moduly pouzivat z C++ (napriklad
stavi-li nejakou knihovnu ... a stejne na kompatibilitu musi pamatovat
v deklaracich, aby nezapomnel na `extern "C"', takze argumenty
o nezasahovani do programu asi neobstoji), mel by explicitne uvest,
ze exceptiony chce.

> 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?

> 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?

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

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

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

> Kdyby si snad nekdo chtel vazne o tehle vecem podiskutovat, klidne.

Alespon jeden takovy tu je :-)

> A takovehle veci samozrejme nejsou problemem jen KDE. Ona ta Mozilla asi
> nebude az takova Bloatzilla, a StarOffice si asi taky nemuze za ten dlouhy
> start jen sam.

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

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj na ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
This message is transmited on 100% recycled electrons.