什么时候会并行提高性能

Question

我试图了解parallel的使用何时会提高效果 我使用一个简单的代码对其进行了测试，该代码在List<Person>中运行了超过100,000个项目，并将每个项目的名称更改为string.Empty。

并行版本比普通版本花费了两倍的时间。 （是的，我用更多的核心测试了......）

我看到this回答说一段并不总是并行的数据对性能有好处 此问题也在MSDN教程的并行示例的每一页中重复出现：

  

这些示例主要用于演示用法，可能或   可能不会比等效的LINQ to Objects运行得更快   查询

我需要一些规则和提示，当并行将提高我的代码的性能，什么时候不会 显而易见的答案是“测试你的代码，如果并行循环更快地使用它”，这是绝对正确的，但我想没有人在他写的每个循环上运行性能分析。

Answer 1

考虑什么时候在现实生活中并行化某些东西是值得的。什么时候坐下来自己从头到尾做自己的工作更好，什么时候雇用二十个人更好？

• 工作本质上是可并行化的还是本质上是串行的？有些工作根本无法并行化：九个女人在一个月内无法共同生育一个孩子。有些工作是可以并行化的，但却会产生糟糕的结果：你可以聘请20个人，并为他们分配50页战争与和平，然后让每个人写一篇文章的二十分之一，将所有的文章片段粘在一起，提交论文;这不太可能导致良好的成绩。有些工作非常可并行化：20个带铲子的人可以比一个人更快地挖洞。

• 如果工作本质上是可并行化的，并行化实际上是否可以节省时间？你可以煮一锅意大利面条，里面有一百个面条，或者你可以煮20个意大利面条，每个面条有五个面条，最后将结果倒在一起。我向你保证，平行烹饪意大利面条的任务不会让你的晚餐变得更快。

• 如果这项工作具有固有的可并行性，并且可以节省时间，那么雇用这些人的成本是否会为节省的时间付出代价？如果你自己完成这项工作比雇用这些人更快，那么并行化就不是一场胜利。雇用二十个人做一份工作，花了你五秒钟，并希望他们能在四分之一秒内完成工作，如果你需要一天的时间来找到这些人，这不是一种节省。

当工作巨大和可并行化时，并行化往往是一种胜利。将十万个指针设置为null是计算机可以在很短的时间内完成的事情。没有巨大的成本，所以没有节省。尝试做一些非平凡的事情;比如说，编写一个编译器，并行地对方法体进行语义分析。你将更有可能在那里获胜。

Answer 2

如果你正在迭代一个集合并对每个元素做一些计算密集的事情（特别是如果＆＃34;某些东西＆＃34;也不是I / O密集型的话），那么你可能会看到一些好处并行化循环。将属性设置为string.Empty的计算成本并不高，这可能是您未获得改进的原因。

Answer 3

当并行执行的计算大于使用并行性（线程启动，线程切换，通信，线程争用等）的开销时，循环将受益于并行性。你的测试似乎意味着平行主义应该有利于琐碎的计算，但事实并非如此。它向你展示的是，对于并列主义来说，存在开销。工作量必须大于（通常明显更大）工作量，而不是看到任何好处的开销。

你似乎也放弃了测试。如果平行主义为你买东西，测试是唯一的方法。您不需要对每个循环进行性能测试，只需要性能测试。如果循环不是性能关键，为什么甚至打扰它并行？如果花时间让它并行是至关重要的，那么你最好做一个测试，以确保你从劳动和回归测试中获益，以确保一些聪明的程序员以后不会破坏你的工作。

Answer 4

对我而言，当您考虑并行化代码时，有一些规则（即便如此，您仍应测试它是否更快）：

1. 要并行化的代码是计算密集型的。只是等待IO通常不会给你带来很多好处。它必须是你肯定会利用一堆CPU时间（比如渲染图像）的东西。
2. 要并行化的代码非常复杂，以至于进行并行化的开销小于分配代码所节省的成本（即，将字符串设置为string.Empty非常简单快速;您需要一些东西每件物品要复杂得多，值得拥有它。）
3. 要并行化的代码是独立的，并且不依赖于其他项目。

Answer 5

并行性有助于提高 的性能，使其能够让您的所有硬件都朝着有用的方向发展。

如果必须共享单个核心，则两个CPU绑定线程的速度不会快于1。 事实上，它们会变慢。

使用多个线程还有其他原因而不是性能。 例如，必须与许多同时用户交互的Web应用程序可以编写为仅响应中断的单个线程。 但是，如果可以使用线程编写代码，它会极大地简化代码。

这不会使代码更快。 它使编写更容易。