候補リストからテンソル化計算グラフへ

進化計算において、多様性はアルゴリズムが有効に機能するための前提です。十分な数の候補解を維持してはじめて、選択圧が早すぎる段階で集団を局所最適に押し込めることを防げます。しかし多様性は同時に膨大な計算量を意味します——1回の実行で数万、時には数百万の候補解を評価する必要があります。候補が通常のオブジェクト配列として書かれ、項目ごとのループで1つずつ評価に送られる場合、計算時間の大部分は本当の数値演算ではなく、項目ごとのスケジューリングとホスト言語の制御フローに消費されます。これこそが従来の逐次 CPU ループが数万回の候補評価を処理する際に低効率となる根本的な原因です。

表現方式の飛躍：候補リストからテンソル化計算グラフへ

EvoX がもたらす変化は、ある演算子の部分的な高速化ではなく、進化プロセスの表現方式の変革：从逐个候选的列表式处理，转向以张量为一等公民的批量计算。候选集合不再散落在对象数组里，而是与评价结果、算法状态一起被统一组织为张量，使它们可以整体参与运算。

• 候補テンソル：世代全体の候補を形状 [集団サイズ, 解の次元数] のテンソルとして記述します。このとき「1つの候補」はテンソル内の1行にすぎず、独立したホスト言語のオブジェクトではなくなります。
• バッチ演算子：変異などの操作は集団全体に直接作用し、1回の呼び出しで全候補の更新が完了します。N 回ループで呼び出す必要はありません。
• バッチ評価：evaluate(候補テンソル) の形で世代全体の評価結果を一度に取得します。評価の数量単位は「個」から「バッチ」へと変わります。
• 計算グラフ：選択と状態更新はもはや逐次制御ロジックではなく、グラフ内のノードとなります。それにより、演算子融合や並列スケジューリングといったコンパイル最適化の機会を得られます。

2つの記述方法の対比

リスト的な記述はおおよそ次のとおりです。候補を1つずつ取り出し、1つずつ評価し、1つずつ比較して状態を更新する——各ステップがホスト言語のループに依存し、全体として最適化するのが困難です。一方、テンソル化された記述は次のとおりです。候補テンソル → 変異 → 評価 → 選択 → 状態更新。チェーン全体がテンソル演算で構成され、1枚の計算グラフとして表現されるため、コンパイラはグラフ全体に対して融合とデバイススケジューリングを行えます。注意：アルゴリズムのロジック（変異分布、選択圧）は書き換えられておらず、書き換えられたのは表現方式です。