3

我正在开发一个小型库，它使用任务并行库来运行并行搜索以寻找解决方案。当前的设计遵循以下原则：

  • ConcurrentQueue 接收 Searches 的结果，
  • 一个主任务作为一个循环工作，作为一个后台线程运行。当一个新的解决方案到达队列时，它会出列并处理它，然后在一个新任务上启动一个新的搜索，
  • 搜索在其自己的任务中启动，并在完成后将其结果返回到队列。

[根据 Eric J 的回答进行编辑：所涉及的活动完全受 CPU 限制，不涉及 IO]

该框架目前运行良好。但是，我可以完全控制将触发的搜索任务的数量，并且我的理解是，虽然 TPL 目前可以很好地处理这种情况，但将大量搜索推向系统不会导致并行度增加，因为它会受到系统上可用的核心数量的限制，并且在达到一定水平后会适得其反。

我的问题如下：我可以通过限制将运行的搜索任务的数量来“帮助”TPL，如果可以，我将如何确定上限应该是多少？例如基于 System.Environment.ProcessorCount 限制它是否合适？

4

1 回答 1

4

首先，除非这里有真正的性能问题，否则我会让 TPL 做这件事。它非常擅长这一点。

如果您确实需要控制任务数量来解决实际性能问题，您需要了解限制性能的因素。您的任务受 CPU 限制吗？IO绑定？您是否用完了物理内存，导致交换？

一旦您知道限制因素是什么，您当然可以监控该因素并根据该（运行时）测量值调整运行任务的数量。例如，如果您的任务受 CPU 限制但有一些 IO 时间，则基于内核数的硬限制很接近但不是最佳的。而是根据整体 CPU 利用率进行限制。 这假设机器主要用于处理此任务。如果不是这样，手动调整会更加复杂且容易出错。

于 2012-06-08T02:49:03.060 回答