KDE a sdilene knihovny (Was Re: Programovani - shared libraries na Linuxu)

[Lubos Lunak]

Pavel Kankovsky wrote:

> On Wed, 5 Sep 2001, Lubos Lunak wrote:
> 
[snip]
> 
>> 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.
> 
> Ovsem GNOME ji pouziva porad (AFAIK) a do 128 MB se v pohode vejde.

 Ovsem GNOME nedostava od gcc/ld premii pres 0,5MB pameti na proces.

[snip]
> 
>> Moje teorie je takova, ze gcc si obcas moc nevi rady s vecmi jako
>> sablony, virtualni tabulky, inline metody a podobne a pro jistotu je v
>> nekterych pripadech emituje vic nez jednou. Sice jsou jako
>> LINK_ONCE_DISCARD, takze ve vysledne knihovne jsou tyhle symboly jen
>> jednou, ale linker uz se neobtezuje (nebo mozna ani nemuze) podivat,
>> ze tyhle symboly uz existuji v nejake knihovne, s kterou se tahle
>> vysledna linkuje. Takze vsechny veci jsou pekne zduplikovane a dopadne
>> to jak s tou libtc nahore.
> 
> Aaaa...asi jsme uhodili hrebicek na hlavicku. C++, your second name is
> bloat. Cele je to totiz *vrozeny* defekt C++.

 Nechtel bych se takhle umet trefovat hrebickum na hlavicku. Mel bych z 
toho moc casto zavazany palec. Doporucuji k precteni Stroustrupovo 'Design 
and Evolution of C++', C++ je navrzeno tak, ze muze byt stejne efektivni 
jak rychlostne tak pametove jako C; vlastnosti, ktere v C nemaji 
ekvivalent, jsou tak efektivni, jako ekvivaletni C kod, nepouzite C++ 
vlastnosti nemusi pridat nic navic. To, ze lidi od gcc jeste u nekterych 
veci porad na to neprisli, jeste neznamena, ze to nejde. To je takova hezka 
smycka :
1) _implementace_ C++ je neefektivni
2) lidi si reknou, ze C++ je neefektivni a nepouzivaji ho
3) je malo lidi pouzivajicich C++, je malo lidi, kteri maji zajem na 
zlepsovani implementance C++
4) pokracujte bodem 1)

 
> 
> Zacalo to v C: jednotlive moduly jsou de facto uplne nesouvisejici kusy
> zdrojoveho kodu, ktere se zcela samostatne zkompiluji a nakonec slinkuji.
> Pritom veci jako definice typu (napr. struct) prestavaji po kompilaci
> existovat a dokonce je mozne, ze ruzne moduly si pod stejnym jmenem
> predstavuji ruzne typy (a dokonce je mozne, ze to bude ve vysledku
> fungovat).
> 
> Drhnout to pochopitelne zacalo pri generovat ladicich informaci, protoze
> ty musi definice typu obsahovat, ale kompilator nema tuseni, ktery
> z modulu typ definuje (ve smyslu rozdilu deklarace a definice)...ony ho
> totiz ve skutecnosti definuji vsechny, ktere ho pouzivaji. Takze kazdy *.o
> vyrobeny ze zdrojaky pracujiciho se stdio obsahuje v ladicich informacich
> kompletni definici FILE. (Tohle mozna nekterym lidem vysvetli zahadu, proc
> -g zpusobi tak ukrutny narust velikosti po kompilaci.)
> 
> A ted do toho prislo C++, kde definice trid, konstant (pres const) a
> inline funkci ci metod (nemluve o sablonach, ale ty pro jednoduchost
> nebudu rozvadet) vede ke generovani *skutecneho* kodu a/nebo dat bez toho,
> aby bylo jasne urceno, ktery modul je vlastne ten pravy (srovnejte to
> napr. s moduly v jinych jazycich: Turbo Pascal, Delphi, Ada...tam vsude je
> vztah kompilacnich jednotek a definic jasne urcen). Cili nezbyva nez to
> vlastne vygenerovat pri *kazde* kompilaci a pak doufat, ze to linker nejak
> chytre posklada dohromady. Vyskytly se take snahy (zvlaste u sablon), ze
> by kompilator automaticky udrzoval umele moduly, do kterych by takove veci
> ukladal, ale nebyly moc uspesne (aspon pokud vim). GNU C++ extenze #pragma
> interface a #pragma implementation byly take pokus o reseni tohoto
> problemu.
> 
> Nejhorsi je situace samozrejme v pripade dynamickeho linkovani, protoze
> tady ten bordel musi do znacne miry uklidit az dynamicky linker. Kdyz
> vyrabite dynamickou knihovnu, tak ld predem *nevi*, s cim dalsim bude
> slinkovana, a tudiz musi predpokladat nejhorsi -- tj. tam nahazet vsechno,
> co je potreba. Dynamic linker pak pochopitelne uvidi vicenasobne definice
> tehoz a musi to nejak vyresit.

 No jasne, ze ja na to neprisel hned, za vsechno muze jazyk. Kdyz se 
podivame treba na tohle ( zestrucneny realny priklad, B je QCString ) :

class A
    {
    public:
        virtual ~A();
    };
class B
    : public A
    {
    public:
        void f();
    };

 Naprosto regulerni C++ kod. B samozrejme potrebuje vtable, protoze kvuli 
dedeni z A ma virtualni destruktor implicitne generovany prekladacem. Jenze 
gcc v B nikde zadnou non-inline virtualni metodu nenajde, vedle ktere by 
emitoval tu vtable a nenapadne ho nic lepsiho nez emitovat vtable kdykoliv 
je treba. Pritom mi trvalo asi tak 10 sekund vymyslet, ze vtable se da v 
pohode emitovat jen v modulu implementujicim B::f() .
 A je vic takovych pripadu, kdy gcc generuje zbytecne vic vyskytu pro veci 
s 'vague linkage'. Vazne nechapu, proc se musi vicekrat emitovat virtual 
thunk pro nektere metody tridy QWidget, kdyz se pro ni emituje vtable jen 
jednou, nebo proc zrejme existuje ve vice vyskytech __pure_virtual (coz je 
tedy naprosta perla, nemuzu si pomoct).


[snip]
> 
> P.S. Dovolil bych si pozadat, aby byly dopisy citovany zpusobem, ktery
> nebude u ctenaru vyvolavat dojem, ze nekdo (ja) rekl neco, co rekl nekdo
> uplne jiny.
> 

 Pardon. Nechtelo se mi se opakovat do dvou zprav za sebou a kdyz jsem 
presouval ty nektere useky, tak jsem pred ne dal o jedno mene '>'. Dam si 
priste pozor.

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