多进程是否性能可靠?

闲聊灌水
1

以前(用Windows的时候)都说考虑到性能, 复杂一些的后台程序都会用多线程(线程池)(7年前接触node.js 是时接触到 单线程思路)
近期看了2003年的老书《UNIX编程艺术》

image
image1272×1386 146 KB

里面又强调在 UNIX/Linux 系统多进程性能高成本低, 提倡优先考虑多进程而不是多线程
如果真是这样(多进程性能无劣势)那确实是方便很多啊?
多线程大多只是能调用自己的程序或调用第三方代码库(麻烦)的线程对吧?
而多进程就是别人的经历了考验(经久不衰)的程序/工具都拿来就用, 感觉视野都宽广了很多一样…(曾经后台只会node的时候就都是通过npm安装必要的库, 其实有些库也是要你安装某些程序/lib, 内部也是调用了其它进程对吧? )
我想如果要频繁借助其它程序工作, 那就要用 socket 来"搭桥", 看来不一定是必须吗?

2

不懂这个，我的 把org-mode当一个应用前端用 也要频繁的在emacs内调用其它程序请求数据，开始时纠结了半天，我是用 (async-shell-command "")呢还是用(url-insert-file-contents "")，因为不明白那个的开销大，或者那个更可靠，最后用了(url-insert-file-contents "")

3

多线程在图形库用的很多，因为要在多个线程共享大量数据。

多进程主要用于多个不相关程序做IPC通讯。

不是超高要求的应用，数据传输量小，这两个方案性能差别很少，大部分情况只要遵循下面规则：

  1. 自己用，简单的进程内协作用线程或者纤程
  2. 对外提供服务或者调用别的进程服务用IPC
3 个赞
4

计算机大三学生来说一下自己的观点。 对于进程调度器来说线程相比进程的开销要小很多，因为多个进程之间切换状态需要处理较多的资源，相比于线程来说（需要处理PCB），而同进程之间的多线程之间相互切换不需要多少时间就可以切换，因为其拥有的资源较少，资源主要都是在进程那边，线程主要被调度和分派。

操作系统课上讲的，可能和现代操作系统不太一样了。。

5

在rust里面用多线程和async同时用，很爽，消耗资源很少，也很稳定。

6

我的直觉印象也是这样啊(大学时学的), 但是我看 UNIX 的书又不是这样, 难道是因为 Windows 才差别大? 还是因为我看的那本书是 2003 年的?

自己的体验来看在 Common Lisp 调用其它进程确实速度也不差多少哦? 还有 shell/pipe 这些都是多进程合作

这个是关键

7

题外话， 在Windows下反复启动关闭进程是Emacs插件拖累总体性能的重要原因。几乎所有著名插件都有这个问题。如ivy，flyspell，flymake，magit 等等。

1 个赞
8

对于内核（linux）来说，多进程跟多线程都是一些job，不同的同一个进程的线程的操作的资源指向的是同一个。所以这个事在不同的角度来看有不同的有不同的结论。以下是个人理解：

  1. 两个不需要频繁协作的长期任务。 这种情况下来说多进程的好处是可以利用别人的二进制。扩展方便，性能跟线程可能差不多或者好一点点。
  2. 需要频繁交互的长期任务。多线程性能应该好点，毕竟两个进程的交互的成本再怎么也比两个线程之间的内存交互慢。
  3. 其中一个是短期的一次性任务。这种应该也是多线程好点，毕竟启动一个进程比启动一个线程费力多。而且线程可以弄线程池。并且进程还需要进程之间的交互。