几年前，在Windows环境下，我做了一些测试，让CPU计算密集型+内存访问密集型+I/O访问密集型的应用程序运行多个实例。我开发了两个版本：一个在多处理下运行，另一个在多线程下运行。
我发现多处理的性能要好得多。我在其他地方读过（但我不记得那个网站了）。
其中说明原因是在多线程下，它们在为单个内存管道和 I/O 管道“战斗”，这使得与多处理相比性能更差
但是，我再也找不到那篇文章了。我想知道，直到今天，以下是否仍然成立？
在 Windows 中，让算法代码在多处理下运行，性能很有可能优于多线程。
这取决于各种线程或进程（我将使用统称“任务”来表示它们）需要多少通信，尤其是通过共享内存：这对于线程来说很容易、便宜且快速，但对于线程来说根本不是进程，因此，如果其中有很多，我敢打赌进程的性能不会超过线程。
此外，进程（尤其是在 Windows 上）启动起来“更重”，因此如果发生大量“任务启动”，线程在性能方面也很容易击败进程。
接下来，您可以拥有具有“超线程”的 CPU，它可以非常快速地在一个内核上运行（至少）两个线程——但不能运行进程（因为“超线程”线程不能使用不同的地址空间）——还有另一种情况其中线程可以在性能方面获胜。
如果这些考虑都不适用，那么无论如何，比赛应该不会比平局更好。
我不确定这句话是什么意思。这非常接近于胡说八道。
进程内线程共享的主要内容是虚拟内存地址空间。
我发现这也是真的。但我认为这与日程安排有关。因为如果你运行它足够长的时间，多进程和多线程一样快。这个数字大约是 10 秒。如果算法需要运行 10 秒。多进程与多线程一样快。但如果它只需要运行不到 1 秒。多进程比多线程快得多。