>>145563>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.
Naja, die C++-Seite hatte damit ja eine Müllabfuhr, welche nicht seriell ist. Deswegen war der Einwand, dass die Müllabfuhr in Firefox seriell ist/einen blockierenden Teil hat, schon richtig. Wenn die Müllabfuhr viel scannen muss (was eben auch im normalen Betrieb passieren kann, nur eben in kleinerem Maßstab), hält die Welt an.
>V8 ist viel zu komplex, als dass es um jede Mikrosekunde feilschen könnte.
Was soll das heißen? Das ist Flinte-ins-Korn-Schmeißen ("Performanz kriegen wir sowieso nicht hin") oder Performanzignoranz ("Performanz ist doch gar nicht wichtig").
Natürlich geht es auch bei V8 um Mikrosekunden, und zwar buchstäblich in den Bankmarken. Z.B. wenn man g++/glibc mit V8/Node.js vergleicht.
Den Problemen aus dem Bankmarken-Spiel haben sich auch andere angenommen:
>This is in contrast to other projects such as the Computer Language Benchmark game, which encourage finding the smartest possible way to express a problem in a language to achieve best performance, an equally interesting but different problem.
>To allow us to compare the degree of optimization done by the implementations as well as the absolute performance achieved, we set the following basic rules:
>The benchmark is 'identical' for all languages. This is achieved by relying only on a widely available and commonly used subset of language features and data types.
>The benchmarks should use language 'idiomatically'. This means, they should be realized as much as possible with idiomatic code in each language, while relying only on the core set of abstractions.
https://github.com/smarr/are-we-fast-yet
>C++98 gcc -O2 vs. Node.js 12.16
>all times in μs
https://github.com/rochus-keller/Are-we-fast-yet/blob/main/FreePascal/Are-we-fast-yet_FreePascal_results.pdf
>Unity ruckelt wegen Müllabfuhr-Spikes, obwohl Multi-Milliarden-Dollar-Firma, deren Brötchengeber das ist
>C# suspendiert Fäden, obwohl ebenfalls Multi-Billionen-Dollar-Firma, die in den 2000ern voll drauf abgefahren ist
>Java braucht kostenpflichtige VM
Tut mir Leid, das hört sich alles nicht nach einer Programmiersprache/Implementierung von der Stange an, die die Feuerfuchs-Entwickler einfach verwenden könnten.
Darüber hinaus hat Müllabfuhr das bereits angesprochene Grundproblem, dass sie eben ausgeführt werden muss. D.h. auch im behindertsten Moment loslaufen kann, insbesondere dann, wenn alle Fäden eigentlich schon was zu tun haben. Man hat damit etwas, das der Programmierer nicht steuern kann. Das ist schlecht, egal ob Teil der Programmiersprache/Implementierung, der Standardbibliothek der Programmiersprache oder von externen Bilbiotheken. Felix würde sogar sagen, man hat in den letzten Jahren (mit immer mehr Verbreitung von "Rahmenwerken" in vielen Bereichen der Computerey) immer mehr gesehen, dass Nichtsteuerbarkeit eine grundschlechte Idee ist. Wie soll der Programmierer da dann noch Performanz sicherstellen? Man schaue sich Bild relatiert an, und überlegt sich, wenn auf einem Faden plötzlich die Müllabfuhr reinplatzt.
Das ist Felixens Meinung nach ein Grundproblem, dem sich auch die Müllabfuhrleute merkwürdigerweise viel zu wenig angenommen haben.
>CL hat Laufzeitkompilierung von Kot als Standardfeature, es genügt also, den Kot in optimiertes CL zu übersetzen.
Wo ruft der Kot die Müllabfuhr von SBCL auf? Wie das gelöst wäre, wäre doch das interessante und der Knackpunkt, weil man das selbst steuern möchte und die Müllabfuhr nicht anspringen soll, wenn z.B. der Benutzer gerade die Seite scrollt.
Bonus: Felix sieht gerade, dass der Feuerfuchs mit
privacy.resistFingerprinting = true es nicht hinkriegt, auf DuRöhre ein 60-FPS-Video in doppelter Geschwindigkeit (=120 Hz) abzuspielen, ohne dass Frames gedroppt werden. Und ja, es liegt nicht nur ein Artefakt bei Zeitmessungen, sondern Felix konnte gedroppte Frames auf dem Monitor gerade nachweisen. Mit
privacy.resistFingerprinting = false ist es weg. Jetzt hat Felix also wieder ein Problem, das er nicht ignorieren kann, und mal wieder liegt es an irgendwelchem hochperformanten Hochperformanzkot...