14 Punkte von GN⁺ 2025-12-30 | Noch keine Kommentare. | Auf WhatsApp teilen
  • Die von Unity verwendete Mono-Laufzeit zeigt im Vergleich zu modernem .NET eine deutlich geringere Ausführungsgeschwindigkeit; beim selben C#-Code wurden Unterschiede von bis zu 15x beobachtet
  • In realem Spielecode wurde 100 Sekunden für die Unity-Ausführung auf Mono-Basis gemessen, während derselbe Code unter .NET 38 Sekunden benötigte, was sich stark auf die Effizienz von Debugging und Tests auswirkt
  • Selbst im Release-Modus bleibt der Unterschied bestehen: Mono benötigt 30 Sekunden, .NET 12 Sekunden, also mehr als 2,5x selbst in einer optimierten Umgebung
  • Ursachen sind unter anderem ineffiziente JIT-Kompilierung und fehlgeschlagenes Inlining in Mono sowie übermäßige Speicherkopien, im Gegensatz zu den modernen CoreCLR-JIT-Optimierungen von .NET
  • Sobald Unity die .NET-Modernisierung auf CoreCLR-Basis abschließt, sind sowohl in Spielen als auch im Editor große Leistungssteigerungen möglich; das dürfte auf eine Beseitigung einer versteckten Performance-Steuer für alle Unity-Projekte hinauslaufen

Hintergrund zur Nutzung von Mono in Unity

  • Unity verwendet seit 2006 das Mono-Framework zur Ausführung von C#-Code
    • Damals war Mono die einzige plattformübergreifende .NET-Implementierung und als Open Source von Unity anpassbar
  • Ab 2014 stellte Microsoft .NET Core als Open Source bereit und veröffentlichte 2016 .NET Core 1.0
    • Danach entwickelte sich das .NET-Ökosystem mit Roslyn-Compiler, neuem JIT und Performance-Verbesserungen rasant weiter
  • 2018 erklärten Unity-Ingenieure, dass sie an einem CoreCLR-Port arbeiteten, mit erwarteten 2- bis 10-fachen Performance-Gewinnen gegenüber Mono
  • Doch selbst Ende 2025 ist spielseitige Ausführung auf CoreCLR-Basis weiterhin nicht möglich

Performance-Lücke zwischen Mono und .NET

  • Der Simulationscode eines Unity-Projekts wurde außerhalb von Unity direkt unter .NET ausgeführt und verglichen
    • Unity/Mono-Umgebung: 100 Sekunden, .NET-Umgebung: 38 Sekunden (im Debug-Modus)
  • Im Release-Modus bleibt der Unterschied mit 30 Sekunden für Mono und 12 Sekunden für .NET bestehen
    • .NET zeigt zudem starke Multithreading-Optimierung, etwa bei der Generierung einer 4K×4K-Karte in unter 3 Sekunden
  • Hauptursache ist die ineffiziente Codegenerierung von Mono; selbst in einfachen Schleifen treten 15-fache Geschwindigkeitsunterschiede auf

Assembly-Vergleich: Mono vs. .NET

  • Vergleich der erzeugten x64-Assemblies mit identischem Testcode
    • Der .NET-JIT verschiebt schleifeninvariante Ausdrücke aus der Schleife heraus (Hoisting) und arbeitet nur mit einem Minimum an Registeroperationen
    • Mono wiederholt Speicherkopien mit Dutzenden von mov-Befehlen und verliert durch ineffizientes Inlining zusätzlich an Leistung
  • Laufzeit einer Schleife mit int.MaxValue Wiederholungen
    • .NET: 750ms, Mono: 11.500ms, Unity Editor (Debug): 67.000ms
  • Mono wiederholt innerhalb der Schleife unnötige Speicherbewegungen und Vergleichsoperationen

Bedeutung der CoreCLR-Einführung

  • CoreCLR bietet moderne Funktionen wie aktuellen JIT, Span<T>-API, SIMD-Optimierungen und Unterstützung für Hardware-Instruktionen
    • Diese Funktionen eröffnen Potenzial für zusätzliche Performance-Gewinne von mehr als 2x
  • Unitys Burst-Compiler erzeugt zwar auf LLVM-Basis nativen Code, bringt aber Einschränkungen bei C#-Features mit sich
    • Der moderne JIT von CoreCLR kann Burst-ähnliche Performance liefern und hat dabei weniger Sprachbeschränkungen
  • CoreCLR unterstützt AOT (Ahead-of-Time-Kompilierung), was schnellere Startzeiten und Unterstützung für Plattformen mit JIT-Einschränkungen (z. B. iOS) ermöglichen kann
    • Unity erklärt jedoch weiterhin, an IL2CPP festhalten zu wollen

Fazit: Unity braucht eine Modernisierung von .NET

  • Mono zeigt gegenüber modernem .NET eine 1,5- bis über 3-fach langsamere Ausführungsleistung und wirkt damit als versteckter Kostenfaktor für alle Unity-Projekte
  • Erwartete Effekte bei einer CoreCLR-Einführung
    • Bessere Laufzeitleistung, schnellere iterative Builds, verbesserte GC, Wegfall von Domain Reloads, größerer Anteil an Managed Code
  • Die Roadmap von Unity 6.x enthält zwar .NET Modernization, diese ist aber erst nach 2026 geplant
  • Wenn die CoreCLR-Unterstützung fertig ist, könnte sie sowohl Unity-Entwicklern als auch Spielern eine spürbare Leistungsrevolution bringen
  • Aktuell bleiben die Grenzen von Mono ein Performance-Flaschenhals für das gesamte Unity-Ökosystem

Noch keine Kommentare.

Noch keine Kommentare.