多核编程:难点

Question

我正在写一本关于使用.NET 4的多核编程的书，我很想知道人们发现多核编程的哪些部分很难理解或预期很难理解？

Answer 1

要并行化的有用工作单元是什么，以及如何查找/组织一个工作单元？

如果您派生的工作比派生开销小，那么所有这些并行原语都没有帮助；事实上，这会为您带来良好的减速，而不是您所期望的。

因此，最大的问题之一是找到明显比并行原语更昂贵的工作单元。这里的一个关键问题是，没有人知道执行任何东西的成本，包括并行原语本身。清楚地校准这些成本将非常有帮助。(顺便说一句，我们设计、实现和日常使用了并行编程语言PARLANSE，它的目标是通过允许编译器生成和优化并行原语来最小化它们的成本，目标是使较小的工作“更可并行化”)。

人们也可以考虑讨论big-Oh符号及其应用。我们都希望并行原语的开销为O(1)。如果是这种情况，那么如果您发现工作的成本为O(x) > O(1)，那么该工作就是一个很好的并行化候选者。如果你提出的工作也是O(1)，那么它是否有效取决于常数因子，我们回到上面的校准。

如果没有一个块足够大，那么将工作收集到足够大的单元中就存在问题。代码移动，算法替换，...都是实现这一效果的有用的想法。

最后，还有同步的问题:我的并行单元什么时候必须交互，我应该使用什么原语，以及这些原语的成本是多少？(比您预期的要多！)

Answer 2

我想这在一定程度上取决于书/读者的基础或高级程度。当你第一次从单线程编程到多线程编程时，你通常会从一个巨大的悬崖上掉下来(许多人再也不会恢复了，参见所有关于Control.Invoke的糊涂问题)。

无论如何，为了添加一些关于编程本身的想法，而更多地关于软件过程中的其他相关任务：

• Measuring：决定你要改进的度量标准，正确地测量它(意外地测量错误的东西是很容易的)，使用正确的工具，区分信号和噪声，解释结果并理解它们为什么是are.
• Testing：如何编写容忍不重要的非确定性/交错的测试，但仍然约束正确的程序调试工具和策略，当“难以调试”意味着反馈来改进你的代码/设计和更好地划分可变状态时，etc.
• Physical与逻辑counter).
• Patterns线程亲和性：理解GUI线程，理解F# map处理器/代理如何封装可变状态并在多个线程上运行，但始终只使用单个逻辑线程(一个程序分支(当它们应用时)：fork-join，-reduce，producer-consumer，...

我预计将会有大量的受众，比如“帮助，我有一个CPU利用率为12%的单线程应用程序，我想学习足够的知识，让它在不做太多工作的情况下速度提高4倍”，而像“我的应用程序在我们添加内核时呈次线性扩展，因为这里似乎存在争用，有没有更好的使用方法？”的受众会很少。因此，可能会有一些挑战是服务于每一个受众。

Answer 3

因为您用.Net编写了一整本关于多核编程的书。

我认为你也可以在多核的基础上做一点。

例如，您可以在.Net中使用一章讨论分布式系统中的并行计算。不太可能，.Net中还没有成熟的框架。DryadLinq是最接近的。(另一方面，Hadoop和它在Java平台上的朋友们真的很棒。)

你也可以用一个章节来演示一些GPU计算的东西。