>>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)
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 Bankmarken-Spiel ist ein Fach übelster Datenmüll, und die Zusammenfassungen sind noch schlimmer. Der Schaden, den Isaac Gouy mit diesem Mist angerichtet hat und weiterhin anrichtet, ist unglaublich.
>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.
>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
Das ist ein notorisches Unity-Problem. Unity benutzt(e?) aus Lizenzgründen die Boehms-Müllabfuhr, welche langsam ist, weil sie als malloc/free-Ersatz konzipiert wurde und davon enorm eingeschränkt wird. Viele Müllabfuhren erhöhen z.B. die Kosten von Zeigerzuweisungen minimal, um die Sammelphase (und damit u.a. Unterbrechungen) massiv zu beschleunigen; das alles ist mit Boehms nicht möglich.
>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.
Felix würde darauf gerne kompakt antworten, aber dein Bild von Müllabfuhr ist so vereinfacht, dass das schwierig ist. Daher muss es beim schnippischen "lies ein Buch" bleiben; Felix empfiehlt
The GC Handbook, dessen Raubmordkopie für diesen Kanal leider zu groß ist.