DLL oder Lib



  • Hi,

    ich möchte ein Kleines Spiel programmieren.

    Da ich auch einen MapEditor etc. plane, möchte ich die Grafik-Engine auslagern.

    Was bietet sich da an, Dll oder Lib? Ich kenn mich mit den Unterschieden und Vorteilen nicht so aus.

    Eigendlich sollte doch eine Dll mehr Sinn machen, weil die Engine in mehreren Programmen genutzt wird.
    Als Lib müsste sie doch immer mit einkompiliert werden, oder?

    Gruß



  • Ja eine DLL würde hier durchaus Sinn machen.
    Statische Bibliotheken werden, wie du erkannt hast, zur Kompilierzeit statisch zu deinem Programm "hinzu gefügt", während DLLs zur Laufzeit vom Betriebssystem geladen werden (ginge aber auch manuell).
    Auf Deutsch: DLLs sparen Programmgröße, weil statische Libs direkt in die Executeable des End-Programmes "kopiert" werden.



  • Ich halte nichts davon für ein paar MB das Programm langsamer werden zu lassen. Die beste Lösung ist alles im Projekt zu haben, die gesamte Engine. Dann kann der Compiler nämlich optimieren, unbenutzte Teile weglassen und benutzte Teile speziell auf die Anwendung anpassen. Bei einer DLL geht das nicht, da die DLL nicht weiß wogegen sie gelinkt wird und die Anwendung die DLL nicht ändern kann.


  • Mod

    nwp3 schrieb:

    Ich halte nichts davon für ein paar MB das Programm langsamer werden zu lassen. Die beste Lösung ist alles im Projekt zu haben, die gesamte Engine. Dann kann der Compiler nämlich optimieren, unbenutzte Teile weglassen und benutzte Teile speziell auf die Anwendung anpassen. Bei einer DLL geht das nicht, da die DLL nicht weiß wogegen sie gelinkt wird und die Anwendung die DLL nicht ändern kann.

    Das ist Quatsch. Wenn die Engine derart leichtgewichtige Funktionen anbietet, dass das irgendeinen messbaren(!) Effekt hat, dann ist sie falsch aufgebaut. Dafür sollte man sich nicht die Entwicklung erschweren.



  • Ich halte nichts davon für ein paar MB das Programm langsamer werden zu lassen. Die beste Lösung ist alles im Projekt zu haben, die gesamte Engine. Dann kann der Compiler nämlich optimieren, unbenutzte Teile weglassen und benutzte Teile speziell auf die Anwendung anpassen. Bei einer DLL geht das nicht, da die DLL nicht weiß wogegen sie gelinkt wird und die Anwendung die DLL nicht ändern kann.

    Wo hasst Du denn das aufgeschnappt ?
    Was und wo könnte der compiler was in ner lib wegoptimieren, was in ner dll nicht geht ?
    Und wenn es so was gäbe, könnte man den compiler dann nicht auch verarschen, in dem man ne Super optimierte lib erzeugt,
    und dann nen dll projekt drumherum baut, was einfach nur die benötigten funktionen exportiert (export table) und intern nur aus der verlinkten super optimierten lib besteht ???

    @Schwarzefee

    Was bietet sich da an, Dll oder Lib?

    beides hat vor und nachteile, kann man so pauschal nicht beantworten.

    der grosse unterschied:
    getrennte Übersetzungseinheit, die verlinkung nach extern geht nicht über linker-symbole sondern über die eigene export table.
    und die dll wird dynamisch hinzugeladen, zur laufzeit.

    Das macht die Dll praktisch zur 1. wahl:
    - wenn man module/Komponenten getrennt distributieren will (binary & lib haben unnerschiedliche versionen), was wiederum die Basis für Plugins/Modularisierung ist.
    - wenn man unterschiedliche inkompatible compiler(einstellungen) verwenden will ... binary und lib können mit unetrschiedlichen compilern gebaut werden.

    Das ist auch aber der grosse Nachteil:
    Es werden daten ausgetauscht ueber Speichersignaturen. die muessen beide 100% gleich interpretieren sonst krachts. Da können schon compilereinstellungen, und unterschiedliche typedefs zu inkompatiblitaeten führen.
    Deshalb Sollte man einem Interface was über DLL grenzen geht, eigentlich etwas mehr aufmerksamkeit schenken als denen die über libs gehen z.b.
    Bei einer lib z.b. ist durch das gemeinsame linken per definition scho sichergestellt, das die symbole zueinander kompatibel sind.

    Konzept Erweiterungsdll:
    Unter Microsoft vom Projekt her gibts diese "Erweiterungs-Dlls".
    Das heisst meistens werden sie komplett ins Projekt zum binary mitgepflegt und distributiert. ne unterschiedliche Version wird quasi uebers Projekt ausgeschlossen.
    Es werden die übelsten sachen im interface exportiert, also 100%ige compilerabhängigkeit ist gegeben.
    und die teile werden quasi statisch geladen über pragma direktiven, also sofort beim start, und erst beim schluss entladen.
    Ich z.b. find den nutzen von den DIngern sehr begrenzt, sie nutzen keinerlei vorteile der dll und wären mit ner statischen lib genau so gut implementierbar.

    das ganze hat aber allerdings auch ned so viele nachteile ...

    Meistens macht man sowas wenn man eine Dll und deren vorteile eigentlich vorsieht (irgendwann mal in nem anderen programm, irgendwann mal ne eigene versions und verwaltung) aber projekttechnisch noch nicht so weit ist, bzw nie dazu gekommen ist 🙂
    Allerdings sind verwaltungstechnisch die unterschiede auch nicht wirklich gross. In Zeiten von Build-generatoren z.b. sind es 2 zeilen im Buildscript und eventuell eine .def datei, die den unterschied zwischen dll und lib ausmachen.
    Es ist nicht so das die Entscheidung nicht rueckgaengig gemacht werden könne ^^

    Das betrifft windows, unter linux siehts technsich gleich aus, aber die bedingungen sind etwas anders ....

    Ciao ...



  • Dann wäre also eine Dll die bessere Wahl für eine Engine?



  • Dann wäre also eine Dll die bessere Wahl für eine Engine?

    Konnzentrier dich lieber auf die Implementierung.
    Wenn du willst, das deine Engine generisch (hochgradig wiederverwendbar) ist, Ist die richtige wahl des Interface designs (c-interfaces vs. pure abstract classes vs. compiler depended classes, templates) wesentlich wichtiger 🙂
    Und wie das ding in nem project verwaltet wird ... versionierung und so.
    Das hat wesentlich mehr EInfluss auf Erfolg und handlebarkeit also wie die Art der Biblio ^^

    lib oder dll, ist dann später(mit buildgenerator) meist nen 2 Zeiler zum switchen.

    Ciao ...



  • RHBaum schrieb:

    Was und wo könnte der compiler was in ner lib wegoptimieren, was in ner dll nicht geht?

    Ich habe doch geschrieben "Die ganze Engine im Projekt". Keine Lib, keine DLL. Ich wollte immer mal untersuchen, wie viel man beim Umstellen von Lib/DLL auf "Ins Projekt reinkopieren" + "Whole Program Optimization" gewinnt. Ich denke das würde sich lohnen.



  • Ich wollte immer mal untersuchen, wie viel man beim Umstellen von Lib/DLL auf "Ins Projekt reinkopieren" + "Whole Program Optimization" gewinnt. Ich denke das würde sich lohnen.

    ok, sorry dann falsch gelesen ...

    und Ja Du würdest vielleicht bissi was gewinnen, weil in die "engine" direkt reinspringen kannst .... aber nicht nur durchs reinkopieren und nen schalter umlegen.
    Sobald du anfaengst "Interfaces" zu bauen und zu leben, hasst keinen Vorteil mehr. Das optimieren versaut dir nicht das linken, sondern generell die Interfaces, mehr oder weniger 🙂

    Dann wär das ganze aber auch keine Bibliothek mehr ... sondern einfach nur direktzugriff, und vllt. paar generischere Hilfsklassen.
    Das hätte dann den begriff "Engine" definitiv nicht verdient...
    Wobei STL, ATL, WTL, boost nennen sich auch Bibliothek ^^
    Deine Idee würde natürlich richtig an Charm gewinnen, wenn Du die Librariesierung eigentlich komplett verhinderst -> 100% headerimplementiert / templates. Dann wäre aber das Thema Lib/dll eh gegessen ...

    Ciao ...


  • Mod

    Erzählt dem TE doch keinen Quatsch. Ich weiß ja nicht, was ihr euch unter einer Grafikbibliothek vorstellt, aber Header-only Grafikbibliothek oder whole-program-optimization macht einfach keinen Sinn. Die Funktionen tun was, da wird durch Inlining nichts optimiert. Die Bibliothek muss auch nicht für unterschiedliche Datentypen abstrahiert werden. Dieser Rat macht alles nur schwieriger, ohne irgendetwas zu bringen.



  • Dieser Rat macht alles nur schwieriger, ohne irgendetwas zu bringen.

    Definitiv ist das kein "Einsteigerthema".
    Aber ist ne Graphik-bibliothek "Einsteigerthema" ?

    da wird durch Inlining nichts optimiert

    Kommt drauf an, wie gestaffelt und komplex seine Einsprungpunkte sind.
    Aber ich vermut auch, das seine Hirarchien eher flach und ungestaffelt sein werden und viel an andere libs einfach nur weitergegeben wird, also eher nur nen interface-wechsel. Da wird Inlining kaum was bringen.
    Und wie gesagt, wenn einsteiger-Level, ist dann die Frage nach der Performance so akut?

    Und ueber das Project selber wissen wir auch nicht viel, warum überhaupt ne Engine/Bib gebaut werden soll.
    Ist da Datenaustausch zwischen mehreren Anwendern (unterschiedliche compilereiheiten / module mit eigener versionierung) im selben prozess nen thema, sollte man das mit der headerimplementierung eh auch schnell vergessen.

    Von daher bleib ich auch dabei, ne lib bauen, und schauen wie es sich weiterentwickelt.

    Ciao ...



  • @SeppJ
    Die ganzen Vektorklassen sollten alle Inline sein.
    Auch Modifikationen des Scene-Graph.

    Die Funktionen die wirklich was tun sind in einer Game-Engine oft recht dünn gesäht. Der grosse Rest ist Kleinvieh das sehr viel von Inlining profitiert.



  • Die Funktionen die wirklich was tun sind in einer Game-Engine oft recht dünn gesäht.

    kenn ich bei den "generischen" Engines auch nur so ...
    Also meistens tun sie:
    - Plattformunabhaengigkeit herstellen
    - Funktionen mehrerer Systeme zu einer zentralen Bib zusammenfassen (Opengl+alsa+XInput)
    - fehlende Hardware funktionalitaet nachbauen
    - Unterschiedliche Systeme mit gleichen Aufgaben generalisierieren.

    und die die ich kenne, wollen als Parameter immer schöne C Binärstrukturen, die ich ausm anderen kontext(opengl, directx ... ) doch schon kenne

    Was wir aber nicht wissen, ist wie Spezifisch sich der TE seine Engine vorstellt. Vielleicht macht sie wirklich richtige aufwendige, sehr spezielle Dinge (transformationen, etc .. ) und will nen recht einfaches aber sehr spezifisches interface dafür anbieten.

    Ciao ...


Log in to reply