Warum bevorzugen Spiele-Engines statische Bibliotheken gegenüber dynamischen Linkbibliotheken?
Lesezeit: 6 Minuten
Ich habe ein paar Gaming-Bücher gelesen. Und sie ziehen es immer vor, die Engine als statische Bibliothek gegenüber einem dynamischen Link zu erstellen. Ich bin neu in C++, daher kenne ich mich mit statischen Bibliotheken und dynamischen Linkbibliotheken nicht aus. Ich weiß nur, dass statische Bibliotheken die Größe Ihres Programms erhöhen, wobei DLL-Link-Bibliotheken geladen werden, wenn Sie sie in Ihrem Programm benötigen.
[edit]
Ich habe Spiele gespielt, bei denen es fast so aussah, als würden sie DLLs verwenden, um Sound, Beleuchtung und was nicht alles einzeln zu laden. als das Level geladen wurde. weil du das nicht unbedingt brauchst, wenn du im Spielmenü bist.
Es ist viel wahrscheinlicher, dass sie die Kunst- und Sound-Assets einfach laden, wenn sie sie brauchen, anstatt sich dafür zu entscheiden, die DLLs zu einem späteren Zeitpunkt zu laden. In der Regel benötigen Sie von Anfang an alle Funktionen, nur nicht alle Ihre Daten.
– Kylotan
28. April 2010 um 9:56 Uhr
Dynamic Link Libraries müssen positionsunabhängig sein; Dies kann bei einigen Prozessorarchitekturen zu Leistungseinbußen führen.
Statische Bibliotheken können optimiert werden, wenn sie in Ihr Programm aufgenommen werden, z. B. durch Entfernen von totem Code. Dies kann die Cache-Leistung verbessern.
Ok, Sie sagten, sie müssen unabhängig positioniert werden. Positionsunabhängig definieren. Ursache, wie ich es sehe. Sowohl DLLs als auch statische Bibliotheken würden beide als unabhängig betrachtet, da sie nicht zum ursprünglichen Spiel gehören. Wenn Sie statische Bibliotheken verwenden. Sie laden den gesamten Inhalt. Wie genau können Sie toten Code daraus entfernen?
– numerisch25
27. April 2010 um 15:36 Uhr
Die statische Bibliothek wird zum Zeitpunkt des Kompilierens/Linkens mit Ihrer ausführbaren Datei verknüpft; der Linker kennt die Ladeadresse des statischen Bibliothekscodes und kann dafür optimieren. Der Linker weiß auch, auf welche Funktionen in der Bibliothek verwiesen wird, und kann die Funktionen entfernen, auf die nicht verwiesen wird. Die dynamische Bibliothek wird zur Laufzeit verknüpft und kann von mehreren Prozessen gemeinsam genutzt werden, und daher ist die Adresse nicht a priori bekannt, noch kann die Bibliothek verschoben werden. Die dynamische Bibliothek hat Einstiegspunkte, die dynamisch verwendet werden können (duh) ;-), sodass kein Code aus dem Speicherbedarf eliminiert werden kann.
– Doug Currie
27. April 2010 um 15:41 Uhr
Mit “positionsunabhängig” meine ich, dass der Code laufen können muss, egal wo er in den Speicher geladen wird. Dies impliziert die Verwendung relativer Sprünge und zeigerbasierter Datenreferenzen (oder PC-relativer konstanter Datenreferenzen). Sehr intelligente Lader können zur Ladezeit einige Arbeiten ausführen, um die Auswirkungen zu minimieren. Statischer Code kann jedoch kompiliert und verknüpft werden, um bekannte Adressen für Daten und Code zu verwenden.
– Doug Currie
27. April 2010 um 15:46 Uhr
@Doug “sehr schlaue Lader können …” Eigentlich, sogar schlau, wird es ihnen schwer fallen, wenn das System zulässt, dass dieselbe dynamische Bibliothek angezeigt wird anders virtuelle Adressen von zwei Prozessen, die sie gleichzeitig verwenden. Dies ist zum Beispiel die Wahl im ELF-Binärformat, über die anderen weiß ich nicht viel.
– Pascal Cuoq
27. April 2010 um 16:42 Uhr
@BlueRaja Wenn garantiert wäre, dass eine DLL von allen Prozessen, die sie verwenden, an derselben Adresse gesehen wird, wäre für die Vorverknüpfung keine Disassemblierung erforderlich. Das alte a.out-Format hat das getan, aber das war nicht praktikabel (zentrale weltweite Autorität für DLLs). Ich denke, dass Mac OS X möglicherweise auch so etwas hat (aber mit der Zentralisierung nur auf der Ebene des Computers).
– Pascal Cuoq
27. April 2010 um 18:23 Uhr
Positionsunabhängig bedeutet er, dass die DLL, da die Game-Engine und die DLL vollständig getrennt sind, eigenständig ist und nicht in den Game-Engine-Code verwoben werden kann, während das statische Linken einer Bibliothek es dem Compiler ermöglicht, sowohl Ihren Game-Engine-Code als auch zu optimieren den Bibliothekscode.
Angenommen, es gibt eine kleine Funktion, von der der Compiler denkt, dass sie eingebettet sein sollte (direkt anstelle eines Funktionsaufrufs kopiert). Dann wäre der Compiler mit einer statischen Bibliothek in der Lage, diesen Code einzubetten, da er weiß was der Code ist (Sie verlinken zur Kompilierzeit). Bei einer dynamischen Bibliothek wäre der Compiler jedoch nicht in der Lage, diesen Code einzubetten, da er weiß nicht was der Code ist (da er zur Laufzeit verknüpft wird).
Inlining ist nicht der Grund, warum dynamische Bibliotheken langsamer sind. Die meisten Compiler+Linker integrieren keine Funktionen über Dateien hinweg. Eigentlich programmiere ich in einer Sprache, in der der Compiler dateienübergreifend integriert ist, und das daraus resultierende Fehlen einer echten separaten Kompilierung ärgert mich ohne Ende.
– Pascal Cuoq
27. April 2010 um 16:45 Uhr
WAHR. Ich habe Inlining nur als Beispiel für etwas vorgestellt, das getan werden könnte möglicherweise mit statischen Bibliotheken, im Gegensatz zu dynamischen, um ein konkreteres Beispiel zu geben.
– Fuchswälder
28. April 2010 um 0:28 Uhr
Visual Studio verfügt über eine vollständige Programmoptimierung, die problemlos über Dateien und wahrscheinlich auch über Bibliotheken hinweg integriert wird. Ich wäre überrascht, wenn gcc nicht etwas Ähnliches hätte (obwohl die meisten Spiele nicht in gcc kompiliert werden).
– Kylotan
28. April 2010 um 9:58 Uhr
Ein weiterer oft übersehener Grund, der eine Erwähnung verdient, ist, dass Sie für viele Spiele nicht viele andere Dinge ausführen werden, und viele Bibliotheken, die für Spiele verwendet werden, werden nicht für die anderen Dinge verwendet, die Sie möglicherweise ausführen zur gleichen Zeit wie ein Spiel, sodass Sie sich keine Gedanken über einen der größten Vorteile machen müssen, die Sie durch die Verwendung von gemeinsam genutzten Bibliotheken erhalten, nämlich dass nur eine Kopie (von den meisten) der Bibliothek gleichzeitig geladen werden muss, während mehrere Dinge geladen werden müssen kann diese eine Kopie verwenden. Wenn Sie ein Spiel ausführen, haben Sie wahrscheinlich sowieso nur ein Programm, das diese Bibliothek verwenden möchte, da Sie wahrscheinlich nicht viele andere Programme (insbesondere andere Spiele oder 3D-Programme) gleichzeitig ausführen werden.
Sie eröffnen auch die Möglichkeit der globalen/Verbindungszeitoptimierung, was bei gemeinsam genutzten Bibliotheken viel schwieriger ist.
Stephan Kreuz
Eine weitere Frage befasst sich mit den Unterschieden zwischen statischen und dynamischen Bibliotheken: Wann sollten dynamische vs. statische Bibliotheken verwendet werden?
Warum sie statische Bibliotheken verwenden, kann sich die zusätzliche Geschwindigkeit lohnen und Sie können die DLL-Hölle vermeiden (war in der Vergangenheit ein großes Problem). Es ist auch nützlich, wenn Sie Ihr Programm und Ihre Bibliotheken zusammen verteilen möchten, um sicherzustellen, dass der Empfänger über die richtigen Abhängigkeiten verfügt, obwohl nichts Sie daran hindert, DLLs zusammen mit der ausführbaren Datei zu verteilen.
Bei der Entwicklung von Spielen für eine Konsole ist dynamisches Linken oft keine Option. Wenn Sie die Engine sowohl für die Konsolen- als auch für die PC-Entwicklung verwenden möchten, sollten Sie am besten auf dynamische Verknüpfungen verzichten.
12465500cookie-checkWarum bevorzugen Spiele-Engines statische Bibliotheken gegenüber dynamischen Linkbibliotheken?yes
Es ist viel wahrscheinlicher, dass sie die Kunst- und Sound-Assets einfach laden, wenn sie sie brauchen, anstatt sich dafür zu entscheiden, die DLLs zu einem späteren Zeitpunkt zu laden. In der Regel benötigen Sie von Anfang an alle Funktionen, nur nicht alle Ihre Daten.
– Kylotan
28. April 2010 um 9:56 Uhr