几年前，在Windows环境中，我做了一些testing，让CPU计算密集型+内存访问密集型+ I / O访问密集型应用程序的多个实例运行。 我开发了两个版本：一个在多处理下运行，另一个在multithreading下运行。
我发现多处理的性能要好得多。 我读了其他地方（但我不记得该网站）。
其中的原因是在multithreading的情况下，对于单个内存pipe道和I / Opipe道来说，它们是“战斗”的，这使得性能比多处理
但是，我再也找不到那篇文章了。 我想知道，直到今天，下面的情况是否仍然如此？
在Windows中，使algorithm代码在多处理下运行，性能会比multithreading更好。
这取决于多少线程或进程（我将使用两个集体名词“任务”）需要沟通，特别是通过共享内存：这对于线程来说简单，便宜和快速，但根本不进程，所以，如果有很多事情正在进行，我敢打赌，进程的性能不会超过线程。
而且，进程（特别是Windows）的开始“比较重”，所以如果出现大量的“任务开始”，线程可以轻松地在性能方面击败进程。
接下来，你可以让CPU具有“超线程”，它可以非常快速地在内核上运行（至少）两个线程，但不是进程（因为“超线程”线程不能使用不同的地址空间）在哪个线程可以赢得性能。
如果这些考虑都不适用的话，无论如何，比赛应该不会比平局更好。
我不确定这句话甚至意味着什么。 这是非常接近废话。
进程线程共享的主要内容是虚拟内存地址空间。
我不相信这是真的。 一般来说，多线程应用程序的运行速度要比Windows下多个进程设计的应用程序快。 有多种原因可以说明你的测试在多进程情况下可能表现更好。
首先想到的是虚假分享。 在你的多线程测试中，这些线程可能会不经意地共享缓存行。 当不同的线程访问物理接近的不同内存位置（在几个字节内）时会发生这种情况。 这导致两个CPU连续在相同的缓存行上竞争，并且这严重地降低了性能。 在多进程情况下不会发生这种情况，因为进程有完全独立的地址空间。
我发现这也是如此。 但我认为这与调度有关。 因为如果你运行的时间足够长，多进程就像多线程一样快。 这个数字大概是10秒。 如果算法需要运行10秒。 多进程与多线程一样快。 但如果只需要运行少于1秒。 多进程比多线程快得多。