82

在我的一个有点像聚合器的项目中，我从网络上解析提要、播客等。

如果我使用顺序方法，考虑到大量资源，处理所有资源需要相当长的时间（因为网络问题和类似的东西）；

foreach(feed in feeds)
{
   read_from_web(feed)
   parse(feed)
}

所以我想实现并发，但无法决定我应该基本上使用 ThreadPools 来处理工作线程还是仅仅依靠 TPL 来对其进行排序。

ThreadPools 肯定会用工作线程为我处理这项工作，我会得到我所期望的（在多核 CPU 环境中，也将使用其他内核）。

并发

但我仍然想考虑 TPL 作为推荐方法，但我有点担心。首先，我知道 TPL 使用 ThreadPools 但增加了额外的决策层。我最关心的是存在单核环境的情况。如果我没记错的话，TPL 从一开始的工作线程数等于可用 CPU 核心数开始。我确实担心 TPL 会为我的 IO 绑定案例产生与顺序方法相似的结果。

所以对于 IO-bound 操作（在我的情况下从 web 读取资源），最好使用 ThreadPools 并控制事物，还是更好地依赖 TPL？TPL 也可以用在 IO-bound 场景中吗？

更新：我主要担心的是——在单核 CPU环境中，TPL 的行为会像顺序方法一样，还是仍会提供并发性？我已经在阅读Parallel Programming with Microsoft .NET等书，但找不到确切的答案。

注意：这是对我之前的问题 [ Is it possible to use thread-concurrency and parallelism together? ] 措辞非常错误。

4

6 回答 6

108

所以我决定为此编写测试并在实际数据上查看它。

测试图例

  • Itr：迭代
  • Seq：顺序方法。
  • PrlEx：并行扩展 - Parallel.ForEach
  • TPL：任务并行库
  • TPool：线程池

测试结果

单核 CPU [Win7-32​​] -- 在 VMWare 下运行 --

Test Environment: 1 physical cpus, 1 cores, 1 logical cpus.
Will be parsing a total of 10 feeds.
________________________________________________________________________________

Itr.    Seq.    PrlEx   TPL     TPool
________________________________________________________________________________

#1      10.82s  04.05s  02.69s  02.60s
#2      07.48s  03.18s  03.17s  02.91s
#3      07.66s  03.21s  01.90s  01.68s
#4      07.43s  01.65s  01.70s  01.76s
#5      07.81s  02.20s  01.75s  01.71s
#6      07.67s  03.25s  01.97s  01.63s
#7      08.14s  01.77s  01.72s  02.66s
#8      08.04s  03.01s  02.03s  01.75s
#9      08.80s  01.71s  01.67s  01.75s
#10     10.19s  02.23s  01.62s  01.74s
________________________________________________________________________________

Avg.    08.40s  02.63s  02.02s  02.02s
________________________________________________________________________________

单核 CPU [WinXP] -- 在 VMWare 下运行 --

Test Environment: 1 physical cpus, NotSupported cores, NotSupported logical cpus.
Will be parsing a total of 10 feeds.
________________________________________________________________________________

Itr.    Seq.    PrlEx   TPL     TPool
________________________________________________________________________________

#1      10.79s  04.05s  02.75s  02.13s
#2      07.53s  02.84s  02.08s  02.07s
#3      07.79s  03.74s  02.04s  02.07s
#4      08.28s  02.88s  02.73s  03.43s
#5      07.55s  02.59s  03.99s  03.19s
#6      07.50s  02.90s  02.83s  02.29s
#7      07.80s  04.32s  02.78s  02.67s
#8      07.65s  03.10s  02.07s  02.53s
#9      10.70s  02.61s  02.04s  02.10s
#10     08.98s  02.88s  02.09s  02.16s
________________________________________________________________________________

Avg.    08.46s  03.19s  02.54s  02.46s
________________________________________________________________________________

双核 CPU [Win7-64]

Test Environment: 1 physical cpus, 2 cores, 2 logical cpus.
Will be parsing a total of 10 feeds.
________________________________________________________________________________

Itr.    Seq.    PrlEx   TPL     TPool
________________________________________________________________________________

#1      07.09s  02.28s  02.64s  01.79s
#2      06.04s  02.53s  01.96s  01.94s
#3      05.84s  02.18s  02.08s  02.34s
#4      06.00s  01.43s  01.69s  01.43s
#5      05.74s  01.61s  01.36s  01.49s
#6      05.92s  01.59s  01.73s  01.50s
#7      06.09s  01.44s  02.14s  02.37s
#8      06.37s  01.34s  01.46s  01.36s
#9      06.57s  01.30s  01.58s  01.67s
#10     06.06s  01.95s  02.88s  01.62s
________________________________________________________________________________

Avg.    06.17s  01.76s  01.95s  01.75s
________________________________________________________________________________

四核 CPU [Win7-64] -- 支持超线程 --

Test Environment: 1 physical cpus, 4 cores, 8 logical cpus.
Will be parsing a total of 10 feeds.
________________________________________________________________________________

Itr.    Seq.    PrlEx   TPL     TPool
________________________________________________________________________________

#1      10.56s  02.03s  01.71s  01.69s
#2      07.42s  01.63s  01.71s  01.69s
#3      11.66s  01.69s  01.73s  01.61s
#4      07.52s  01.77s  01.63s  01.65s
#5      07.69s  02.32s  01.67s  01.62s
#6      07.31s  01.64s  01.53s  02.17s
#7      07.44s  02.56s  02.35s  02.31s
#8      08.36s  01.93s  01.73s  01.66s
#9      07.92s  02.15s  01.72s  01.65s
#10     07.60s  02.14s  01.68s  01.68s
________________________________________________________________________________

Avg.    08.35s  01.99s  01.75s  01.77s
________________________________________________________________________________

总结

  • 无论您是在单核环境还是多核环境中运行，Parallel Extensions、TPL 和 ThreadPool的行为都是相同的，并给出了近似的结果。
  • 尽管如此， TPL仍然具有易于异常处理、取消支持和轻松返回任务结果的能力等优点。尽管并行扩展也是另一种可行的选择。

自己运行测试

您可以在此处下载源代码并自行运行。如果您可以发布结果，我也会添加它们。

更新：修复了源链接。

于 2011-03-07T11:47:25.370 回答
15

如果您尝试最大化 IO 绑定任务的吞吐量，则绝对必须将传统的异步处理模型 (APM) API 与基于 TPL 的工作结合起来。APM API 是在异步 IO 回调挂起时解除阻塞 CPU 线程的唯一方法。TPL 提供了TaskFactory::FromAsync辅助方法来帮助组合 APM 和 TPL 代码。

查看 MSDN 上名为TPL 和传统 .NET 异步编程的 .NET SDK 部分，了解有关如何结合这两种编程模型以实现异步必杀技的更多信息。

于 2011-03-08T01:28:41.817 回答
2

您是对的，当您创建自己的线程池时，TPL 确实删除了您拥有的一些控制权。但这仅在您不想深入挖掘时才正确。TPL 确实允许您创建不属于 TPL 线程池的长时间运行的任务，并且可以很好地满足您的目的。这本已出版的书是免费阅读的Parallel Programming with Microsoft .NET，它将让您更深入地了解 TPL 的使用方式。您始终可以选择为 Paralle.For、Tasks显式 参数分配多少线程。除此之外，如果您想要完全控制，您可以用您自己的替换 TPL 调度程序。

于 2011-03-06T22:30:35.457 回答
1

您可以将自己的任务调度程序分配给 TPL 任务。不过，默认工作窃取一个非常聪明。

于 2011-03-06T22:26:34.213 回答
0

我确实担心 TPL 会为我的 IO 绑定案例产生与顺序方法相似的结果。

我认为会的。瓶颈是什么？是解析还是下载？多线程对从 Web 下载没有多大帮助。

我会使用任务并行库进行裁剪，为下载的图像应用蒙版或效果，从播客中剪切一些样本等。它更具可扩展性。

但这不会是数量级的加速。花你的资源来实现一些功能，测试。

PS。“哇，我的函数在 0.7 秒内而不是 0.9 秒内执行”；）

于 2011-03-06T22:15:24.243 回答
0

如果您并行化对 url 的调用，我认为它会改进您的应用程序，即使只有一个内核。看看这段代码：

var client = new HttpClient();
var urls = new[]{"a", "url", "to", "find"};

// due to the EAP pattern, this will run in parallel.
var tasks = urls.Select(c=> client.GetAsync(c));

var result = Tasks.WhenAll(task).ContinueWith(a=> AnalyzeThisWords(a.Result));
result.Wait(); // don't know if this is needed or it's correct to call wait

在这种情况下，多线程和异步之间的区别在于如何完成回调/完成。

使用 EAP 时，任务数与线程数无关。

当您依赖 GetAsync 任务时，http 客户端使用网络流（套接字、tcp 客户端或其他）并在 BeginRead/EndRead 完成时发出信号以引发事件。因此，此时不涉及任何线程。

调用完成后，可能会创建一个新线程，但由 TaskScheduler（在调用 GetAsync/ContinueWith 调用中使用）来创建新线程、使用现有线程或内联任务以使用调用线程。

如果AnalyzeThisWords阻塞时间过长，那么您开始遇到瓶颈，因为 ContinueWith 上的“回调”是从线程池工作程序完成的。

于 2016-12-06T01:31:00.697 回答