这个问题与400 threads in 20 processes outperform 400 threads in 4 processes while performing an I/O-bound task非常相似。唯一的区别是，链接的问题与I / O绑定任务有关，而此问题与CPU绑定任务有关。
这里是实验代码，可以启动指定数量的工作进程，然后在每个进程中启动指定数量的工作线程，并执行计算第n个质数的任务。
import math
import multiprocessing
import random
import sys
import time
import threading
def main():
processes = int(sys.argv[1])
threads = int(sys.argv[2])
tasks = int(sys.argv[3])
# Start workers.
in_q = multiprocessing.Queue()
process_workers = []
for _ in range(processes):
w = multiprocessing.Process(target=process_worker, args=(threads, in_q))
w.start()
process_workers.append(w)
start_time = time.time()
# Feed work.
for nth in range(1, tasks + 1):
in_q.put(nth)
# Send sentinel for each thread worker to quit.
for _ in range(processes * threads):
in_q.put(None)
# Wait for workers to terminate.
for w in process_workers:
w.join()
total_time = time.time() - start_time
task_speed = tasks / total_time
print('{:3d} x {:3d} workers => {:6.3f} s, {:5.1f} tasks/s'
.format(processes, threads, total_time, task_speed))
def process_worker(threads, in_q):
thread_workers = []
for _ in range(threads):
w = threading.Thread(target=thread_worker, args=(in_q,))
w.start()
thread_workers.append(w)
for w in thread_workers:
w.join()
def thread_worker(in_q):
while True:
nth = in_q.get()
if nth is None:
break
num = find_nth_prime(nth)
#print(num)
def find_nth_prime(nth):
# Find n-th prime from scratch.
if nth == 0:
return
count = 0
num = 2
while True:
if is_prime(num):
count += 1
if count == nth:
return num
num += 1
def is_prime(num):
for i in range(2, int(math.sqrt(num)) + 1):
if num % i == 0:
return False
return True
if __name__ == '__main__':
main()
这是我运行此程序的方式：
python3 foo.py <PROCESSES> <THREADS> <TASKS>
例如，python3 foo.py 20 20 2000创建20个工作进程，每个工作进程中有20个线程（因此共有400个工作线程），并执行2000个任务。最后，该程序打印出执行任务所花费的时间以及平均每秒执行多少任务。
我正在具有8 GB RAM和4个CPU的Linode虚拟专用服务器上测试此代码。它正在运行Debian 9。
$ cat /etc/debian_version
9.9
$ python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ free -m
total used free shared buff/cache available
Mem: 7987 67 7834 10 85 7734
Swap: 511 0 511
$ nproc
4
这里有一些试运行，其中400个工作线程分布在20个工作进程之间（即20个工作进程中的每个工作进程中都有20个工作线程）。
以下是结果：
$ python3 bar.py 20 20 2000
20 x 20 workers => 12.702 s, 157.5 tasks/s
$ python3 bar.py 20 20 2000
20 x 20 workers => 13.196 s, 151.6 tasks/s
$ python3 bar.py 20 20 2000
20 x 20 workers => 12.224 s, 163.6 tasks/s
$ python3 bar.py 20 20 2000
20 x 20 workers => 11.725 s, 170.6 tasks/s
$ python3 bar.py 20 20 2000
20 x 20 workers => 10.813 s, 185.0 tasks/s
当我使用top命令监视CPU使用率时，我发现每个python3工作进程都消耗大约15％到25％的CPU。
现在我认为我只有4个CPU。即使我启动了20个工作进程，在物理时间的任何时候最多也只能运行4个进程。此外，由于全局解释器锁（GIL），每个进程中只有一个线程（因此最多四个线程）可以在物理时间的任何时间运行。
因此，我认为如果将进程数减少到4，并将每个进程的线程数增加到100，以便线程总数仍然保持400，则性能应该不会降低。
但是测试结果显示，每个包含100个线程的4个进程的性能始终比每个包含20个线程的20个进程的性能差。
$ python3 bar.py 4 100 2000
4 x 100 workers => 19.840 s, 100.8 tasks/s
$ python3 bar.py 4 100 2000
4 x 100 workers => 22.716 s, 88.0 tasks/s
$ python3 bar.py 4 100 2000
4 x 100 workers => 20.278 s, 98.6 tasks/s
$ python3 bar.py 4 100 2000
4 x 100 workers => 19.896 s, 100.5 tasks/s
$ python3 bar.py 4 100 2000
4 x 100 workers => 19.876 s, 100.6 tasks/s
每个python3工作进程的CPU使用率在50％到66％之间。
为了进行比较，我记录了一个事实，即情况1和情况2均优于单个进程中所有400个线程的情况。显然，这是由于全局解释器锁定（GIL）。
$ python3 bar.py 1 400 2000
1 x 400 workers => 34.762 s, 57.5 tasks/s
$ python3 bar.py 1 400 2000
1 x 400 workers => 35.276 s, 56.7 tasks/s
$ python3 bar.py 1 400 2000
1 x 400 workers => 32.589 s, 61.4 tasks/s
$ python3 bar.py 1 400 2000
1 x 400 workers => 33.974 s, 58.9 tasks/s
$ python3 bar.py 1 400 2000
1 x 400 workers => 35.429 s, 56.5 tasks/s
单个python3工作进程的CPU使用率介于110％和115％之间。
同样，为了比较，这是当有400个进程（每个进程都有一个线程）时结果的外观。
$ python3 bar.py 400 1 2000
400 x 1 workers => 8.814 s, 226.9 tasks/s
$ python3 bar.py 400 1 2000
400 x 1 workers => 8.631 s, 231.7 tasks/s
$ python3 bar.py 400 1 2000
400 x 1 workers => 10.453 s, 191.3 tasks/s
$ python3 bar.py 400 1 2000
400 x 1 workers => 8.234 s, 242.9 tasks/s
$ python3 bar.py 400 1 2000
400 x 1 workers => 8.324 s, 240.3 tasks/s
每个python3工作进程的CPU使用率在1％到3％之间。
从每个案例中选择中位数结果，我们得到以下摘要：
Case 1: 20 x 20 workers => 12.224 s, 163.6 tasks/s
Case 2: 4 x 100 workers => 19.896 s, 100.5 tasks/s
Case 3: 1 x 400 workers => 34.762 s, 57.5 tasks/s
Case 4: 400 x 1 workers => 8.631 s, 231.7 tasks/s
即使我只有4个CPU，为什么20个进程x 20个线程的性能要比4个进程x 100个线程好？
实际上，尽管只有4个CPU，但400个进程x 1个线程的性能最佳？为什么？
答案 0 :(得分：1)
在Python线程可以执行代码之前，它需要获取Global Interpreter Lock (GIL)。这是一个每个进程锁。在某些情况下（例如，在等待I / O操作完成时），线程将例行释放GIL，以便其他线程可以获取它。如果活动线程在一定时间内没有放弃锁，则其他线程可以发信号通知活动线程释放GIL，以便轮流使用。
考虑到这一点，让我们看一下代码在我的4核笔记本电脑上的性能：
在最简单的情况下（具有1个线程的1个进程），我得到〜155个任务/秒。 GIL在这里没有妨碍我们。我们使用一个内核的100％。
如果我增加线程数量（1个进程包含4个线程），我将获得约70个任务/秒。起初这可能是违反直觉的，但可以通过以下事实来解释：您的代码主要是CPU约束的，因此所有线程几乎一直都需要GIL。他们中只有一个可以一次运行它的计算，因此我们无法从多线程中受益。结果是我们使用了我的4个内核中每个内核的约25％。更糟的是，获取和释放GIL以及上下文切换会增加大量开销，从而降低整体性能。
添加更多线程（1个进程包含400个线程）无济于事，因为一次只能执行其中一个。在我的笔记本电脑上，性能与情况（2）非常相似，同样，我们使用了4个内核中每个内核的25％。
使用4个进程（每个进程有1个线程），我得到〜550个任务/秒。我的情况几乎是（1）的4倍。实际上，由于进程间通信和共享队列上的锁定所需的开销少了一些。请注意，每个进程都使用自己的GIL。
有4个进程每个运行100个线程，我得到〜290个任务/秒。再次，我们看到了在（2）中看到的减速，这次影响了每个单独的过程。
400个进程每个运行1个线程，我得到〜530个任务/秒。与（4）相比，由于进程间通信和共享队列的锁定，我们看到了额外的开销。
有关这些影响的更详细说明，请参阅David Beazley's talk Understanding the Python GIL。
注意：Some Python interpreters like CPython and PyPy have a GIL while others like Jython and IronPython don't。如果您使用其他Python解释器，则可能会看到非常不同的行为。
答案 1 :(得分：0)
由于臭名昭著的global interpreter lock，Python中的线程无法并行执行：
在CPython中，全局解释器锁（即GIL）是一个互斥体，用于保护对Python对象的访问，从而防止多个线程一次执行Python字节码。
这就是每个进程一个线程在基准测试中表现最佳的原因。
如果真正的并行执行很重要，请避免使用threading.Thread。