>>145543
>Die Profile zeigten, dass es Spikes von der Müllabfuhr waren, mit Aufrufstapel in der Müllabfuhr.
FF hat zwei GCs: Einen klassischen für JS (GC im Profil) und einen referenzzählerbasierten für C++ (CC im Profil, für Cycle Collector, weil Referenzzähler ohne sowas nicht alles behandeln können). Das hausgemachte Referenzzählergefrickel hat dann gefefelt [0] und tote Zyklen nicht als tot erkannt, diese aber später immer wieder gescannt. Hätte die C++-Seite einen vernünftigen GC, wäre das gar nicht erst passiert.

>Das Problem ist, dass das bereits zu langsam für eine JavaScript-Maschine ist, wenn bei V8 um jede Mikrosekunde gefeilscht wird.
V8 ist viel zu komplex, als dass es um jede Mikrosekunde feilschen könnte. Die Unterschiede aus dem Bankmarken-Spiel sind im Bereich der zuvorgenannten Compilerarbeit: Felix hatte z.B. vor kurzem aus C übersetzten CL-Kot gesehen, der in einer neuen SBCL-Version plötzlich 1.5x schneller lief, ein Fach weil einige der Optimierungen aus GCC und Co. nun auch in SBCL gelandet sind.

>Das sieht nach dem Gegenteil von voll-paralleler Müllabfuhr aus.
Ist aber nicht der Grund, warum Unity ruckelt. Das liegt am (insb. nicht-inkrementellen) Boehm-GC und eventueller Inderey.

>Gibt es überhaupt eine einzige weit verbreitete Programmiersprache/Implementierung, die nicht eine "stoppe die Welt"-Phase hat?
Komplett ohne Unterbrechung, egal wie klein? Azuls Implementation der JVM hat sowas, heißt C4 [1]. Ist proprietär und kostet, weil kaum einer einen wirklich pausenlosen GC braucht, und die, die ihn brauchen, dafür zahlen. OpenJDK hat ansonsten z.B. Shenandoah [2], welcher üblicherweise Pausen im niedrigen einstelligen Millisekundenbereich hat. Man bemerke auch die Heap-Größen. SBCL hatte vor ein zwei Jahren auch sowas im Anmarsch, aber Felix weiß nicht, wie der Stand da gerade ist. Anmerkung nebenbei: Latenz ist nicht alles. Kürzere Pausen bedeuten praktisch immer niedrigeren Durchsatz, was für sehr viele Programme viel relevanter ist.

>Wie soll der gejittete Maschinenkot die Müllabfuhr von Programmiersprache X aufrufen?
CL hat Laufzeitkompilierung von Kot als Standardfeature, es genügt also, den Kot in optimiertes CL zu übersetzen:

Die Definition der Funktion ist hier eine Konstante, aber die kann auch zur Laufzeit berechnet werden.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1939295#c18
[1] https://docs.azul.com/prime/c4-garbage-collection
[2] https://wiki.openjdk.org/display/shenandoah/Main

>Pannierung bis 23.1.
Da hast du mich aber eben erschreckt, dass die Wahl schon im Januar stattfindet.

>>145517
>>>Sind in Felixens Welt alle Müllabfuhren seriell und halten die Welt an?
>>Genau das war ja beim Käfer der Fall.
>Nein, das Problem war, dass bestimmte Dinge fälschlicherweise von der Müllabfuhr ausgenommen waren und sich dann anstauten.
Aber selbst dann würde nicht stottern, wenn es parallel wäre und die Welt nicht anhalten würde. Da es stotterte, gab es einen seriellen Teil, der alles blockiert.
Die Profile zeigten, dass es Spikes von der Müllabfuhr waren, mit Aufrufstapel in der Müllabfuhr.

>>fannkuch-redux (1.20x), n-body (1.52x), spectral-norm (0.95x), mandelbrot (1.78x)
>Ist Felixens Erfahrung nach realistisch. Er schließt dennoch nicht aus, dass auch die Vergleiche schwachsinnig sind und bloß zufällig in der richtigen Größenordnung landen.
Das Problem ist, dass das bereits zu langsam für eine JavaScript-Maschine ist, wenn bei V8 um jede Mikrosekunde gefeilscht wird.

Gibt es überhaupt eine einzige weit verbreitete Programmiersprache/Implementierung, die nicht eine "stoppe die Welt"-Phase hat?

>Das ist ein notorisches Unity-Problem.
Wenn ich mir C# allgemein anschaue (Jahr 2017):
>Above, we see GC was triggered by thread 2948 and it waits for the CLR to suspend all managed threads.
https://devblogs.microsoft.com/premier-developer/understanding-different-gc-modes-with-concurrency-visualizer/
Das sieht nach dem Gegenteil von voll-paralleler Müllabfuhr aus.

>Daher muss es beim schnippischen "lies ein Buch" bleiben; Felix empfiehlt The GC Handbook, dessen Raubmordkopie für diesen Kanal leider zu groß ist.
Danke für den Buchtipp, Felix wird es sich mal anschauen.

Darüber hinaus gibt es aber noch das Problem der Sprachbarriere. Es geht hier darum, mit Programmiersprache X eine JavaScript-Maschine (und deren Anbindungen ans DOM) zu schreiben. Wenn man den Fall hat, dass X eine Müllabfuhr hat, dann geht es hier um die Idee, dass man diese Müllabfuhr auch für das, was in der JavaScript-Maschine ausgeführt wird, verwendet (und zwar die gleiche Müllabfuhr-Instanz in und außerhalb der Maschine, wegen Abhängigkeit zwischen DOM/dahinterhängenden JS-APIs und dem Kot in der JavaScript-Maschine). Eine JavaScript-Maschine muss Maschinenkot jitten (siehe Performanz oben). Wie soll der gejittete Maschinenkot die Müllabfuhr von Programmiersprache X aufrufen? Dafür muss in der Programmiersprache X selbst es Funktionalität geben, mit der man die Müllabfuhr des eigenen Programms steuern kann, aber hoffentlich ohne explizite Allokationen/Deallokationen, sonst ist man wieder an der gleichen Stelle wie ohne Müllabfuhr.

Die Diskriminierungsklage gegen OP ist eingereicht. Es ist die richtige Zeit zu schauen, ob die Rechtsschutzversicherung noch nicht abgelaufen ist.

>>145492
>Naja, da steht schon "real existierend", was sich auf eine Implementierung beziehen sollte.
Es ging Felix darum, dass z.B. Schedulierung und Vektorisierung am oberen Ende einen verdammt großen Teil ausmachen und die Fachleute für sowas aus offensichtlichen Gründen eher an GCC, Clang/LLVM und MSVC arbeiten statt an irgendeiner Sprachimplementation mit geringerem "Wirkungsgrad". Große Verbesserungen sind da oft überraschend schnell zu erreichen, sodass "Performanz von X" nicht so viel heißt, wie man vielleicht denkt. Gilt auch am unteren Ende, siehe z.B. CPython/PyPy.

>Ich mag das Bankmarken-Spiel nicht, aber da ist SBCL ungefähr Faktor 5x lahmer
Felix ist mal durch die g++/SBCL-Vergleiche gegangen:
>k-nucleotide (4.36x)
Eigene Haschischtabelle implementieren ist haram, aber den halben Kot dafür verwenden, eine sonst nutzlose Haschischfunktion zu implementieren, ist okeh. Felix hat das mal lokal auf seinem Vor-AVX2-Rechner probiert und kam auf Faktor 2.05x, was für bessere Autovektorisierung spricht, aber der CL-Kot ist eine grottenschlechte Übersetzung aus dem Javanischen, sodass da wahrscheinlich auch was zu holen ist.
>fasta (5.74x)
g++-Programm hat Mehrfadierung und SIMD-Intrinsiken, SBCL-Programm nicht. Nimmt man das schnellste g++-Programm ohne diese Tricks und behebt den peinlichen Performanztöter im RNG des SBCL-Programms (Konstanten nicht als Konstanten deklariert und Funktion nicht einlinierbar), kommt man auf 1.24x.
>reverse-complement (0.84x)
Die Bankmarke ist so vernachlässigt, dass das schnellste GCC-Programm fast sieben mal schneller als das schnellste g++-Programm ist. Spricht Bände. Das schnellste vergleichbare GCC-Programm kriegt Faktor 3.57x hin, aber der CL-Kot ist auch hier ziemlich fragwürdig.
>binary-trees (3.09x)
Das ist eine Müllabfuhr-Bankmarke, bei der Aufmotzen GC-Tuning verboten und explizite Speicherpools erlaubt sind. Weil das noch nicht sinnlos genug ist, müssen Speicherpools natürlich auch aus einer Bibliothek kommen; wenig überraschender Weise gibt es diese hauptsächlich für Sprachen ohne Müllabfuhr. Keine Ahnung, was man saufen muss, um sich solche Messkriterien auszudenken.
>pidigits (4.68x)
Ein Dutzend Sprachen kämpft darum, welche am besten GMP einbetten kann. Gewinner sind Sprachen mit miserablem Zahlenturm, weil dies ihnen die Lizenz gibt, GMP explizit als Bibliothek mit minimalem Überkopf zu benutzen.
>regex-redux (12.19x)
Vergleicht PCRE2 mit CL-PPCRE und hat daher nichts mit den Sprachen zu tun. CL-PPCRE ist zwar beliebt, aber nicht gerade für Performanz bekannt. C++ hat eingebautes Regex, aber das ist so arschlahm, dass kein einziges eingereichtes Programm auch nur versucht, es zu benutzen. Letzteres kann Felix ehrlich gesagt nicht kritisieren.
>fannkuch-redux (1.20x), n-body (1.52x), spectral-norm (0.95x), mandelbrot (1.78x)

mein SACK

hab mich eingekackert

>>145452
>Das ist eher eine Kompiler- bzw. Implementationsfrage
Naja, da steht schon "real existierend", was sich auf eine Implementierung beziehen sollte.
Bei C/C++: Gibt nur 3 in Frage kommende Implementierungen, und zwar ähnlich gute Implementierungen.
Bei müllabführenden Sprachen: Gibt in der Regel (C#, Java, JavaScript) einen Platzhirsch, ansonsten nehme die dir genehme Implementierung.
Wobei die Implementierung natürlich egal ist, weil alle Müllabfuhr-basierten Sprachen, in egal welcher Implementierung, huntslahmer Müll sind (nicht ganz ernst gemeint, oder doch?)

>SBCL ist mit Typdeklarationen z.B. heute schon gut im Rennen.
Ich mag das Bankmarken-Spiel nicht, aber da ist SBCL ungefähr Faktor 5x lahmer, was für eine JavaScript-Maschine den absoluten Tod bedeuten würde (bei JavaScript-Maschinen wird darum gekämpft, wer 5-10 % schneller als die JavaScript-Konkurrenz ist).
https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html

>Die Anforderung ist kompletter Unsinn. Sind in Felixens Welt alle Müllabfuhren seriell und halten die Welt an?
Genau das war ja beim Käfer der Fall. Wenn man den Brauserinhalt gescrollt hat, ist buchstäblich ein Streifen vom Bildausschnitt mit Fensterhintergrundfarbe gefüllt worden, und erst nach dem Ende der Müllabfuhr, 7 Sekunden später, wurde der Bildinhalt gerendert und ging es weiter. Das hängt auch damit zusammen, dass JavaScript einzelfadig ist - wenn der eine, einzige JavaScript-Faden stoppt, ist auch die Seite eingefroren.

>Currently, all modern engines ship a mark-and-sweep garbage collector. All improvements made in the field of JavaScript garbage collection (generational/incremental/concurrent/parallel garbage collection) over the last few years are implementation improvements of this algorithm, but not improvements over the garbage collection algorithm itself nor its reduction of the definition of when "an object is no longer needed".
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_management

So, und nun die Frage: Wenn der JavaScript-Faden gerade läuft, wie soll man währenddessen von einem anderen Faden auf die Objekte in der JavaScript-Maschine zugreifen, während die Maschine gerade ausgeführt wird und diese Objekte manipuliert und neue Objekte erstellt/die Referenzen zwischen diesen Objekten umbiegt? Genau, dafür braucht man entweder einen Globalen-Interpretierer-Lock (CPython) oder feingranulare Locks/Mutexe, die bei jeder solchen Stelle im JavaScript-Interpretierer den Interpretierer sperren. Und sperren bedeutet Jank.

Weiteres Problem: Die Müllabfuhr muss ja auf irgendeinem Faden laufen (Endgegner: System hat nur 1 Kern), und wenn alle Fäden bereits vom Brauser belegt sind, und die Müllabfuhr laufen soll, muss einer der anderen Fäden anhalten. Dann stoppt hoffentlich nicht der aktuelle Tab, weil der ja gerade in Benutzung ist. Aber hoffentlich auch kein Hintergrundtab, in dem gerade ein DuRöhre-Video abgespielt wird, und dann die Musik stoppt, wenn die Müllabfuhr zu lange dauert und die JavaScript-Engine nicht mehr die Audio-API füttert. Jedenfalls hat C# extreme Probleme mit Müllabfuhr, wie man bei Unity sieht, und die müssen große Klimmzüge unternehmen, um die Müllabfuhr und den damit einhergehenden Jank/Spikes zu umgehen:
https://embrace.io/blog/garbage-collector-spikes-unity/
In Unity sind ~5 ms bereits eine inakzeptable Zeit für die Müllabfuhr, weil das länger als ein ganzer Frame auf einem guten Monitor ist. Ein Brauser soll aber so flüssig wie eine Spiele-Maschine laufen. Lösung in Unity ist natürlich, native Allokationen und Deallokationen, die die Müllabfuhr nicht sieht, zu benutzen. Also diesbezüglich keine Müllabfuhr zu benutzen.

>Welche real existierende müllabführende Programmiersprache bietet überhaupt [...]?
Aber ich entnehme deiner Antwort, dass es aktuell keine hier verwendbare Programmiersprache dafür gibt.

>>145452
Die Lösung ist natürlich verteiltes Echtzeit-Java!

>>145370
>*Performanz auf dem Niveau von C/C++
Das ist eher eine Kompiler- bzw. Implementationsfrage statt einer Sprachfrage; C++ hatte früher mal den Ruf, arschlahm zu sein. SBCL (Common Lisp) ist mit Typdeklarationen z.B. heute schon gut im Rennen.

>*Man muss die Müllabführ zeitweise unterbinden, zeitlich selber auslösen, und jederzeit beim Laufen unterbrechen können (sonst Brauser-Jank)
Die Anforderung ist kompletter Unsinn. Sind in Felixens Welt alle Müllabfuhren seriell und halten die Welt an?

>>145425
Deshalb SVP wählen!

Wenigstens werden die Fotzen jetzt gebannt.

wat?
> Müllabfuhr
damit hatte Felix schon vong Ewigkeit her ein Problem. Auf'm Schoßauf war die nie so richtig zugange; regelmäßiger Neustart erforderlich.

War aber auch so'n Frickelschoßauf mit vong eigentlcih für Fenster, aber irgendwie Penguin draufgeklatscht.

Pisse und Scheiße aus meinem Arschloch

>>145353
Jetzt mal realistisch gesehen: Wenn Mozilla so eine müllabführende Programmiersprache entwickelt, wird dadurch der bisher schon dünne Personalbestand an Entwicklern nur noch dünner.

Welche real existierende müllabführende Programmiersprache bietet überhaupt
*Performanz auf dem Niveau von C/C++
*Man muss die Müllabführ zeitweise unterbinden, zeitlich selber auslösen, und jederzeit beim Laufen unterbrechen können (sonst Brauser-Jank)
?

>>145340
Dort unten würde die Müllabfuhr aber deutlich mehr Zeit und Arbeit abbekomben.

>>145337
Naja, sie müssen eben einen Javascript-Interpretierer mit Müllabfuhr implementieren, das ist deren Aufgabe. Und wenn man den Javascript-Interpretierer in einer Programmiersprache mit Müllabfuhr implementieren würde, müsste jemand den Kompilierer mit Müllabfuhrunterstützung für diese Programmiersprache implementieren, wo dann ebenfalls Fehler mit der Müllabfuhr lauern könnten. Damit verschiebt man das Problem nur, es ist Müllabfuhr den ganzen weg runter.

Problem war wohl eher, dass nicht genug Sozialismus Müllabfuhr drin war. Hätte man die von vornherein verwendet, anstatt seine eigene fehlerbehaftete drumherum zu zimmern, hätte man dieses Problem gar nicht gehabt.

Von der fetten Groben

Pisse Kacke und Arschwurst. Ich mag gerne Arschwurst. Magst du auch gern Arschwurst, Feliks?