这个问题与20个过程中的400个线程非常相似，在执行I/O界任务时，在4个过程中的400个线程都优于400个线程。唯一的区别是链接的问题是关于I/O结合任务的，而这个问题是关于CPU结合的任务。
实验代码
这是可以启动指定数量的工艺过程的实验代码，然后在每个过程中启动指定数量的工作线程并执行计算n-prime数字的任务。
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个线程(因此总共400个工作线程(创建20个工作过程，并执行2000个任务。最后，该程序打印执行任务所需的时间以及平均每秒执行多少任务。
环境
我正在具有8 GB RAM和4 CPU的Linode虚拟专用服务器上测试此代码。它正在运行Debian9。
$ 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
案例1：20过程x 20线程
以下是一些试验运行，其中有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。
情况2：4个过程x 100线程
现在我认为我只有4个CPU。即使我启动了20个工作流程，最多只能在物理时间的任何时候运行4个流程。此外，由于全局解释器锁(GIL(，每个过程中只有一个线程(因此总共4个线程可以在物理时间的任何时候运行。
因此，我认为，如果我将过程数减少到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％之间。
情况3：1过程x 400线程
只是为了进行比较，我记录了一个事实，即情况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％之间。
情况4：400进程x 1线程
再次，仅供比较，这是当有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
问题
为什么20个过程x 20线程的性能要比4个过程x 100线程好，即使我只有4个CPU？
实际上，尽管只有4个CPU，但400个过程x 1线程表现最好？为什么？
在python线程可以执行获得全局解释器锁(GIL(所需的代码之前。这是每条程序锁定。在某些情况下(例如，等待I/O操作完成时(线程通常会释放GIL，以便其他线程可以获取它。如果活动线程在一定时间内没有放弃锁定，则其他线程可以发出主动线的信号以释放GIL，以便它们轮流。
考虑到这一点，让我们看一下您的代码在我的4个核心笔记本电脑上的性能：
-
在最简单的情况(1个带1个线程的过程(中，我得到〜155个任务/s。吉尔在这里没有妨碍我们的路。我们使用一个核心的100％。
-
如果我凸起线程数(带有4个线程的1个进程(，我会得到〜70个任务/s。一开始这可能是违反直觉的，但是可以通过以下事实来解释您的代码大部分是在CPU结合的事实，因此所有线程几乎一直都需要GIL。他们中只有一个可以一次运行其计算，因此我们不会从多线程中受益。结果是我们使用了我的4个核心中的每一个中的25％。为了使事情变得更糟，获取和发布GIL以及上下文切换增加了重要的开销，从而降低了整体性能。
-
添加更多线程(带有400个线程的1个进程(无济于事，因为其中只有一个被执行。在我的笔记本电脑的性能上与情况(2(非常相似，我们同样使用了我的4个内核中的每一个。
-
有4个过程，每个过程有1个线程，我得到〜550任务/s。我(1(几乎是我得到的4倍。实际上，由于程序间通信和锁定共享队列所需的开销，因此要少一些。请注意，每个过程都使用自己的GIL。
-
有4个流程每个运行100个线程的过程，我得到〜290任务/s。再次，我们看到了(2(中看到的慢速下降，这次影响了每个单独的过程。
-
有400个流程运行1个线程，我得到〜530任务/s。与(4(相比
请参阅David Beazley的演讲理解Python Gil，以更深入地解释这些效果。
注意：一些Python口译员(例如Cpython和Pypy(具有GIL，而其他像Jython和Ironpython这样的解释者则没有。如果您使用另一个Python解释器，您可能会看到非常不同的行为。
python中的线程由于臭名昭著的全局解释器锁定而不会并行执行：blockquote>
在CPYTHON中，全局解释器锁定或GIL是一个静音的静音，可保护对Python对象的访问，防止多个线程立即执行Python bytecodes。
这就是为什么每个进程在基准测试中表现最佳的原因。
如果真正的并行执行很重要，请避免使用threading.Thread。