Tokioの性能を限界突破！順序より進捗を優先して100万タスクを爆速処理する秘訣

Tokioにおいて、順序の制御よりも進捗率（Progress）を重視することで、100万ものタスクを効率的にスケジュールする方法について解説します。非同期処理のボトルネックを解消し、スループットを最大化するための設計思想に迫ります。

こういう教訓って、みんな痛い目を見て学ぶものだよな。俺もそうだったし。

実際のシステムで堅牢なスケジューラを設計するのが難しいのは、2つの性質がぶつかり合うからだ。理論的に最適なスケジュールはタスクのレイテンシに上限を設けることを保証しないし、ランタイムのスケジューリング自体がAIコンプリート（AIと同等の難しさを持つ問題）だからね。

実際には、レイテンシには上限が必要で、それもかなり厳しく求められることが多い。スケジューラの実装はメモリやコンピューティングのリソースが限られた中で動かなきゃいけない。これは「AIコンプリート」なアルゴリズムが要求するものとは相容れない性質で、せいぜい極めて狭い範囲での大雑把な近似解を出すのが限界なんだ。

こうした制約があるから、汎用的なスケジューラは壊れやすかったり、効率が悪かったり（大抵はその両方）するわけだ。かといって、個別の実装に合わせた専用のスケジューラを設計するのも、単純なアプリ以外ではめちゃくちゃ難易度が高い。文献がある中で比較的近い例はキャッシュ置換アルゴリズムだけど、あれはレイテンシの上限が問題にならない、かなり限定的なケースに過ぎないしな。

こうした設計上の問題を解決する手法は、歴史的に「レイテンシ隠蔽（latency-hiding）」の枠組みで扱われてきた（HPCの世界など）。ソフトウェアに関しては文献がほとんど皆無に等しいし、ハードウェア特有の制約や性質はそのままソフトウェアには当てはまらないことが多いんだよ。