gdo*_*ica 4 .net c# parallel-processing performance
我试图了解何时使用parallel会增加性能.
我用一个运行超过100,000个项目的简单代码对其进行了测试,List<Person>并将每个项目的名称更改为string.Empty.
并行版本比普通版本花费了两倍的时间.(是的,我用更多的核心进行了测试...)
我看到这个答案说一段并不总是并行的数据对性能有好处.
此外,在MSDN教程的并行示例的每一页中都会重复此注意事项:
这些示例主要用于演示用法,可能会或可能不会比等效的LINQ to Objects查询运行得更快
我需要一些规则和提示,当并行将提高我的代码的性能,什么时候不会.
显而易见的答案是"测试你的代码,如果并行循环更快地使用它",这是绝对正确的,但我想没有人在他写的每个循环上运行性能分析.
Eri*_*ert 21
想想何时值得在现实生活中并行化某些东西.什么时候坐下来自己从头到尾做自己的工作更好,什么时候雇用二十个人更好？
工作本质上是可并行化的还是固有的串行？有些工作根本无法并行化:九个女人在一个月内无法共同生育一个孩子.有些工作是可以并行化的,但却会产生糟糕的结果:你可以聘请20个人,并为他们分配50页战争与和平,然后让每个人写一篇文章的二十分之一,将所有的文章片段粘在一起,提交论文; 这不太可能导致良好的成绩.有些工作非常可并行化:20个带铲子的人可以比一个人快得多.
如果工作本质上是可并行化的,并行化实际上是否可以节省时间？你可以煮一锅意大利面条,里面有一百个面条,或者你可以煮20个意大利面条,每个面条有五个面条,最后将结果倒在一起.我向你保证,平行烹饪意大利面条的任务不会导致你的晚餐更快.
如果工作本质上是并行的,并且有可能节省时间,并雇用那些家伙的成本及时为节约买单？如果你自己完成这项工作比雇用这些人更快,那么并行化就不是一场胜利.雇用二十个人做一份工作,花了你五秒钟,并希望他们能在四分之一秒内完成工作,如果需要一天的时间来找到这些人,这不是一笔积蓄.
当工作量巨大且可并行化时,并行化往往是一种胜利.将十万个指针设置为null是计算机可以在很短的时间内完成的事情.没有巨大的成本,所以没有节省.尝试做一些非平凡的事情; 比如说,编写一个编译器,并行地对方法体进行语义分析.你将更有可能在那里获胜.