Rustのstd fsはPythonより遅いのか？ いや、ハードウェアの問題だった

 (xuanwo.io)
2 ポイント 投稿者 GN⁺ 2023-11-30 | 1件のコメント | WhatsAppで共有

OpenDALのPythonバインディングはPythonより遅いのか？

  • OpenDALは、さまざまなストレージサービスからデータを効率的に取得できるようにするデータアクセスレイヤー。
  • OpenDALのPythonバインディングが、Python自体より遅いという報告がある。
  • 原因として、Python内部のキャッシュ、ファイル読み取りの高速化、PyO3の追加オーバーヘッドなどの可能性が仮説として示されている。

OpenDALのFsサービスはPythonより遅いのか？

  • Rust、OpenDAL、Python、PyO3など、複数の要素が関係する問題。
  • Rustで実装されたOpenDALのfsサービスも、Pythonより遅いことが判明した。

Rustのstd fsはPythonより遅いのか？

  • OpenDALはstd::fsを通じてfsサービスを実装している。
  • Rustのstd::fsを使った実装でも、Pythonより遅いことが確認された。

Rustのstd fsはPythonより遅いのか？ 本当に！？

  • Rustのstd fsがPythonより遅いという結果に疑問を呈している。
  • straceを使ってシステムコールを分析する方法を学んだ。
  • straceの結果を分析したものの、両者ともmmapを使っているにもかかわらず、なぜPythonのほうが速いのかは分からなかった。

なぜここでmmapを使うのか？

  • mmapはファイルをメモリにマップする以外にも、大規模なメモリ領域の割り当てに使われる。
  • mallocでメモリを要求すると、glibcがmmapを使ってメモリを割り当てる。

PythonはRustと同じメモリアロケータを持っているのか？

  • Pythonは、小さな割り当てに最適化されたpymallocというメモリアロケータを使っている。
  • pymallocは小さなオブジェクトに最適化されており、大きな割り当てにはPyMem_RawMalloc()とPyMem_RawRealloc()を使う。

RustはデフォルトのメモリアロケータでPythonより遅いのか？

  • mmapが問題を引き起こしていると疑われた。
  • jemallocに切り替えたRustプログラムが、Pythonより速く動作することが分かった。

Rustは自分のコンピュータでだけPythonより遅いのか！

  • RustがPythonより遅く動作するのは、特定のコンピュータでのみ発生していた。
  • CPUとメモリに関する詳細情報が示されている。
  • CPU脆弱性緩和機能、Transparent Hugepage、CPUコアアフィニティなどを調整しても、結果に変化はなかった。
  • eBPFプログラムを使って、RustがシステムコールレベルでもPythonより遅いことを確認した。

CはPythonより遅いのか？

  • Cで実装したバージョンでも、Pythonより遅いことが分かった。

CはPythonより遅いのか？ 指定オフセットなしで！

  • メモリ領域のオフセットに違いがあることを発見し、オフセットを調整することでCプログラムの速度を改善した。
  • AMD Ryzen CPUでは、特定のオフセットがないと性能低下が発生することが確認された。

AMD Ryzen 9 5900Xは指定オフセットなしだと遅いのか！

  • CPUに起因する問題であることが確認され、カーネル開発者も議論に参加した。
  • perfを使ったプロファイリングにより、オフセットなしでは性能低下が起きることが改めて確認された。

GN⁺の意見: この記事で最も重要な点は、RustやCが特定のハードウェア環境ではPythonより遅く動作し得ることであり、その原因がメモリ割り当てとCPUの特定の動作にある可能性があるということです。この記事は、ソフトウェア性能に影響を与えるさまざまな要素を探る過程を通じて、ハードウェアとソフトウェアの相互作用がいかに複雑になり得るかを示しています。こうした探求は、ソフトウェアエンジニアリングの世界で起こり得る予想外の問題を解決するうえで重要な教訓を与えてくれます.

関連記事

1件のコメント

 
GN⁺ 2023-11-30
Hacker Newsのコメント

  • 混乱を招く前提についての意見

    あるユーザーは、Python標準ライブラリの関数が純粋なPythonで書かれていると考えることに戸惑いを示している。Pythonのファイル読み込みメソッドもOpenDALも、どちらもネイティブコードをラップしたPythonラッパーであるという点で、性能差は興味深いが、「Pythonより遅い」と表現するのは奇妙だと感じている。Python標準ライブラリの関数実装はネイティブコードで、それぞれ最適化されているはずだと期待している。記事の結論がネイティブコードの動作方式に関係していること自体には驚かなかったが、特定の回答には驚いたとも述べており、混乱を招く導入にもかかわらず、非常に興味深い記事だったと認めている。

  • CPU機能フラグに関する議論

    2つの専用CPU機能フラグがあり、REP STOS/MOV命令がmemset/memcpyのための短い命令シーケンスとして高速かつ利用可能であることを示している。新しいCPU世代ごとに最適化済みルーチンを手作業で作るのは、何十年も続いてきた苦労だという。そろそろCPUメーカーのタイミングテストスイートの一部にすべきではないか、という疑問が呈されている。

  • 関連するglibcバグへのリンク

    Zen 4に関連するglibcバグへのリンクが共有されている。

  • 記事への好意的な反応

    あるユーザーは、std::fsの誤用をあざ笑うつもりで記事を読み始めたが、話が次々と深みに入り込むミステリーのようで、よく書かれていて非常に興味深いと評価している。

  • 記事への高評価

    別のユーザーは、この記事は今週読んだ中で最も興味深いものだったと評価し、文章も見事だと称賛している。

  • 問題解決のための提案

    明白な解決策として、「copy_user_generic」カーネルメソッドを変更し、CPUに問題があると検出され、メモリアラインメントが低速化バグを引き起こす場合には、別のメモリコピー実装を使うようにするパッチを送ることが提案されている。

  • Rustのデフォルトアロケータに関する情報

    Rustのデフォルトアロケータは2018年までjemallocだったという情報と、関連リンクが共有されている。

  • 性能向上のためにRust開発者が検討すべき点

    Rust開発者はjemallocatorへ切り替えて性能を向上させることを検討すべきなのか、これが誰もが無料で性能を得られる方法なのか、Cのコードベースもそこから恩恵を受けられるのか、現在取りこぼしている性能なのか、といった疑問が示されている。

  • AMDとIntelのCPUの違いに関する説明

    AMDの文字列ストア方式はIntelと異なり、CPUのL2サイズを超えるまでは使わないほうがよいと説明されている。その閾値を超えると文字列ストアを使う利点があり、「DRAM速度」で動作するはずだが、起動コストが高いため、その閾値に達するまでは256ビットのベクタロード/ストアを使うべきだと言及されている。

  • 記事を適切な人たちに共有したこと

    あるユーザーは、この記事を適切な人たちに転送したと明かしている。