コアごとのスレッド（Thread-per-core）

• この記事は、Rust コミュニティにおけるマルチスレッド実行器の利用をめぐる議論を扱っており、これはタスクをバランスよく分配するために work-stealing を行う async ランタイムです。
• 一部の Rust ユーザーは、「thread-per-core」という代替アーキテクチャを提唱しており、こちらのほうが高性能で実装も容易だとしています。
• 「thread-per-core」という用語は誤解を招きやすいものです。すべてのマルチスレッド実行器は thread-per-core であり、コアごとに 1 つずつ OS スレッドを生成し、その上でタスクをスケジューリングします。
• Thread-per-core は 3 つのアイデアを組み合わせたものです。すなわち、ユーザー空間での並行処理、I/O を非同期化してスレッドのブロッキングを避けること、そして CPU コア間でデータを分割して同期コストと CPU キャッシュ間のデータ移動をなくすことです。
• この議論の中心は主に 3 つ目のポイントであり、async Rust を使えば最初の 2 つの要件は満たせます。
• Thread-per-core アーキテクチャでは、2 つの最適化を行えます。すなわち、スレッド間でタスクを steal することと、共有する状態を可能な限り少なくすることです。
• Work-stealing は、すべてのスレッドが常に仕事を持てるようにすることで tail latency を改善しますが、実装が難しく、同期コストやキャッシュミスを引き起こす可能性があります。
• Share-nothing は、データを単一の CPU コアに属するより高速なキャッシュ内に保持することで tail latency を改善しますが、複数のパーティションにまたがって状態を変更する必要がある複雑なアプリケーションでは実装が難しい場合があります。
• この記事は、共有状態を使うシステムでは、work-stealing が高負荷時の CPU 使用率を改善できる可能性があると示唆しています。

[GN⁺]

Hacker Newsの意見

• 議論の核心は、コアごとのスレッドのワークスティーリング executor ではなく、Rust における async/await が優れた抽象化かどうかです。
• コアごとのスレッドは、一般的な多コアサーバーにおける計算のスケーラビリティと効率を解決するために考案され、高スループットの I/O バウンドな処理に卓越していることが分かりました。
• コアごとのスレッドアーキテクチャは、そのスケーラビリティと効率性ゆえに今後も使われ続けるでしょうが、ほとんどのソフトウェアエンジニアは、現代的で慣用的なコアごとのスレッド設計がどのようなものかについての直感が限られています。
• 一部のアプリケーションは単一スレッドシステムにより適しており、Rust はこうした柔軟性を許容します。
• Rust の async プログラミングには批判があり、その中には Send + Sync + 'static が要求されることも含まれ、一部の人はそれを負担に感じています。
• Send bound は、executor スレッド間でのタスク移動を可能にするための要件であり、Rust async システムの欠点のように見えます。
• あらゆるプログラムに対して最良の性能を達成する画一的なアプローチはなく、async の使用は多くの Rust プログラムにとって早すぎる最適化と見なされます。
• カーネルのコンテキストスイッチはコストが高いためコアごとのスレッド設計が好まれますが、ユーザー空間でのコンテキストスイッチングスケジューリングも問題になり得ます。
• ワークスティーリングはテールレイテンシを解決する方法ですが、キャッシュミスや Send、Sync、'static のような追加の開発者制約をもたらします。