spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BlueCobold«

Zitat von »Chromanoid«

Naja, das worauf ich hinaus will, sind eher Sachen wie zig Referenzen, die irgendwie zu einem Zyklus führen, ohne dass man überhaupt einen Graphen entwickeln will.

Das ist in Referenz-Sprachen ein echtes Problem. In C++ ist das z.B. überhaupt gar keins, denn bei sauberer C++ Verwendung, ist das technisch nicht möglich zu implementieren.

Es ist eben i.d.R. kein Problem bei GC-Sprachen, weil das einfach der natürliche Programmierstil dieser Sprachen ist. Und von dem behaupte ich, dass er einfacher ist als der Programmierstil ohne GC. Nur weil man das technisch nicht mit C++ lösen kann, heißt das nicht, dass der Use Case nicht berechtigt ist.

Zitat von »BlueCobold«

Interfaces oder nicht sind hier völlig irrelevant.

Naja, sonst könnte man argumentieren, dass man den Zyklus mit statischer Code Analyse ja sehr leicht finden kann.

Zitat von »BlueCobold«

Du darfst durchaus zyklische Datengraphen haben. Aber du solltest niemals einen Besitz-Zyklus haben. In sauberem C++ kannst Du so einen bei klarem Verstand nicht versehentlich bauen. In Java oder C# ist das natürlich überhaupt kein Problem und da ist der Fehler.

Wenn man alles sauber und mit klarem Verstand machen würde, dann gäbe es ja gar keine Probleme, egal welche Sprache man verwendet.

Zitat von »dot«

Nochmal: Der GC managed nicht Speicher allgemein, der GC managed nur Heapobjekte und sonst nichts. Und genau das ist das Problem...

Das sehe ich nicht so. In vielen Fällen ist die Anzahl der extern verwendeten Ressourcen irrelevant. Transaktionen und Datenbankzugriffe werden wegabstrahiert.

Ich glaube wir kommen aus unterschiedlichen Welten der Entwicklung. Die Entwicklungen, die ich so kenne, würden mit einer Nicht-GC-Sprache viel komplizierter sein. Genau weil man sich um Besitz-Verhältnisse usw. in besonderem Maße kümmern muss. Ich glaube man kann hier wirklich ad populum argumentieren, weil es am Ende Menschen sind, denen die Entwicklung gelingen und möglichst auch Spaß bringen muss.

Vielleicht geht es ja um einen Konflikt, den Rasmus Lerdorf (Erfinder von PHP) mal beschrieben hat:

Zitat

* I actually hate programming, but I love solving problems.
* There are people who actually like programming. I don’t understand why they like programming.
* I’m not a real programmer. I throw together things until it works then I move on. The real programmers will say “Yeah it works but you’re leaking memory everywhere. Perhaps we should fix that.” I’ll just restart Apache every 10 requests.

Bei so einer Einstellung ist man mit einer GC-Sprache deutlich besser dran. Mir geht es nicht so wie Lerdorf, aber ich hasse es mich um technische Details zu sorgen, die ich auch automatisch machen lassen kann. Ich will möglichst abstrakt arbeiten.

Zitat von »BlueCobold«

Und Swift hat weder, noch braucht es, einen GC.

Das wird sich zeigen. Ich finde ARC eine gute Sache. Python nutzt das ja auch - zusammen mit Zyklus-Erkennung durch einen GC. Ich bin ja kein absoluter Fan von GC sondern dem Feature, dass ich mich nicht um Speicherverwaltung kümmern muss.

Zitat von »BlueCobold«

Wahlweise kann ich dafür auch eine Sprache verwenden, die solche Prüfungen unabdingbar macht. Wie eben z.B. Swift oder Rust.

Ja, oder zum Beispiel den neuen Stern (?) am JVM Himmel Kotlin. Ganz interessanter Beitrag zu dem Thema von Lukas Eder (ein bekannter Java-Ökosystem-Blogger) mit einer weiteren interessanten neuen JVM-Sprache Ceylon: https://blog.jooq.org/2016/03/15/ceylon-…ot-nulls-right/

Zitat von »Chromanoid«

Vielleicht geht es ja um einen Konflikt, den Rasmus Lerdorf (Erfinder von PHP) mal beschrieben hat:

Zitat

* I actually hate programming, but I love solving problems.
* There are people who actually like programming. I don’t understand why they like programming.
* I’m not a real programmer. I throw together things until it works then I move on. The real programmers will say “Yeah it works but you’re leaking memory everywhere. Perhaps we should fix that.” I’ll just restart Apache every 10 requests.

Bei so einer Einstellung ist man mit einer GC-Sprache deutlich besser dran. Mir geht es nicht so wie Lerdorf, aber ich hasse es mich um technische Details zu sorgen, die ich auch automatisch machen lassen kann. Ich will möglichst abstrakt arbeiten.

Und genau damit wären wir wieder bei der Argumentation von Go, welche nebenbei sicher einige Beispiele für große robuste Software hergibt. Google setzt sie ein, dann weiß ich noch von Soundcloud und man findet viele weitere Beispiele auf Youtube, in denen erklärt wird warum diese Sprache. Dabei ging es nicht unbedingt vor allem um den GC, aber da habt ihr (dot, blue) mal Beispiele für große robuste Software...

Zitat von »Chromanoid«

Naja, sonst könnte man argumentieren, dass man den Zyklus mit statischer Code Analyse ja sehr leicht finden kann.

Hier sind wir bei den Worten hinreichend und notwendig...
Ich kann bei Interface-Verwendung einen Referenz-Zyklus in Java nicht ausschließen. Das könnte ich, wenn es keine Interfaces gäbe. Das ist richtig. Ich kann so einen Zyklus in C++ aber trotz (!!!) Interfaces ausschließen! Sofern also meine Aussage, dass nicht Interfaces die Ursache für das Problem sind, sondern die Unmöglichkeit für den Entwickler in C# oder Java eine Ownership zu definieren und somit Zyklen zu verhindern, die gar nicht notwendig sind. Im Gegenteil, die Sprachen und Referenzen zwingen den Entwickler quasi Ownership-Zyklen dort zu bauen, wo gar keine sein müssten. Und das Problem überlässt man dann dem GC, auf dass er das irgendwann irgendwo auflöse und vernichte. Was er aber auch nur bei Heap-Objekten kann und was bei Ressourcen ein echtes Problem wird. Ich denke da z.B. an Video- oder Audio- oder Textur-Daten. Genau solche Sachen sind in Spielen ein echtes Problem, wo man plötzlich anfängt wild Sachen auf null zu setzen und GC.collect zu rufen und solch grauenvolle Dinge... und das nur in der Hoffnung (und ohne Garantie!), dass es was hilft und man nicht out of memory geht.

Zitat von »Chromanoid«

Wenn man alles sauber und mit klarem Verstand machen würde, dann gäbe es ja gar keine Probleme, egal welche Sprache man verwendet.

Nein. Eben nicht. Es ist in Java unmöglich festzustellen, ob und wann Du mit einem Objekt einen Daten-Zyklus baust und wann nicht. Das hast Du doch sogar schon selbst festgestellt beim Thema Interfaces. Da kann man noch so sehr bei klarem Verstand sein, man kann es gar nicht entscheiden.

Zitat von »BlueCobold«

Nein. Eben nicht. Es ist in Java unmöglich festzustellen, ob und wann Du mit einem Objekt einen Daten-Zyklus baust und wann nicht. Das hast Du doch sogar schon selbst festgestellt beim Thema Interfaces. Da kann man noch so sehr bei klarem Verstand sein, man kann es gar nicht entscheiden.

Muss man doch i.d.R. auch gar nicht, weil der GC das sehr gut lösen kann. Du misst hier die Qualität der Abhängigkeiten/Besitzstrukturen mit dem Maß eines C++-Entwicklers. Das ist bei GC-Sprachen aber das falsche Maß. Ich messe doch auch nicht C++-Strukturen mit dem Qualitätsmaß von Java-Entwicklern. Ich sage lediglich, dass ich häufig so entwickeln möchte, dass das Maß der GC-Sprachen besser passt und ich glaube, dass das sehr vielen so geht.

Tja, ich eben nicht. Ich sehe bei einem GC eben spätestens seit C++11 keinen Vorteil mehr, sondern nur noch Nachteile. Auch in C++ muss ich mich nicht um Memory-Management kümmern und da gibt es keinen GC und auch keine Probleme mit Ressourcen-Freigabe.

Und wieso soll ich nicht mit C++ Augen messen? Es geht doch gerade darum, ob ein GC ein Fluch oder Segen ist. Ich sehe, wie sauber Memory-Management in C++ oder Swift arbeitet, komplett ohne GC. Und daran messe ich GC-Sprachen. Ich kann doch schlecht aus Java-Sicht beurteilen wie toll oder schlecht der GC ist? Ich kann das doch nur mit einem Vergleich einer Sprache machen, die keinen GC besitzt, um beurteilen zu können, ob ein GC toll ist oder nicht. Beziehungsweise muss ich das nicht unbedingt, ich sehe ja auch so, dass C# und Java bei Ressourcenfreigabe arge Probleme haben und das Problem ist der GC. Du hast behauptet, dass Zyklen ein Problem darstellen ohne GC, weil sie nicht beräumt werden können. Können sie aber. Dann meintest du, dass das in Referenz-Sprachen nicht so einfach geht. Und da hast du definitiv Recht. Ohne GC lässt sich eine Sprache wie C# oder Java nicht sauber verwenden, eben weil es kein vernünftiges Konzept für Ownership gibt (oder Weak<T> schlicht von niemandem verwendet wird, was auch eher abstrus wirken würde).

Zitat von »BlueCobold«

Was er aber auch nur bei Heap-Objekten kann und was bei Ressourcen ein echtes Problem wird. Ich denke da z.B. an Video- oder Audio- oder Textur-Daten. Genau solche Sachen sind in Spielen ein echtes Problem, wo man plötzlich anfängt wild Sachen auf null zu setzen und GC.collect zu rufen und solch grauenvolle Dinge... und das nur in der Hoffnung (und ohne Garantie!), dass es was hilft und man nicht out of memory geht.

Genau an diesen Stellen muss man sich eben Gedanken machen ob eine GC-Sprache die richtige Wahl ist. Ich weiß nicht wie man i.d.R. mit Unity arbeitet, aber ich glaube so "wo man plötzlich anfängt wild Sachen auf null zu setzen und GC.collect zu rufen und solch grauenvolle Dinge" hoffentlich nicht.

Ich bin mir ehrlich gesagt nicht mal sicher, ob Unity Ressourcen überhaupt managed verwaltet oder ob das nicht der darunter liegende C++ Kern der Anwendung anders löst.

PS: Siehe Edit des vorherigen Posts.

Zitat von »BlueCobold«

Tja, ich eben nicht. Ich sehe bei einem GC eben spätestens seit C++11 keinen Vorteil mehr, sondern nur noch Nachteile. Auch in C++ muss ich mich nicht um Memory-Management kümmern und da gibt es keinen GC und auch keine Probleme mit Ressourcen-Freigabe.
Und wieso soll ich nicht mit C++ Augen messen? Es geht doch gerade darum, ob ein GC ein Fluch oder Segen ist. Ich sehe, wie sauber Memory-Management in C++ arbeitet, komplett ohne GC. Und daran messe ich GC-Sprachen.

Ich dachte wir argumentieren ganz allg. darüber. Und da ist meine Antwort natürlich "It depends" mit Tendenz zu "Meist ein Segen" und Deine scheinbar "Immer ein Fluch".

Nein, meine Einschätzung ist, dass ich mit einem GC nichts geliefert bekomme, was mir einen Mehrwert über die "manuelle" Speicherverwaltung in C++ oder Swift liefert. Also wozu sollte ich mir diese Nachteile an's Bein binden wollen? Ich würde das nicht unbedingt als Fluch bezeichnen, aber schön finde ich's definitiv nicht.