几年前,在Windows环境中,我做了一些测试,让CPU计算密集型+内存访问密集型+ I/O访问密集型应用程序的多个实例运行。我开发了两个版本:一个在多处理下运行,另一个在多线程下运行.
我发现多处理的性能要好得多。我在别的地方读过书(但我不记得那个网站了)。
指出其原因是在多线程环境下,它们正在为单个内存管道和I/O管道“战斗”,这使得性能比多处理差。
但是,我再也找不到那篇文章了。我一直在想,直到今天,下面这些是否仍然是真的?
在Windows环境下,算法代码在多进程下运行,其性能很有可能优于多线程.。
发布于 2010-07-31 02:55:45
这取决于不同的线程或进程(我将对它们都使用“任务”这个统称)需要进行多少通信,特别是通过共享内存:这对于线程来说简单、廉价、快速,但对进程来说一点也不重要,所以,如果有很多线程正在进行,我打赌进程的性能不会超过线程。
同时,过程(尤指)在Windows上)启动“更重”,所以如果出现了大量的“任务启动”,那么线程在性能上也可以轻松地超过进程。
接下来,您可以拥有带有“超线程”的CPU,它可以非常快地(至少)在一个核心上运行两个线程--但是不能运行进程(因为“超线程”线程不能使用不同的地址空间) --这是线程可以在性能上获胜的另一种情况。
如果这些考虑因素都不适用的话,那么比赛应该不会比平局更好。
发布于 2010-07-31 02:53:49
我不知道这句话到底是什么意思。简直是胡说八道。
proc线程共享的主要内容是虚拟内存地址空间。
发布于 2012-02-15 02:56:03
我发现这也是真的。但我认为这和日程安排有关。因为如果运行足够长的时间,多进程就像多线程一样快。这个数字大约是10秒。如果算法需要运行10秒。多进程和多线程一样快.但是如果它只需要运行不到1秒。多进程比多线程快得多.
https://stackoverflow.com/questions/3376562
复制相似问题