Wieviel effizienter und schneller sind Spiele, die direkt in Assembly geschrieben wurden als welche die bspw. mit Unity gemacht wurden?
Hallo, ich hätte eine Frage, die mir warscheinlich nur Computer Nerds oder Informatiker beantworten können: Wenn ich ein Spiel ganz klassisch mit Unity erstelle und das selbe Spiel auch direkt in Assembly programmiere, und diese beiden vergleiche, wieviel schneller wird das mit Assembly geschriebene sein. Und wieviel Schpeicherplatz wird es weniger brauchen? (natürlich in % und das im Durchschnitt) Mir ist klar, das es mit heutigen Computern super schwer ist, etwas direkt mit Assembly zu Programmieren und es würde ultra lange dauern, aber es wäre möglich. Ich würde es nicht versuchen, ich will einfach nur sehen wie effizient eigentlich moderne Game Engines sind.
8 Antworten
Naja, wenn man sich mal in der sog. Demoscene umguckt und sich ansieht, was die mit Assembler heraus holen, dann dürfte der Speicherplatz für die Binary auf weit unter ein Tausendstel sinken, was allerdings durch sehr hohen RAM-Verbrauch erkauft wird.
Die Geschwindigkeit kann man mit Unity gar nicht vergleichen, da liegen Welten, dazwischen.
Allerdings ist es mit Assembler alles andere als komfortabel ein Spiel zu entwickeln, und deshalb wird es auch in den meisten Fällen bei atemberaubenden Demos bleiben.
Allerdings kann man mit C++ durchaus Spieleengines schreiben, die teilweise der Assemblerprogrammierung überlegen sind, weil bei modernem C++ unglaublich viel zur Kompilierzeit vorausberechnet werden kann.
Außerdem hat man mit C++ wesentlich mehr Kontrolle über Speichermanagement, Prozesse und auch den Scheduler. Die Synchroniesierung dessen ist aber eine Kunst und stellt die Größte Hürde für aktuelle Spieleengines dar.
Bei Unity fehlt dieser Teil gänzlich, aber Unity ist auch wesentlich anfängerfreundlicher.
Richtig guten C++-Code zu schreiben ist eine hohe Kunst, und Assembler vermutlich noch viel mehr.
Da optimierter C++-Code aber im Schnitt mit Assembler gleich zieht, macht sich niemand (außer aus Spieltrieb bei z. B. oben genannten Demos) die Mühe.
Das kommt sehr auf den einzelnen Fall an.
Die Engine ist hoch optimiert, weil sie viele Anwender hat. Du kannst eigentlich nur schneller sein, wenn Dein Spiel eine Untermenge verwendet, die Unity nicht so gut optimieren kann, weil es allgemeinere Use Cases abdeckt.
Kann man so nicht sagen...
Es kann sogar sein, dass es langsamer ist
https://stackoverflow.com/questions/9601427/is-inline-assembly-language-slower-than-native-c-code
Wird hier sicher nicht der Fall sein, aber einen Faktor auszumachen wird schwer
Ja wenn wir davon ausgehen dass jemand perfekten Assemler schreibt hast du recht. Aber dann können wir ja auch davon ausgehen, dass es perfekte Compiler gibt :)
Ein wesentlicher Faktor fehlt dabei: Die Fehlersuche !
Assembler zu programmieren ist sehr viel aufwendiger und damit steigt das Fehlerrisiko und dann die Fehler zu finden ist krass.
Was sich direkt auf die Kosten auswirkt, und da kommt noch ein weiterer Punkt dazu, die Erweiterbarkeit, da Änderungen auf Assembler Ebene sehr aufwendig sind.
Es gibt aber Mischformen, langsames wird mit vorgefertigten Engines erstellt, das super Zeitkritische mit anderen Sprachen wie C oder Assembler.
Mein Fazit: Es lohnt sich zeitlich, finanziell und aus Wartbarkeit schlicht nicht, etwas in Assembler zu programmieren. Auch auf kleinen Mikrokontrollern macht C einen sehr guten, kaum zu schlagenden Code.
Ich bezweifle, dass sich das irgendwie beantworten lässt. 1) Assembler lässt sich kaum programmieren, 2) die Programme sind hoch spezialisiert und nur für bestimmte Architekturen geeignet und 3) fallen einige Optimierungstechniken weg, die bei modernen Compilern viel Performance rausholen, auch aufgrund impliziter Parallelisierung. Ich glaube kaum, dass jemand so gut Assembler programmieren kann, als dass sich der zuletzt genannte Punkt ausgleichen ließe. Interessant sind eher Lösungen, die in-hardware passieren. Wenn du durch low-level Effekte optimieren willst, dann beschneide dich nicht selbst in der Sprache, sondern verlagere einige Berechnungen auf die Hardwareseite und versuche diese Features möglichst einfach zugänglich zu machen.
Naja, aber das liegt dann nie an Assembler, und inline Assembler ist nochmals ein Thema für sich