多线程和多进程的性能差异
几年前，在Windows环境下，我做了一些测试，让CPU计算密集型+内存访问密集型+I/O访问密集型应用程序的多个实例运行。我开发了2个版本：一个是在多处理下运行，另一个是在多线程下运行。
我发现多处理的性能要好得多。我在其他地方读过（但我不记得那个网站了）。
其中指出原因是在多线程下，它们正在“争夺”单个内存管道和 I/O 管道，这使得性能比多处理更差
但是，我可以'再也找不到那篇文章了。我想知道，直到今天，以下内容是否仍然成立？
在Windows中，有算法 代码在多处理下运行，有很高的 表演的机会 比多线程更好。
A few years ago, in the Windows environment, I did some testing, by letting multiple instances of CPU computation intensive + memory access intensive + I/O access intensive application run. I developed 2 versions: One is running under multi-processing, another is running under multi-threading.
I found that the performance is much better for multi-processing. I read somewhere else (but I can't remember the site).
Which states that the reason is that under multi-threading, they are "fighting" for a single memory pipeline and I/O pipeline, which makes the performance worse compared to multi-processing
However, I can't find that article anymore. I was wondering, till today, whether the below still hold true?
In Windows, having the algorithm
code run under multi-processing, there is a high
chance that the performance will be
better than multi-threading.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这取决于不同线程或进程（我将使用统称“任务”来表示它们）需要进行多少通信，尤其是通过共享内存：这对于线程来说很简单、便宜且快速，但对于进程，因此，如果发生大量进程，我敢打赌进程的性能不会会击败线程。
此外，进程（尤其是 Windows 上的进程）启动起来“较重”，因此，如果发生大量“任务启动”，线程在性能方面可以轻松击败进程。
接下来，您可以拥有具有“超线程”功能的 CPU，它可以非常快速地在一个核心上运行（至少）两个线程——但是，不能运行进程（因为“超线程”线程不能使用不同的地址空间）——还有另一种情况其中线程可以在性能方面获胜。
如果这些考虑因素都不适用，那么无论如何，这场比赛应该不会比平局更好。
It depends on how much the various threads or processes (I'll be using the collective term "tasks" for both of them) need to communicate, especially by sharing memory: that's easy, cheap and fast for threads, but not at all for processes, so, if a lot of it is going on, I bet processes' performance is not going to beat threads'.
Also, processes (esp. on Windows) are "heavier" to get started, so if a lot of "task starts" occur, again threads can easily beat processes in terms of performance.
Next, you can have CPUs with "hyperthreading", which can run (at least) two threads on a core very rapidly -- but, not processes (since the "hyperthreaded" threads cannot be using distinct address spaces) -- yet another case in which threads can win performance-wise.
If none of these considerations apply, then the race should be no better than a tie, anyway.
我什至不确定这句话的意思。这非常接近废话。
进程内线程共享的主要内容是虚拟内存地址空间。
I'm not sure what the quote even means. It's very close to nonsense.
The primary thing that in-proc threads share is virtual memory address space.
我发现这也是事实。但我认为这与日程安排有关。因为如果你运行它足够长的时间，多进程和多线程一样快。这个数字大约是 10 秒。如果算法需要运行 10 秒。多进程与多线程一样快。但如果它只需要运行少于1秒。多进程比多线程快得多。
I found this is true as well. but I think it has something to do with the scheduling. because if you run it long enough, the multi-processes is just as fast as multi-threads. that number is about 10 seconds. if the algorithm needs to be run for 10 seconds. the multi-processes is as fast as multi-thread. but if it only needs to be run for less than 1 second. multi-processes is much,much faster than multi-thread.