Benutzt irgendwer dynamische Libs?

derFer

Also ich linke alles dynamisch, Ausnahmen: Wenn ich ein kleines Programm nur kurz testweise linke (< 100 Zeilen)...
Aber sonst alles dynamisch...Die Vorteile wurde ja schon alle genannt (schnelleres Austauschen etc.) und vor allem bewege ich mich meist in der Linux Welt und hier ist alles dynamisch gelinkt (/usr/lib/)
Und ein weiterer Grund: einige von mir benutzte Libs dürfen nur so gelinkt werden (z.B. QT)...
MfG

Um ehrlich zu sein, nerven mich diese Shared-Libs unter Linux.

Mag sein, dass es einen Platzspar-vorteil gibt, wenn verschiedene Programme die gleichen Libs nutzen, aber ich finde es mehr als unnötig, dass ich mir bei manchen Programmen mehrere Shared-Libs mitladen muss, weil sonst das Programm nicht funktioniert.

derFer

Naja stören tut das ja wohl kaum, die meisten Pakete installiere ich über meinen Paketemanager (YaST) da interessiert es mich nicht wie viele Pakete nebenbei geladen werden, Aufwand ist der selbe.
Und der Vorteil ist einfach, das ich bei z.B. einem Bugfix von einem Paket (z.B. QT) nicht gleich alle Programme updaten muss (was bei statisch gelinkten sehr große Datenmengen dann wären je nach Programm) sondern nur die Libs updaten muss...
Und mit max. 150KB/s macht es nicht so Bock 100 Programme updaten zu müssen

MfG

hustbaer

Wir (Firma) verwenden viele DLLs.

Hauptsächlich weil die Linkzeiten dadurch sinken und natürlich auch weil die Binaries dadurch tendenziell kleiner werden (kann manchmal auch umgekehrt sein, z.B. wenn man nur einen kleinen Teil einer grossen LIB braucht, und das nur in einem Projekt gewinnt normalerweise die LIB).

Ich frage mich immer, warum manche Anwendungen unter Windows, vor allem Spiele, so viele DLL-Dateien haben.

Wie ja in diesem Thread schon angesprochen wurde, eigentlich sollten diese DLLs/SOs einen Vorteil bringen, indem sich mehrere Programme die gleichen Dateien "teilen" (-> "Shared").

Wenn aber eine Anwendung sozusagen ihre eigenen DLLs hat, also DLLs, die nur diese Anwendung braucht, wie es ja bei Spielen so ist, dann untergräbt das den einzig vernünftigen Grund für DLLs.

Hat die Dateigröße einer exe etwas mit ihrer Ausführungsgeschwindigkeit zu tun? Ich weiß es nicht.

SeppJ

dlls unter windows schrieb:

Hat die Dateigröße einer exe etwas mit ihrer Ausführungsgeschwindigkeit zu tun?

Nein.

Ich weiß es nicht.

Jetzt schon.

derFer

Reine Vermutung aber vielleicht wird das gemacht weil dann nur die gerade wirklich benötigten Bibliotheken zur Laufzeit in den Speicher geladen werden müssen... Daher nicht die komplette Datei in den Speicher geladen werden muss...
MfG

berniebutt

Das kommt der Sache recht nah. Aber es gibt auch Leute, die am Auto ständig den Skiträger mit Gepäckbox befestigt haben und natürlich stets den Anhänger mitführen, weil sie mal zum Baumarkt wollen.

berniebutt schrieb:

Das kommt der Sache recht nah. Aber es gibt auch Leute, die am Auto ständig den Skiträger mit Gepäckbox befestigt haben und natürlich stets den Anhänger mitführen, weil sie mal zum Baumarkt wollen.

naja.
ffmpeg beipielsweise unter windows eine einzige executable, ca. 20MB groß.

den anwender kümmert es nicht.

derFer schrieb:

.Die Vorteile wurde ja schon alle genannt (schnelleres Austauschen etc.)

Nein, wurden sie nicht.

Dazu kommen noch:

- mit dynamischen Libs ist das System schneller. Wenn sich 10 Anwendungen die gleiche Lib teilen und eine Anwendung die Lib schon in den Speicher geladen hat, dann ist der Start der restlichen 9 Anwendungen wesentlich schneller, als wenn diese 9 Anwendungen die Lib statisch reingelinkt hätte.
Denn bei den darauffolgenden Starts muss die Lib nicht mehr erst geladen werden, da sie schon geladen ist.
Dynamisch zu linken hilft also der Performance und Reaktionszeit des Gesamtsystems.

- bei manchen Bibliotheken MUSS man, wenn man das Endprodukt weitergibt, aufgrund der Lizenz unter der sie vertrieben werden, dynamisch Linken. Als Beispiel wären da z.B. alle Bibliotheken zu nennen, die die LGPL als Lizenz verwenden.

dlls unter windows schrieb:

Ich frage mich immer, warum manche Anwendungen unter Windows, vor allem Spiele, so viele DLL-Dateien haben.

Wie ja in diesem Thread schon angesprochen wurde, eigentlich sollten diese DLLs/SOs einen Vorteil bringen, indem sich mehrere Programme die gleichen Dateien "teilen" (-> "Shared").

Wenn aber eine Anwendung sozusagen ihre eigenen DLLs hat, also DLLs, die nur diese Anwendung braucht, wie es ja bei Spielen so ist, dann untergräbt das den einzig vernünftigen Grund für DLLs.

Hat die Dateigröße einer exe etwas mit ihrer Ausführungsgeschwindigkeit zu tun? Ich weiß es nicht.

Klar, umso größer die EXE, desto länger dauert es diese zu Laden.
Das merkt man auf SSDs meist nicht mehr, aber bei fetten Librarys die statisch in die EXE gelinkt werden, können das schon Sekunden auf HDs betragen.

Und Spiele haben oft DLLs, weil es die Lizenzen so vorschreiben.

Es ist ja nicht so das die ganze EXE beim Start direkt komplett von der Festplatte geladen wird. Es wird immer nur das geladen was benötigt wird.

hustbaer

Dynamisch Linken rulez schrieb:

Klar, umso größer die EXE, desto länger dauert es diese zu Laden.
Das merkt man auf SSDs meist nicht mehr, aber bei fetten Librarys die statisch in die EXE gelinkt werden, können das schon Sekunden auf HDs betragen.

Falsch.
Die EXE wird beim "Laden" nicht komplett geladen, sondern es wird bloss das PE Image in den Speicher gemappt.
Geladen wird dann nur das was benötigt wird.
Und eine fette EXE verglichen mit einer EXE + ein paar DLLs (die in Summe dann ca. gleich gross oder sogar grösser sind), da gewinnt klar die monolithische EXE.

Weil da wenigstens nur ein File geladen werden muss vs. mehrere Files bei EXE + DLLs. D.h. weniger Suchzeiten.

Und für "mehrere Sekunden bei HDs" müsste die EXE schon mehrere hundert MB gross sein.

Also so, wie ich den Eingangspost interpretiere, redet der Threadstarter eher vom linken, und nicht vom dynamischen Nachladen während der Laufzeit.

Ich denk mal, wenn ich eine so/dll beim kompilieren linke, dann wird, wenn die executable ausgeführt wird, auch gleichzeitig die gelinkte so/dll mitgeladen.

summa summarum müsste es eigentlich egal sein, ob ich Codeteile als so/dll kompiliere und dann dynamisch dazulinke, oder den Code gleich mit in die executable miteinkompiliere.

derFer

Was verstehst du den unter dynamisch linken und dynamisch nachladen?
Dynamisch linken bedeutet ja du erzeugst dein Programm (.exe etc) und die Bibliothek (.DLL oder .so) und dann wenn der Benutzer das Programm startet wird die Bibliothek geladen... Daher dynamisch linken und nachladen sind das selbe
MfG

derFer schrieb:

Was verstehst du den unter dynamisch linken und dynamisch nachladen?
Dynamisch linken bedeutet ja du erzeugst dein Programm (.exe etc) und die Bibliothek (.DLL oder .so) und dann wenn der Benutzer das Programm startet wird die Bibliothek geladen... Daher dynamisch linken und nachladen sind das selbe
MfG

unter dynamisch nachladen, dass ich irgendwelche funktionen aus windows.h verwende, um die lib während der laufzeit zu laden.

shutdown -h now schrieb:

ffmpeg beipielsweise unter windows eine einzige executable, ca. 20MB groß.

den anwender kümmert es nicht.

Schön, wenn man eine beschränkte Sicht auf die Dinge hat
Ich entwickle Software, die auf DVD ausgeliefert werden MUSS. Und da ist neben meiner Software noch ein Riesen Batzen an anderer Software drauf. Wenn jeder denken würde wie du, dann würde die DVD wohl überlaufen...
Vielleicht einfach mal dran denken, dass Softwareentwicklung nicht nur für das Kiddie daheim ist, dass seinen neuesten kopierten Film schauen will.

KuhTee schrieb:

shutdown -h now schrieb:

ffmpeg beipielsweise unter windows eine einzige executable, ca. 20MB groß.

den anwender kümmert es nicht.

Schön, wenn man eine beschränkte Sicht auf die Dinge hat
Ich entwickle Software, die auf DVD ausgeliefert werden MUSS. Und da ist neben meiner Software noch ein Riesen Batzen an anderer Software drauf. Wenn jeder denken würde wie du, dann würde die DVD wohl überlaufen...
Vielleicht einfach mal dran denken, dass Softwareentwicklung nicht nur für das Kiddie daheim ist, dass seinen neuesten kopierten Film schauen will.

Ich kann deine Argumente nicht ganz nachvollziehen.
Wenn du über das "CD-Maximum" von ca. 650MB kommst, nimmt man halt einfach eine DVD mit 4,7GB oder mehr.

hustbaer

Courier schrieb:

summa summarum müsste es eigentlich egal sein, ob ich Codeteile als so/dll kompiliere und dann dynamisch dazulinke, oder den Code gleich mit in die executable miteinkompiliere.

Nö, ist nicht egal.
Wenn man von einer EXE ausgeht, die 1x "frisch" nach dem Neustart des OS gestartet wird, und sich keine DLLs mit anderen EXEn teilen kann, dann gewinnt immer der Monolith.

Wenn man dagegen mehrere EXEn hat von denen auch mehrere gestartet werden, u.U. sogar mehrfach, dann kann es sein dass die DLL Variante gewinnt.

hustbaer schrieb:

Courier schrieb:

summa summarum müsste es eigentlich egal sein, ob ich Codeteile als so/dll kompiliere und dann dynamisch dazulinke, oder den Code gleich mit in die executable miteinkompiliere.

Nö, ist nicht egal.
Wenn man von einer EXE ausgeht, die 1x "frisch" nach dem Neustart des OS gestartet wird, und sich keine DLLs mit anderen EXEn teilen kann, dann gewinnt immer der Monolith.

Wenn man dagegen mehrere EXEn hat von denen auch mehrere gestartet werden, u.U. sogar mehrfach, dann kann es sein dass die DLL Variante gewinnt.

ja, du gehst aber immer von "allgemeingebräuchlichen" DLLs aus, also DLLs, die mehrere Programme brauchen und benutzen. Da stimmt das, was du sagt, völlig.

Aber wenn ich eine Anwendung habe, die neben der exe noch 5 DLLs mit nichtssagendem Namen hat ("GameEngine.dll", "ScriptingEngine.dll", "audio.dll" usw.), dann bringt das eben keinen Vorteil.

Wenn ich die exe starte, läd das Betriebssystem die 5 Dlls mit in den Speicher.
--> Wenn ich nur eine exe habe, läd das Betriebssystem diese exe in den Speicher.

Verstehst du nicht, wie ich das meine? Wenn ich eine exe mit "einmal-gebrauchten-DLLs" habe, das ganze Pack 20 MB groß ist, dann kann ich das ganze auch gleich in eine exe kompilieren, die dann im Endeffekt 20 MB groß ist, aber keine unnütze DLLs mitbringt.