Ist Rusts `std::fs` langsamer als Python? Nein, es ist ein Hardwareproblem

 (xuanwo.io)
2 Punkte von GN⁺ 2023-11-30 | 1 Kommentare | Auf WhatsApp teilen

Sind die Python-Bindings von OpenDAL langsamer als Python?

  • OpenDAL ist eine Datenzugriffsschicht, die eine effiziente Abfrage von Daten aus verschiedenen Speicherdiensten ermöglicht.
  • Es gibt Berichte, dass die Python-Bindings von OpenDAL langsamer sind als Python selbst.
  • Als Hypothese werden interner Python-Cache, beschleunigtes Dateilesen und zusätzlicher Overhead durch PyO3 genannt.

Ist der OpenDAL-Fs-Service langsamer als Python?

  • Es handelt sich um ein Problem, an dem mehrere Faktoren beteiligt sind, darunter Rust, OpenDAL, Python und PyO3.
  • Es wurde festgestellt, dass auch der in Rust implementierte OpenDAL-Fs-Service langsamer ist als Python.

Ist Rusts std::fs langsamer als Python?

  • OpenDAL implementiert den Fs-Service über std::fs.
  • Es wurde bestätigt, dass auch eine Implementierung mit Rusts std::fs langsamer ist als Python.

Ist Rusts std::fs langsamer als Python? Wirklich!?

  • Das Ergebnis, dass Rusts std::fs langsamer als Python sei, wird infrage gestellt.
  • Es wird gelernt, wie man mit strace Systemaufrufe analysiert.
  • Trotz Auswertung der strace-Ergebnisse lässt sich nicht erklären, warum Python schneller ist, obwohl beide mmap verwenden.

Warum wird hier mmap verwendet?

  • mmap wird nicht nur zum Mapping von Dateien in den Speicher verwendet, sondern auch zur Zuweisung großer Speicherbereiche.
  • Wenn Speicher mit malloc angefordert wird, verwendet glibc zur Speicherzuweisung mmap.

Verwendet Python denselben Speicher-Allocator wie Rust?

  • Python verwendet einen auf kleine Allokationen optimierten Speicher-Allocator namens pymalloc.
  • pymalloc ist für kleine Objekte optimiert und verwendet für große Allokationen PyMem_RawMalloc() und PyMem_RawRealloc().

Ist Rust mit dem Standard-Speicher-Allocator langsamer als Python?

  • Es besteht der Verdacht, dass mmap das Problem verursacht.
  • Es wurde festgestellt, dass ein auf jemalloc umgestelltes Rust-Programm schneller läuft als Python.

Ist Rust nur auf meinem Computer langsamer als Python!

  • Dass Rust langsamer als Python läuft, tritt nur auf einem bestimmten Computer auf.
  • Es werden detaillierte Informationen zu CPU und Speicher bereitgestellt.
  • Auch nach Anpassungen an CPU-Schwachstellen-Mitigierungen, Transparent Hugepage und CPU-Core-Affinität ändert sich das Ergebnis nicht.
  • Mit einem eBPF-Programm wird bestätigt, dass Rust auch auf Ebene der Systemaufrufe langsamer ist als Python.

Ist C langsamer als Python?

  • Es wurde festgestellt, dass auch eine in C implementierte Version langsamer ist als Python.

Ist C langsamer als Python? Ohne festgelegten Offset!

  • Es wird entdeckt, dass es Unterschiede bei den Offsets im Speicherbereich gibt, und durch Anpassung des Offsets wird das C-Programm beschleunigt.
  • Auf AMD-Ryzen-CPUs wurde bestätigt, dass ohne einen bestimmten Offset ein Leistungseinbruch auftritt.

Ist ein AMD Ryzen 9 5900X ohne festgelegten Offset langsam!

  • Es wird bestätigt, dass es sich um ein CPU-bezogenes Problem handelt, und ein Kernel-Entwickler beteiligt sich an der Diskussion.
  • Durch Profiling mit perf wird erneut bestätigt, dass ohne Offset ein Leistungseinbruch auftritt.

GN⁺-Meinung: Der wichtigste Punkt dieses Artikels ist, dass Rust und C in bestimmten Hardware-Umgebungen langsamer als Python laufen können und dass dies auf Speicher-Allokation und bestimmte Verhaltensweisen der CPU zurückzuführen sein kann. Der Artikel zeigt durch die Untersuchung verschiedener Faktoren, die die Software-Performance beeinflussen, wie komplex die Wechselwirkung zwischen Hardware und Software sein kann. Diese Untersuchung liefert eine wichtige Lehre für die Lösung unerwarteter Probleme, die in der Welt des Software Engineerings auftreten können.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-30
Hacker-News-Kommentare

  • Meinung zu einer verwirrenden Prämisse

    Ein Nutzer zeigte sich irritiert über die Annahme, die Funktionen der Python-Standardbibliothek seien in reinem Python geschrieben. Er fand den Leistungsunterschied zwar interessant, da sowohl die Dateilesemethoden von Python als auch OpenDAL Python-Wrapper um nativen Code seien, hielt die Formulierung „langsamer als Python“ jedoch für seltsam. Er erwartete, dass die Funktionen der Python-Standardbibliothek in nativem Code implementiert und jeweils optimiert seien. Dass die Schlussfolgerung des Artikels mit der Funktionsweise von nativem Code zusammenhing, überraschte ihn nicht; über eine bestimmte Antwort war er zwar erstaunt, räumte aber ein, dass der Artikel trotz des verwirrenden Einstiegs sehr interessant gewesen sei.

  • Diskussion über CPU-Feature-Flags

    Es gebe zwei dedizierte CPU-Feature-Flags, die anzeigen, dass REP-STOS/MOV-Befehle als kurze Befehlssequenzen für memset/memcpy schnell und nutzbar seien. Für jede neue CPU-Generation von Hand optimierte Routinen zu erstellen, sei seit Jahrzehnten eine Qual. Es wurde die Frage aufgeworfen, ob das inzwischen nicht Teil der Timing-Test-Suite der CPU-Hersteller sein sollte.

  • Link zu einem relevanten glibc-Bug

    Es wurde ein Link zu einem glibc-Bug im Zusammenhang mit Zen 4 geteilt.

  • Positive Reaktion auf den Artikel

    Ein Nutzer schrieb, er habe den Artikel gelesen und sich schon darauf vorbereitet, über eine falsche Verwendung von std::fs zu spotten, aber der Artikel sei eine Abfolge von Kaninchenlöchern und Rätseln, gut geschrieben und sehr interessant.

  • Sehr hohe Bewertung des Artikels

    Ein anderer Nutzer bewertete den Artikel als den interessantesten, den er diese Woche gelesen habe, und lobte die hervorragende Schreibe.

  • Vorschlag zur Problemlösung

    Als offensichtliche Lösung wurde vorgeschlagen, einen Patch einzureichen, der die Kernel-Methode copy_user_generic so ändert, dass bei Erkennung einer betroffenen CPU und wenn die Speicherausrichtung den Langsamkeits-Bug auslöst, eine andere Implementierung für das Kopieren von Speicher verwendet wird.

  • Informationen über den Standard-Allocator von Rust

    Es wurde darauf hingewiesen, dass der Standard-Allocator von Rust bis 2018 jemalloc war, inklusive eines entsprechenden Links.

  • Überlegungen von Rust-Entwicklern zur Leistungssteigerung

    Es wurde die Frage gestellt, ob Rust-Entwickler erwägen sollten, für bessere Performance auf jemallocator umzusteigen, ob das ein Weg sei, mit dem alle kostenlos mehr Leistung bekämen, ob auch C-Codebasen davon profitieren könnten und ob derzeit Performance auf dem Tisch liegen bleibe.

  • Erklärung zu CPU-Unterschieden zwischen AMD und Intel

    Es wurde erklärt, dass AMD beim String-Store anders vorgehe als Intel und man dies besser nicht verwenden sollte, bevor die Größe des L2-Caches der CPU überschritten sei. Jenseits dieses Punkts sei der Einsatz von String-Store vorteilhaft und sollte mit „DRAM-Geschwindigkeit“ laufen, doch wegen der hohen Anlaufkosten müsse man bis zum Erreichen dieses Schwellenwerts 256-Bit-Vektor-Loads/Stores verwenden.

  • Artikel an die richtigen Leute weitergeleitet

    Ein Nutzer teilte mit, dass er den Artikel an die richtigen Personen weitergeleitet habe.