现在开始设计任务并行库还为时过早吗？

Question

自微软首次宣布以来,我就一直关注着.NET任务并行库(TPL)的开发.

毫无疑问,我们最终会利用TPL.我在质疑的是,在发布Visual Studio 2010和.NET 4.0时是否有必要开始利用TPL,或者等待一段时间是否有意义.

为什么现在开始？

• .NET 4.0任务并行库看起来设计得很好,一些相对简单的测试表明它在当今的多核CPU上运行良好.
• 自从七年前购买我的第一台四核处理器Dell Poweredge 6400以来,我一直非常感兴趣使用多个轻量级线程来加速我们的软件.当时的实验表明它不值得付出努力,这主要归功于在每个CPU的缓存(当时没有共享缓存)和RAM之间移动数据的开销.
• 竞争优势 - 我们的一些客户永远无法获得足够的性能,毫无疑问,我们现在可以使用TPL构建更快的产品.
• 听起来很有趣.是的,我意识到一些开发人员宁愿用尖锐的棍子捅自己的眼睛,但我们真的很喜欢最大化性能.

干嘛要等？

• 今天的英特尔Nehalem CPU代表了我们的目标,因为多核支持成熟了吗？您可以购买具有4个内核的Nehalem CPU,它们共享单个3级缓存,并且在Visual Studio 2010/.NET 4.0发布时,很可能是6核CPU共享单个3级缓存.显然,核心数量会随着时间的推移而增加,但架构呢？随着核心数量的增加,它们是否仍会共享缓存？Nehalem的一个问题是,即使内核之间存在非常快速的互连,它们也具有非均匀内存访问(NUMA),这会导致性能降低和结果可预测性降低.未来的多核架构是否能够取消NUMA？
• 同样,.NET任务并行库是否会随着成熟而发生变化,需要修改代码才能充分利用它？

限制

• 我们的核心引擎是100%C#,并且必须在没有完全信任的情况下运行,因此我们仅限于使用.NET API.

Answer 1

我现在就开始吧.我强烈怀疑我们已经看到了大部分的变化 - 即使候选版本中有一些调整,我相信它们将在PFX团队博客中得到很好的记录,并且易于更改.即使芯片发生变化,我也希望TPL能够在未来的版本中进行适当的调整 - 我个人认为目前的TPL仍然可以比处理任何手工制作的线程代码更好地处理这些新芯片.我们可以写.

我现在看到的一个真正的缺点是,学习资源还没有真正存在.有一些文档,一些博客文章(其中一些将在现在过时)和一些示例代码 - 但没有专门用于PFX的书籍.我相信这些会及时到来 - 如果你在游戏的早期,你甚至可以写一个:)

根据您的应用程序,您可能还需要查看Reactive Extensions,它与PFX一起使用.