【发布时间】：2023-04-03 11:39:01
【问题描述】：
我试图了解 CPython 的 GIL 是如何工作的，以及 CPython 2.7.x 和 CPython 3.4.x 中的 GIL 有什么区别。我正在使用此代码进行基准测试：
from __future__ import print_function
import argparse
import resource
import sys
import threading
import time
def countdown(n):
while n > 0:
n -= 1
def get_time():
stats = resource.getrusage(resource.RUSAGE_SELF)
total_cpu_time = stats.ru_utime + stats.ru_stime
return time.time(), total_cpu_time, stats.ru_utime, stats.ru_stime
def get_time_diff(start_time, end_time):
return tuple((end-start) for start, end in zip(start_time, end_time))
def main(total_cycles, max_threads, no_headers=False):
header = ("%4s %8s %8s %8s %8s %8s %8s %8s %8s" %
("#t", "seq_r", "seq_c", "seq_u", "seq_s",
"par_r", "par_c", "par_u", "par_s"))
row_format = ("%(threads)4d "
"%(seq_r)8.2f %(seq_c)8.2f %(seq_u)8.2f %(seq_s)8.2f "
"%(par_r)8.2f %(par_c)8.2f %(par_u)8.2f %(par_s)8.2f")
if not no_headers:
print(header)
for thread_count in range(1, max_threads+1):
# We don't care about a few lost cycles
cycles = total_cycles // thread_count
threads = [threading.Thread(target=countdown, args=(cycles,))
for i in range(thread_count)]
start_time = get_time()
for thread in threads:
thread.start()
thread.join()
end_time = get_time()
sequential = get_time_diff(start_time, end_time)
threads = [threading.Thread(target=countdown, args=(cycles,))
for i in range(thread_count)]
start_time = get_time()
for thread in threads:
thread.start()
for thread in threads:
thread.join()
end_time = get_time()
parallel = get_time_diff(start_time, end_time)
print(row_format % {"threads": thread_count,
"seq_r": sequential[0],
"seq_c": sequential[1],
"seq_u": sequential[2],
"seq_s": sequential[3],
"par_r": parallel[0],
"par_c": parallel[1],
"par_u": parallel[2],
"par_s": parallel[3]})
if __name__ == "__main__":
arg_parser = argparse.ArgumentParser()
arg_parser.add_argument("max_threads", nargs="?",
type=int, default=5)
arg_parser.add_argument("total_cycles", nargs="?",
type=int, default=50000000)
arg_parser.add_argument("--no-headers",
action="store_true")
args = arg_parser.parse_args()
sys.exit(main(args.total_cycles, args.max_threads, args.no_headers))
在 Ubuntu 14.04 和 Python 2.7.6 下的四核 i5-2500 机器上运行此脚本时，我得到以下结果（_r 代表实时，_c 代表 CPU 时间，_u 代表用户模式，_s 代表内核模式）：
#t seq_r seq_c seq_u seq_s par_r par_c par_u par_s
1 1.47 1.47 1.47 0.00 1.46 1.46 1.46 0.00
2 1.74 1.74 1.74 0.00 3.33 5.45 3.52 1.93
3 1.87 1.90 1.90 0.00 3.08 6.42 3.77 2.65
4 1.78 1.83 1.83 0.00 3.73 6.18 3.88 2.30
5 1.73 1.79 1.79 0.00 3.74 6.26 3.87 2.39
现在，如果我将所有线程绑定到一个内核，结果就会大不相同：
taskset -c 0 python countdown.py
#t seq_r seq_c seq_u seq_s par_r par_c par_u par_s
1 1.46 1.46 1.46 0.00 1.46 1.46 1.46 0.00
2 1.74 1.74 1.73 0.00 1.69 1.68 1.68 0.00
3 1.47 1.47 1.47 0.00 1.58 1.58 1.54 0.04
4 1.74 1.74 1.74 0.00 2.02 2.02 1.87 0.15
5 1.46 1.46 1.46 0.00 1.91 1.90 1.75 0.15
所以问题是：为什么在多核上运行这个 Python 代码比在单核上运行慢 1.5x-2x 和 CPU 时钟慢 4x-5x？
四处打听和谷歌搜索产生了两个假设：
- 在多个内核上运行时，可以重新调度线程以在不同的内核上运行，这意味着本地缓存会失效，因此速度会变慢。
- 在一个内核上挂起线程并在另一个内核上激活它的开销大于在同一内核上挂起和激活线程。
还有其他原因吗？我想了解正在发生的事情并能够用数字来支持我的理解（这意味着如果减速是由于缓存未命中，我想查看并比较两种情况的数字）。
【问题讨论】：
-
是的，我知道 GIL 并且在并行线程中运行倒计时实际上比在单线程中慢并不令我感到惊讶。令我惊讶和不明白的是，为什么在多核上运行此脚本比在单核上运行要慢得多。
-
我注意到在添加第一个版本中报告的时间时（因此没有任务集），总和与
time报告的时间不对应。如果将time.clock()更改为time.time()，这种差异就会消失。使用taskset方法时似乎仍然有一点优势，但不确定这一切意味着什么...... -
On *nix time.clock() 报告 CPU 时间，而不是挂钟时间 (docs.python.org/2.7/library/time.html#time.clock)。所以结果应该这样解释：在多核上运行这段代码比在单核上运行需要更多的 CPU 工作。我不是第一个偶然发现这些结果的人（例如youtu.be/Obt-vMVdM8s?t=55s），但我对解释并不满意。但你是对的，我也应该实时测量和报告。我会更新代码。
标签：
python
multithreading
cpython
gil
本站文章如无特殊说明，均为本站原创，如若转载，请注明出处：为什么这个 Python 脚本在多核上比在单核上运行慢 4 倍 - Python技术站
微信扫一扫 
支付宝扫一扫 