.net - 多线程->多处理趋势

Question

今天，可用内存比以前大得多，我发现开发人员倾向于从多线程转向多处理。

这里好Multi-process Architecture argumentation from Chrome devs:

In this world, browsers that put everything in one process face real challenges for robustness, responsiveness, and security. If one web app causes a crash in the rendering engine, it will take the rest of the browser with it, including any other web apps that are open. Web apps often have to compete with each other for CPU time on a single thread, sometimes causing the entire browser to become unresponsive.
Security is also a concern, because a web page that exploits a vulnerability in the rendering engine can often take over your entire computer.

所以
多处理优点:

隔离将意味着健壮性和安全性。 (我认为我们可以就响应能力争论不休，因为做出良好的响应并不难
正确的多线程和线程池管理)

缺点:

内存开销

更大的开始时间

如果我们不会在浏览器环境中说话，我们将倾向于将任何3d party库放在单独的过程中。因为我们不能确定此lib是否会导致崩溃，会导致崩溃，也不会不安全的数据。
.NET中有一些替代多进程方法的方法，例如AppDomains概念。但是他们无法提供所需的鲁棒性和灵活性，因为它仅适用于托管代码，不适用于 native 。
我认为对于任何其他软件框架都是如此。

那么，您如何看待，至少对于3d-party库而言，多进程体系结构是合理的选择还是它是邪恶的，而程序员懒惰，渴望简化自己的生活的结果呢？

Answer 1

这完全取决于您编写的应用程序。
考虑一些计算引擎。在HPC范围内拥有多个流程通常非常昂贵，并且需要认真的论据。

许多应用程序正在转向Multicore体系结构，因为我们的程序假设要在其上运行的硬件在时钟速度方面达到了极限，因此编程语言提供了越来越复杂的语言构件来应对这一 future 。 (Microsoft TPL，Intel TBB，GCC, Matlab and many others支持卸载到Xeon Phi多核协处理器)。

当您处理许多/多核核心体系结构时，关键是数据结构和内存访问模式。如果至少根据他的程序正确地调整了这两个参数，您会惊奇地发现一个人可以获得多少性能。

进行多进程(如果不是完全禁止的话)至少会使处理RAM fragmentation，CPU Cache之类的工作变得非常具有挑战性。
在编写计算引擎时(同样，仅举一个例子)，您不必担心chrome团队必须担心的安全性，您担心的故障点，而这又会更易于处理和将来管理多年，而所有流程都集中在一个流程中。

现在:

So how do you think, is the multi-process architecture at least for 3d-party libs is reasonable choice or it is evil and the result of programmers laziness, their desires to simplify to itself life?

这是断线。在您提出的问题中，一个人应该问的问题是:如果第3方lib失败，我的应用程序应该怎么做？我要如何处理？回答这些问题将使您为您的项目做出正确的选择。

我个人而言，将不是为了失败管理而是为了平台/语言集成挑战而在另一个过程中前进。假设这是一个Python/C++项目，而我的宿主应用程序是C#，我希望避免所有的互操作/编码，而仅从命令行调用流程。再说一次，如果可能的话，还是可持续的。

所有这些都是为了，对于您的下一个项目来说，Chrome团队绝对没有必要的事情是完全可以的。实际上，很可能很多都不会。
因此，了解原因，学习概念并选择更适合您的情况。