只为几个可用内核创建大量任务是不是一个坏主意？

Question

我是使用 TPL 进行并行编程的新手，刚刚听完 TPL 课程。我刚刚写了一小段演示软件来测试我对它的理解。

在问我的一般问题之前，让我解释一下我的并行代码的上下文：（如果无聊，直接跳到问题;-)

上下文：

我首先编写了一个遍历递归代码的顺序递归树（适用于任何已知的两人游戏），然后尝试通过在每个遍历（和评估）节点上创建并发子任务来将其并行化，从而尽可能多地展示并行性. （为每个子节点启动一个子任务）。从当前评估的头节点的每个子节点发出的子树通过启动的并发子任务之一调用的相同递归方法自行评估。

在游戏树中，节点代表游戏位置。当前游戏位置的根节点及其 n 个子节点（在第 2 层树上）通过在根位置为玩家 A 应用 n 次合法移动可以到达的游戏位置。第 3 级节点通过在每个第 2 级位置/节点上应用玩家 B 下的合法移动来表示可到达的位置，依此类推，直到达到给定的最大搜索深度。..

树以深度优先遍历顺序遍历，直到给定的最大搜索深度，其中“叶子”位置将由启发式评估函数评估，该函数返回一个整数值，表示玩家 A 与玩家 B 在此方面的优势游戏位置。这个值越大，玩家 A 的位置就应该越好。

将所有子节点的最佳值报告给它们共同的父节点，（当然如果父节点代表玩家A所打的位置，则最佳子节点是具有最高值的子节点，如果它由玩家 B 播放，最好的子节点是值最低的那个）。

最好的子值最终以向根节点报告其最佳值的第 2 级子节点的索引报告给根节点。当然，这个指数代表玩家 A 的“最佳”移动。这意味着向玩家 A 保证报告值（或更好的值）可以在探索深度（“叶子”位置）达到，无论玩家 B 的走法。

好的，这是众所周知的两人状态博弈的极小极大算法。

您可能还知道这种顺序算法的经典优化，称为 alpha-beta，当我们知道博弈树的一些分支/子分支不会导致有趣的叶子位置时，它们允许修剪它们。

所以我尝试并行化这种递归树遍历，将叶子值报告给根节点，并允许完全取消树遍历（如果用户取消搜索），但也允许取消部分子树任务以实现 alpha-beta修剪必须中止执行某些子节点子树评估的任务，而不会中断在其他子树上工作的任务。

工作成功完成，并行搜索比顺序搜索更快，并且几乎总是以 100% 的速度在所有可用内核上分派工作（根据任务管理器）。我不想用我的源代码让你厌烦。我只想准确地说，我还将 .Net 4.5 异步等待模式应用于我的递归并行化方法，并实现了“一个接一个地等待”模式（实际上是等待 Task.WhenAll()）来创建探索子任务从每个子节点发出的子树。 （注意：为了允许子树遍历取消，我必须将取消令牌列表传递给递归异步子树探索方法，每个递归探索级别都会向列表中添加一个新的 CancellationToken）。

现在您已经了解了上下文，下面是我的问题：

1. 启动搜索将快速创建数百万个任务，评估从每个树节点发出的数百万个子树，但实际上只有几个处理器内核可用于使用几个线程（每个内核一个？）执行这些任务。那么不考虑这一点并为每个必须评估/遍历的子节点/子树创建任务是一个好主意吗？创建比暴露最大并行度所需的任务更多的任务是否不会引起开销？限制启动任务的数量不是更好吗（例如，只为最高级别的节点启动任务，而对最低级别的节点使用纯顺序遍历方法？）或者我们可以通过创建数百万个任务，即使我们知道其中一些（在最深的树节点上启动）执行的工作非常小？

2. 我没有阻止“通过闭包将循环索引变量传递给启动的任务”问题使用 lambda 表达式参数（如课程中建议的那样），而是通过复制循环索引在启动任务并通过闭包引用此副本之前，本地副本变量中的变量，而不是 lambda 表达式中的索引循环变量。您如何看待这种解决方法？这和传递 lambda 表达式参数一样安全吗？

3. minimax 算法的 alpha-beta 剪枝优化基于每个子树的顺序遍历。并行遍历使 alpha-beta 修剪效率降低，因为如果子节点的所有并行子树遍历花费大致相同的时间返回，则不会中止任何子树遍历任务，如果它们将被中止，它们将被中止，因为它们都是已经快完成了……这将极大地限制 alpha-beta 优化所带来的收益。在将博弈树遍历与 alpha-beta 优化并行化时，您知道解决此问题的明智策略吗？

Answer 1

关于“多少任务”的问题实际上是由两件事驱动的：

• 概念性程序组织
• 任务开销

从概念上讲，为树中的每个节点分配一项任务很简单。这就是好处。

缺点是使用任务的原因是有效地利用并行性，而不是程序组织。当你的处理器有很多工作要做时，你最终会得到最好的并行化， 与工作相比，管理该工作的开销很小。

您在节点级别选择任务的原因是很容易看到（可以说）有很多节点。 [在您的评论中，您提到深度搜索树的工作单元比您预期的要少！]。另一个原因是你不知道一个节点到底需要多少工作，所以有很多任务意味着处理器可以处理一个，一直工作到完成，然后去获取另一个。如果它们都有一些平均时间，处理器将执行并找到其他工作，而不会浪费大量时间等待其他工作出现。

关键问题是开销。要“拥有”一项任务，有很多开销：必须创建它，用工作填充它，将它放入其他处理器可以获取的工作队列中；其他处理器必须将其从队列中拉出，获取其内容，[不是开销：执行它]，最后取消创建它。这些开销中的每一个都需要一些计算机指令，一些内存访问（如果幸运的话，它们是缓存命中）以及通常在处理器之间进行一些昂贵的同步（你不能让所有 CPU 将新任务放入可用的工作队列中）同一时刻）。

我不知道 C# TPL 的工作开销是多少。您可以通过编写模拟任务主体的简单循环并对其进行测量来测量它；然后测量转储到任务中时该循环需要多长时间。我知道您希望最小化开销（我围绕这个想法设计了一种并行编程语言PARLANSE）并最大化您投入任务的工作量。

在你的情况下，我担心节点中的工作（“生成下一步动作并简单地评估它”）并不是真的很多，而且你实际上会失去性能并行。如果您退出并行性，您是否测量过相同程序的运行速度？ （PARLANSE 足够快，以至于 one can code a parallel 8 puzzle solver，但生成-移动-评估仍然比开销要多得多）。

当您在任务中没有足够的工作来压倒开销时，标准技巧是在任务中投入更多的工作。

在您的情况下，您可能决定让任务代表 2 层或 3 层搜索；这应该为每个任务创造大量的工作。对于 8 层游戏搜索，您仍然会生成大量任务来保持处理器忙碌。我展示了一个类似的技巧 (coarse-grain-threshold) 来使 parallel Fibonacci 工作，这与人们可以发明的工作/开销比率方案一样糟糕。

在国际象棋世界中众所周知，复杂的棋盘评估就像一个人在棋盘位置进行了 2 层或 3 层搜索一样。因此，您的另一个选择是实施昂贵的电路板评估程序；这将使叶子中的开销变小。

Alpha-beta 版可能会从running out of VM due to "big stacks" and many tasks 中节省您（“仅 1000 个任务”）。产生大量工作的好消息是您有很多可以提供给 CPU。坏消息是，它们可能会在虚拟机中占据 很多 空间，而它们却坐在那里不被执行； MS 的大筹码模型加剧了这一点。即使它不会使您耗尽 VM，它也可能导致您的程序接触大量内存，从而否定处理器缓存的价值。我会担心这个，但对 C# 没有好的建议；我构建了 PARLANSE 来避免这些问题；当它有“足够”的工作时，它会自动限制任务生成。不过，MS 有一些智能 cookie。