musl-Allokator: 25 % langsamere Rust-Programme
Don't use musl if you care about performance
Jonathan Ellis, Entwickler bei Brokk, warnt vor der Verwendung von musl als libc für leistungskritische Rust-Anwendungen. In Benchmarks mit Bifrost, einem Tool zur Code-Analyse, zeigte sich, dass musl im Vergleich zu glibc zu einer 25-prozentigen Leistungseinbuße führt. Selbst der Austausch des Allokators durch mimalloc oder jemalloc gleicht den Rückstand nicht aus – musl bleibt 26 % langsamer. Die Ursache liegt nicht nur im Allokator, sondern auch in langsamen Speicherfunktionen wie memcpy und memcmp. Ellis empfiehlt, für leistungssensitive Projekte glibc zu verwenden und musl nur für kleine Tools einzusetzen, bei denen die Performance keine Rolle spielt.
Dies ist eine wirklich schlechte Fußangel, die man den Benutzern überlässt, und ich denke, musl sollte ohne Allokator ausgeliefert werden und einen wählen lassen.
- matherial
Wenn dein Algorithmus so viele kleine Allokationen durchführt, dass der Allokator zum Engpass wird, machst du es bereits falsch. Der Allokator bringt zwangsläufig viel Overhead mit sich, weil er verschiedene Anwendungsfälle unterstützen, Fragmentierung vermeiden und idealerweise eine Vielzahl von Sicherheitsprüfungen implementieren muss. Wenn du etwas Allokationsintensives tust, allokierst und befreist du wahrscheinlich viele identische Strukturen, und du wärst besser dran, etwas kontinuierlichen Speicher zu nehmen und diesen selbst aufgabenspezifisch zu verwalten.
Aber die Realität ist, dass sich fast niemand wirklich um Leistung kümmert, weil Rechenleistung billiger ist als Fachwissen und Arbeitskraft, zumindest kurzfristig. Alles wird immer aufgeblähter und langsamer, und wir kompensieren das, indem wir CPU-Kerne, Gigabyte und Gigahertz hinzufügen.
- marssaxman
Die Leute haben so unterschiedliche Perspektiven. 26 % langsamer klingt für mich nicht "furchtbar"; es klingt nach einem ziemlich vernünftigen Preis, den man für den Komfort zahlen könnte, den musl bietet. Wenn musls Allokator 2,6-mal langsamer wäre, würde ich das vielleicht "nicht so toll" nennen ... aber um als "furchtbar" zu gelten, müsste der Unterschied meiner Meinung nach eine Größenordnung betragen!
- bloppe
Das ist nur ein Aspekt von "Leistung". glibcs Allokator ist vielleicht schneller, aber er verbraucht auch mehr Speicher.
Für eine viel technischere Diskussion siehe https://github.com/sharkdp/fd/issues/710
- mattrighetti
Habe das neulich gepostet, aber die ganze musl-Allokator-Sache scheint bekannt zu sein [0]
- grep_it
Ich denke, die Größe der gelinkten Binärdateien und die Einfachheit waren schon immer die Hauptmerkmale?