科学计算数据分析【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址https://gitcode.com/gh_mirrors/nu/numpy点击查看免费下载导读NumPy 通过向量化操作在 Python 中实现了高性能数值计算但向量化本身并不能自动利用多核处理器的全部算力。本文以 NumPy 官方用户指南《Writing Performant NumPy Code with Multi-Core CPUs》为主体系统讲解利用 Python 标准库concurrent.futures的多进程/多线程执行器与第三方库Dask、joblib、threadpoolctl实现多核并行的方法并以 Mandelbrot 集合生成为贯穿全文的实战案例。读完本文你将掌握多进程/多线程的选型依据、规避 GIL 与 CPU 过载oversubscription陷阱的实操技巧以及一套可直接复制运行的并行计算模板。引言为什么向量化还不够NumPy 的设计目标是通过向量化操作在 Python 中实现高性能数值计算——将循环下推到 C 层执行避免 Python 解释器的逐元素开销。然而向量化并不总是能充分利用多核处理器的能力单次 NumPy 调用通常运行在单核上若要发挥多核优势还需要额外的并行策略。本文围绕三条主线展开在 Python 中使用多核处理器的一般概念多进程与多线程的取舍使用 Python 标准库借助 NumPy 利用多核处理器附完整示例代码面向多核处理的第三方库Dask、joblib、threadpoolctl。在 Python 中使用多核处理器的一般概念多进程Multiprocessing多进程技术允许同时执行多个进程每个进程拥有独立的 Python 解释器和独立的内存空间。Python 提供的高层 API 是concurrent.futures.ProcessPoolExecutor。优点绕过全局解释器锁GIL实现真正的并行执行各进程内存空间相互隔离避免意外共享数据。缺点每个进程都需要独立的内存空间内存占用更高进程间共享数据困难对象需要经过序列化pickling才能传递。通用建议一降低进程创建开销与线程相比进程创建需要初始化新的 Python 解释器和内存空间开销更高。缓解策略使用进程池复用已有进程而不是为每个任务新建进程。concurrent.futures.ProcessPoolExecutor正是为此设计的谨慎选择启动方式start method。除非确认应用安全否则避免显式选择fork——从多线程进程中 fork 会引发死锁或崩溃。Python 3.14 已将 POSIX 平台的默认启动方式从fork改为forkserver正是为了规避多线程进程的常见不兼容问题详见 Python 官方multiprocessing文档的 Contexts and start methods 一节。通用建议二降低通信开销进程间通信IPC因数据序列化与传输会产生显著开销在 Python 中只有可 pickle 的对象才能跨进程传递。因此需要频繁序列化数据的程序并不适合多进程。尽量减少进程间传输的数据量对于需要被多个进程访问的大数据使用共享内存结构如multiprocessing.shared_memory、multiprocessing.Array或multiprocessing.Value通过合理的负载均衡见下文确保所有进程都被高效利用避免空闲。通用建议三Pickling 考量使用多进程时worker 函数及其参数必须可 pickle。这在处理复杂数据结构或动态定义的函数时可能成为限制。如遇 pickling 问题重构代码以使用更简单的数据结构或函数——例如将 worker 函数定义在模块顶层避免使用 lambda 或嵌套函数考虑第三方库joblib其默认后端loky依赖cloudpickle做序列化能处理比标准pickle模块更广的 Python 对象如 lambda 函数。多线程Multithreading多线程允许多个线程在同一进程内运行共享同一内存空间。需要特别说明的是自由线程free-threadedPython于 Python 3.13 作为实验特性引入在 Python 3.14 成为受支持非实验性特性。当与显式设计为线程安全的库结合时线程也可以实现真正的并行执行。NumPy 官方文档在 线程安全说明 中指出NumPy 支持通过标准库threading模块在多线程环境中使用许多 NumPy 底层操作会释放 GIL因此与许多纯 Python 代码不同NumPy 能够利用多线程并行性。Python 提供的高层 API 是concurrent.futures.ThreadPoolExecutor。此外还有concurrent.futures.InterpreterPoolExecutor在独立线程中运行多个解释器、避免解释器间共享 Python 对象但该执行器目前尚不可用于 NumPy见 NumPy 议题 gh-24755。优点线程共享同一内存空间内存占用更低线程间通信更容易。缺点多个线程同时修改共享数据并伴随其他线程读取时可能产生竞态条件race condition若所用 Python 库非线程安全或对自由线程构建支持有限性能提升受限。通用建议一避免竞态条件竞态条件指多个线程同时更新共享数据导致结果不可预测。规避策略通过线程局部存储thread-local storage或显式向线程传递数据最小化线程间共享的数据量尽可能使用不可变 NumPy 数组或只读访问模式减少显式同步需求使用线程安全数据结构或同步原语锁、信号量、条件变量管理共享数据访问。注意这些同步机制使用不当会造成死锁需谨慎使用。NumPy 的 线程安全文档 也强调跨线程共享 NumPy 数组需要格外小心例如一个线程在读取数组时另一线程调整数组大小会造成未定义行为最稳妥的做法是每个线程持有自己的数组对象、共享数组只读访问或在需要变更时自行加锁。通用建议二避免 CPU 过载oversubscription部分 NumPy 操作——如矩阵乘法与线性代数函数见 线性代数参考文档——会使用底层 BLAS 库如 OpenBLAS、MKL提供的多线程。若这些操作运行在已经占满所有 CPU 核的外层线程池中就会发生 CPU 过载外层线程池与 BLAS 线程竞争同一批 CPU 资源反而降低性能。NumPy 官方 全局配置选项文档 印证了这一背景NumPy 自身的函数调用通常刻意限制为单线程但高性能线性代数依赖 OpenBLAS、MKL 等 BLAS 后端这些后端可能使用多线程线程数可通过OMP_NUM_THREADS等环境变量或threadpoolctl包控制。numpy.linalg 包文档 也明确写道BLAS/LAPACK 库是多线程且依赖处理器的可能需要环境变量或threadpoolctl等外部包来控制线程数。规避策略例如使用threadpoolctl将 BLAS 线程数限制为 1。多进程与多线程的通用建议负载均衡Balance processing load若处理负载在 worker 间分配不均部分 worker 提前完成而空闲、其余仍在工作会导致资源利用率低下、整体执行时间变长。策略采用动态任务分配任务在 worker 空闲时就绪时再分配而非预先静态分配检查chunksize参数任务块既不能太小造成过多开销也不能太大导致负载失衡。确定正确的 CPU 数量Python 提供os.cpu_count系统 CPU 数和os.process_cpu_count当前进程可用 CPU 数两个函数。但在某些环境如 Docker 容器、HPC 集群中二者可能无法反映进程实际可用的 CPU 数。更准确的做法是使用joblib.cpu_count()它会考虑 CPU 亲和性设置、Linux CFS 调度器配额等约束返回值更贴近真实可用核数详见下文 joblib 一节。用 Python 标准库利用多核Mandelbrot 集合实战本节演示如何用 Python 标准库结合 NumPy 利用多核处理器。示例选用Mandelbrot 集合生成。Mandelbrot 集合定义为满足如下条件的复数集合由迭代函数z_{n1} z_n^2 c, z_0 0产生的序列不发散到无穷大。若经过固定迭代次数后z_n的绝对值仍有界通常以不超过阈值2判断则认为c属于 Mandelbrot 集合。按照该定义复平面上每个点可独立计算天然适合并行计算。下图的热色代表复平面上每个点序列发散所用的迭代次数。多进程示例以下代码演示如何使用concurrent.futures.ProcessPoolExecutor跨多个进程并行生成 Mandelbrot 集合。该示例优先考虑清晰性而非效率。实践中在进程间传输大型 NumPy 数组代价高昂定义共享内存数组或在每个进程内创建数组可能是更高效的实现。from concurrent.futures import ProcessPoolExecutor import numpy as np from numpy.typing import NDArray def mandelbrot_block( c_block: NDArray[np.complex128], max_iter: int ) - NDArray[np.int64]: z np.zeros(c_block.shape, dtypenp.complex128) steps np.zeros(c_block.shape, dtypenp.int64) for _ in range(max_iter): mask np.abs(z) 2 z[mask] z[mask] * z[mask] c_block[mask] steps[mask] 1 return steps def mandelbrot_set( arr: NDArray[np.complex128], max_iter: int, n_workers: int, ) - NDArray[np.int64]: n_workers min(n_workers, arr.size) arrs np.array_split(arr, n_workers) with ProcessPoolExecutor(max_workersn_workers) as pool: futures [ pool.submit(mandelbrot_block, _arr, max_iter) for _arr in arrs ] results [future.result() for future in futures] return np.concatenate(results) if __name__ __main__: xmin, xmax, ymin, ymax -2.0, 1.0, -1.5, 1.5 nx, ny 800, 800 max_iter 10000 n_workers 10 real np.linspace(xmin, xmax, nx, dtypenp.float64) imag np.linspace(ymin, ymax, ny, dtypenp.float64) arr (real[:, np.newaxis] 1j * imag[np.newaxis, :]).ravel() mandelbrot_image mandelbrot_set(arr, max_iter, n_workers) mandelbrot_image mandelbrot_image.reshape((nx, ny))实现要点解读任务切分np.array_split(arr, n_workers)将整个复数平面按 worker 数均匀切块每块交给一个进程独立计算——这正是每个点可独立计算这一并行友好特性的落地进程池管理ProcessPoolExecutor作为上下文管理器使用退出时自动回收进程避免反复创建进程的开销呼应前文降低创建开销结果合并各进程返回的np.int64步数数组通过np.concatenate拼回再reshape((nx, ny))还原为图像形状入口保护if __name__ __main__:是多进程编程的必备结构——Windows 与spawn/forkserver启动方式下子进程会重新导入主模块若无此保护会引发递归创建进程的严重问题数据传递成本每个块数组都要经历 pickle 序列化→跨进程传输→反序列化的完整链路这正是文档强调清晰性优先于效率的原因。多线程示例与多进程示例类似下面用concurrent.futures.ThreadPoolExecutor跨多个线程并行生成 Mandelbrot 集合。环境准备安装自由线程版 Python运行多线程示例前需要确保已安装Python 3.13 或更高版本的自由线程free-threaded构建。根据 Python 官方文档可通过以下方式验证当前 Python 构建是否为自由线程版在终端运行python -VV检查输出中是否显示free-threading build在 Python shell 中检查sys._is_gil_enabled()的值应为False。代码示例import sys from concurrent.futures import ThreadPoolExecutor import numpy as np def mandelbrot_block(start: int, stop: int, max_iter: int) - None: z_target np.zeros(stop - start, dtypenp.complex128) indexes slice(start, stop) arr_target SHARED_readonly_arr[indexes] steps_target SHARED_updating_steps[indexes] threshold 2.0 for _ in range(max_iter): mask np.abs(z_target) threshold z_target[mask] z_target[mask] * z_target[mask] arr_target[mask] steps_target[mask] 1 SHARED_updating_steps[indexes] steps_target return None def mandelbrot_set( total_size: int, max_iter: int, n_workers: int, ) - None: chunksize total_size // n_workers with ThreadPoolExecutor(max_workersn_workers) as pool: futures [ pool.submit( mandelbrot_block, start, min(start chunksize, total_size), max_iter ) for start in range(0, total_size, chunksize) ] _ [future.result() for future in futures] if __name__ __main__: print(Python version is free-threaded:, not sys._is_gil_enabled()) assert not sys._is_gil_enabled() xmin, xmax, ymin, ymax -2.0, 1.0, -1.5, 1.5 nx, ny 800, 800 max_iter 10000 n_workers 10 real np.linspace(xmin, xmax, nx, dtypenp.float64) imag np.linspace(ymin, ymax, ny, dtypenp.float64) SHARED_readonly_arr (real[:, np.newaxis] 1j * imag[np.newaxis, :]).ravel() SHARED_readonly_arr.flags.writeable False SHARED_updating_steps np.zeros(SHARED_readonly_arr.shape, dtypenp.int64) mandelbrot_set(SHARED_readonly_arr.size, max_iter, n_workers) mandelbrot_image SHARED_updating_steps.reshape((nx, ny))实现要点解读GIL 检查入口处assert not sys._is_gil_enabled()强制要求在自由线程构建下运行——若在标准 GIL 构建下执行线程间的数值循环无法真正并行示例失去意义共享数组设计本实现刻意在多个线程间共享数组。SHARED_readonly_arr是保存待求值复数集合的只读数组通过flags.writeable False显式置为只读SHARED_updating_steps是保存各点迭代次数的更新数组——只读共享 分块写入每线程只写属于自己的切片indexes的设计正是前文避免竞态条件建议不可变数组/只读访问 最小化共享写入的代码级体现任务切分方式与多进程版用np.array_split切分数据不同多线程版按索引区间[start, stop)切分任务每个线程只读写自己负责的切片互不重叠天然避免写入冲突无返回值设计结果直接写入共享数组SHARED_updating_steps因此 worker 返回None线程间零序列化开销——这也是多线程相较多进程最大的成本优势共享内存、无 pickling。面向多核处理的第三方库在许多实际场景中第三方库比 Python 标准库提供更便捷、更高效的并行方案。DaskDask 是开源并行计算库不仅支持单机还支持机器集群并行计算。它提供与 NumPyndarrayAPI 高度相似的DaskArray如果你熟悉 NumPy可以轻松上手DaskArray将原有的数组式写法迁移到更大规模、分布式的并行计算中。joblibjoblib提供了一系列便于并行化任务的辅助函数。其两个核心能力默认后端loky依赖cloudpickle进行序列化能处理比标准pickle模块更广的 Python 对象例如lambda 函数有效缓解前文提到的 pickling 限制joblib.cpu_count()返回当前进程可用的 CPU 数会考虑 CPU 亲和性设置与 Linux CFS 调度器配额等约束。在 Docker 容器等资源受限环境中该值通常比os.cpu_count/os.process_cpu_count更准确可用于确定进程池/线程池的max_workers规模。threadpoolctlthreadpoolctl提供控制 Python 中线程池行为的工具包括 BLAS、OpenMP 等库使用的底层线程池。它允许你在同时使用多个会动用线程的库时避免前文所述的CPU 过载oversubscription问题——例如在外部线程池中运行numpy.linalg系列函数numpy.linalg模块时先用threadpoolctl将 BLAS 线程数限制为 1即可防止外层线程池与 BLAS 内部线程争抢 CPU 核。NumPy 官方的 全局配置选项文档 也推荐用threadpoolctl控制线性代数后端线程数并提及OMP_NUM_THREADS等环境变量在 OpenBLAS/MKL 场景下的等效作用。小结与选型参考维度多进程ProcessPoolExecutor多线程ThreadPoolExecutor并行本质多解释器、多内存空间真并行单进程多线程需自由线程构建Python 3.133.14 正式支持才可绕过 GIL内存开销高每进程独立内存低共享内存数据通信需 pickle 序列化代价高共享数组直接读写零序列化主要风险pickling 限制、进程创建开销竞态条件、CPU 过载BLAS 线程竞争适用场景数据可切分、传输量小、函数可 pickle大量共享只读数据、需要低延迟通信写作高性能多核 NumPy 代码时可以遵循如下决策路径先向量化确保单核上的 NumPy 操作已用足向量化能力判断并行瓶颈任务是 CPU 密集选多进程或自由线程多线程还是 I/O 密集线程即可确定 CPU 规模容器/HPC 环境下用joblib.cpu_count()而非os.cpu_count防止线程叠加并行任务中调用 BLAS 密集运算时用threadpoolctl将 BLAS 线程限制为 1避免 CPU 过载控制任务粒度调好chunksize既不过细调度开销也不过粗负载失衡并优先采用动态任务分配。上述标准库与第三方库两条技术路线在 用户指南目录 中有系统编排配合 NumPy 线程安全说明 与 全局配置选项文档 阅读可以形成从概念到落地的完整多核优化知识闭环。赞分享科学计算数据分析【免费下载链接】numpyThe fundamental package for scientific computing with Python.项目地址https://gitcode.com/gh_mirrors/nu/numpy点击查看免费下载相关推荐FastAPI 部署实战用 Uvicorn --workers 多工作进程榨干多核 CPUFastAPI 部署实战用 Uvicorn workers 多工作进程榨干多核 CPU 本文基于 FastAPI 官方文档 Server Workers –后端Web框架API设计FastAPI 部署实践用 Uvicorn 多 Worker 进程--workers榨干多核 CPUFastAPI 部署实践用 Uvicorn 多 Worker 进程 workers 榨干多核 CPU 多进程复制Replication是 FastAP后端Web框架API设计FastAPI 部署实战使用 --workers 让 Uvicorn 开启多 Worker 进程榨干多核 CPUFastAPI 部署实战使用 workers 让 Uvicorn 开启多 Worker 进程榨干多核 CPU 本文对应 FastAPI 官方部署指南中的 后端Web框架API设计创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考