私はパフォーマンス クリティカルな二分決定木を持っています。この質問を 1 行のコードに絞り込みたいと思います。二分木反復子のコードは、それに対して実行されたパフォーマンス分析の結果とともに以下に示されます。
public ScTreeNode GetNodeForState(int rootIndex, float[] inputs)
{
0.2% ScTreeNode node = RootNodes[rootIndex].TreeNode;
24.6% while (node.BranchData != null)
{
0.2% BranchNodeData b = node.BranchData;
0.5% node = b.Child2;
12.8% if (inputs[b.SplitInputIndex] <= b.SplitValue)
0.8% node = b.Child1;
}
0.4% return node;
}
BranchData はフィールドであり、プロパティではありません。インライン化されないリスクを防ぐためにこれを行いました。
BranchNodeData クラスは次のとおりです。
public sealed class BranchNodeData
{
/// <summary>
/// The index of the data item in the input array on which we need to split
/// </summary>
internal int SplitInputIndex = 0;
/// <summary>
/// The value that we should split on
/// </summary>
internal float SplitValue = 0;
/// <summary>
/// The nodes children
/// </summary>
internal ScTreeNode Child1;
internal ScTreeNode Child2;
}
ご覧のとおり、while ループ / null チェックはパフォーマンスに大きな打撃を与えます。ツリーは巨大なので、葉の検索にはしばらく時間がかかると思いますが、その 1 行に費やされる不釣り合いな時間を理解したいと思います。
私はもう試した：
- Null チェックを while から分離する - ヒットするのは Null チェックです。
- オブジェクトにブールフィールドを追加してそれをチェックしても、違いはありませんでした。何を比較するかは問題ではありません。問題は比較です。
これは分岐予測の問題ですか? もしそうなら、私はそれについて何ができますか？何かあれば？
私はCILを理解しているふりをするつもりはありませんが、 CIL を理解している人のために投稿して、そこから情報をかき集められるようにします。
.method public hidebysig
instance class OptimalTreeSearch.ScTreeNode GetNodeForState (
int32 rootIndex,
float32[] inputs
) cil managed
{
// Method begins at RVA 0x2dc8
// Code size 67 (0x43)
.maxstack 2
.locals init (
[0] class OptimalTreeSearch.ScTreeNode node,
[1] class OptimalTreeSearch.BranchNodeData b
)
IL_0000: ldarg.0
IL_0001: ldfld class [mscorlib]System.Collections.Generic.List`1<class OptimalTreeSearch.ScRootNode> OptimalTreeSearch.ScSearchTree::RootNodes
IL_0006: ldarg.1
IL_0007: callvirt instance !0 class [mscorlib]System.Collections.Generic.List`1<class OptimalTreeSearch.ScRootNode>::get_Item(int32)
IL_000c: ldfld class OptimalTreeSearch.ScTreeNode OptimalTreeSearch.ScRootNode::TreeNode
IL_0011: stloc.0
IL_0012: br.s IL_0039
// loop start (head: IL_0039)
IL_0014: ldloc.0
IL_0015: ldfld class OptimalTreeSearch.BranchNodeData OptimalTreeSearch.ScTreeNode::BranchData
IL_001a: stloc.1
IL_001b: ldloc.1
IL_001c: ldfld class OptimalTreeSearch.ScTreeNode OptimalTreeSearch.BranchNodeData::Child2
IL_0021: stloc.0
IL_0022: ldarg.2
IL_0023: ldloc.1
IL_0024: ldfld int32 OptimalTreeSearch.BranchNodeData::SplitInputIndex
IL_0029: ldelem.r4
IL_002a: ldloc.1
IL_002b: ldfld float32 OptimalTreeSearch.BranchNodeData::SplitValue
IL_0030: bgt.un.s IL_0039
IL_0032: ldloc.1
IL_0033: ldfld class OptimalTreeSearch.ScTreeNode OptimalTreeSearch.BranchNodeData::Child1
IL_0038: stloc.0
IL_0039: ldloc.0
IL_003a: ldfld class OptimalTreeSearch.BranchNodeData OptimalTreeSearch.ScTreeNode::BranchData
IL_003f: brtrue.s IL_0014
// end loop
IL_0041: ldloc.0
IL_0042: ret
} // end of method ScSearchTree::GetNodeForState
編集：分岐予測テストを行うことにしました。その間に同一のifを追加したので、
while (node.BranchData != null)
と
if (node.BranchData != null)
その中に。次に、それに対してパフォーマンス分析を実行したところ、最初の比較を実行するのに、常に true を返す 2 番目の比較を実行するのに比べて 6 倍の時間がかかりました。それは確かに分岐予測の問題であるように見えます-そして、私はそれについて私ができることは何もないと思います?!
別の編集
上記の結果は、node.BranchData を while チェックのために RAM からロードする必要がある場合にも発生します。その後、if ステートメントのためにキャッシュされます。
これは、同様のトピックに関する 3 番目の質問です。今回は、1 行のコードに焦点を当てています。この件に関する私の他の質問は次のとおりです。