如何在 HPC 上通过 Python 使用多个 CPU？

Question

我正在使用 Python 进行数据分析项目，并且正在使用 HPC 集群来处理我的数据。 我很难让我的程序使用多个 CPU 以使其运行得更快。 这是我正在做的一个例子：

import multiprocessing as mp
import csv

def calc_function(sample-file):  
    # do some heavy calculation and make a dictionary about it
    sample_dict = {'Name': str(sample_file), 'Info': 'blablabla'}
    return sample_dict

list_of_files = [1, 2]
pool = mp.Pool( mp.cpu_count() )
with pool as p:
    list_of_results = p.map(calc_function, list_of_files)

# make csv file
# add all data to csv

我发现即使我给他们的时间与我根本不使用多处理所需的时间相同或更多，我的工作也会超时。

我知道这种方式不是很好，因为它依赖于整个池在保存到 csv 之前完成。 我在其他问题中发现，最好将所有内容放在队列中并将其写入 csv。 但我也无法让它发挥作用。

我尝试了一个 3GB 的小型数据集，没有 mp.Pool 大约需要 40 分钟。 如果有帮助，这也是我的 SBATCH 文件：

#SBATCH --partition=general
#SBATCH --qos=short
#SBATCH --time=1:00:00
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
#SBATCH --mem=4G
#SBATCH --mail-type=BEGIN,END

conda activate main_env
srun python <my_file.py>
conda deactivate

谢谢您的帮助！

Answer 1

问： “如何在 HPC 上通过 Python 使用多个 CPU？ ”

A ：
错了，对不起，
Python永远不可能
_{（除非发生从头开始、自下而上的全面重新设计，Python 之父 Guido van ROSSUM 先生经常引用他自己的话，认为在可预见的努力和一些可接受的时间范围）}
由于基本的设计属性，使用更多的 CPU（内核），因为 Python 解释器进程和线程都等待单个（进程中心，主要并发-避免， MUTEX - lock作为协调点），全局I解释器锁（又名GIL ）。

这就是说，无论 Python-Interpreter 进程启动多少线程，所有线程都在等待，并且只有一个线程成功地获取了 GIL MUTEX 锁，它会做少量有用的工作（大约100 ms的可配置块） . 我再说一遍，所有其他人等等，什么都不做。 这与 HPC 在进行计算时所争取的（即高性能计算 - 请注意 PERFORMANCE一词的重音，更准确地说是HIGH performance ）而言，基本上是完全相反的状态。

如果我们一致地使用相同的词来表示这些词确实自然具有的相同含义，那么将基于 Python-Interpreter 的作业启动到 HPC 基础设施上更接近于高性能等待，而不是永远高性能计算（智能矢量化非 Python，绕过 GIL 的数学库肯定是这个事实的例外，但它们本身不是 Python 解释器，而是运行良好且性能优化的外部数学引擎，所以观察仍然成立）。

问题（原样） - 什么是最好的处理策略......？

为了

• 要处理的给定文件名列表
• 将文件内容转换为结果的给定过程
• 一个给定的 HPC 基础设施来启动一个计算策略

解决方案

避免任何和所有附加的间接费用：

1. 忘记队列——队列处理开销加上数据SER/DES开销（如果要提高性能，读取pickle.dumps( sample_dict ) + pickle.loads( sample_dict )代表非常糟糕的反模式）
2. 忘记生成mp.cpu_count() - 整个 Python-Interepreter 进程的许多完整副本（包括所有它的内部数据结构、文件句柄等），如果这样做很快就会在现代内存占用{ 8- | 16- | 32- | 64- | ... } { 8- | 16- | 32- | 64- | ... } { 8- | 16- | 32- | 64- | ... } - 核心 CPU 耗尽物理 RAM 并将 O/S 变成 RAM 抖动的换入/换出 moribundus，只需将物理 RAM 块从磁盘移动到 RAM / 从- RAM-to-disk ad 恶心，将较少的 RAM-I/O 带宽（如果有的话）留给一些（现在已经饿死）窒息的计算。 因此，已经低效（高性能等待）的 GIL 锁引擎现在甚至等待从 RAM 到 CPU 接收下一个伪指令的数据，以便能够在接下来的 100 毫秒内进行一些“计算”

最有前途的候选人
具有最大 Python 允许的性能：

如果您不能或不重新分解代码，以绕过 GIL 锁性能避免陷阱，请执行以下操作：

a) 使用slurm工具在您的 HPC 使用计划允许的范围内启动尽可能多的N个 python 进程（Python-Interpreter 不需要任何多核，策略的其他部分也不需要，适当大小的 RAM 特定参数可能有助于查找更多可用节点将批次映射到 HPC 基础设施 - 请参阅下面的备注）

b）通过特定于进程的启动配置参数配置每个slurm -launched python-process

c) 根据slurm -launch 提供的进程特定参数自行配置每个 python 进程

d) 让每个 python 进程开始一个微不足道的、私有的、避免并发的、令人尴尬的并行，但仍然是一个 Python 解释器本机纯 - [SERIAL]处理那些来自它自己的、非重叠的文件给定<_list-of-filenames_>子集，第 1 个从第 1 个开始，第 2 个在第 2 个第 2 个部分，第 3 个在第 3 个第 N 个，最后一个原始列表的最后 N 个。

e) 使文件处理功能将其自己的结果自行存储在某个文件中，无论是 .CSV 还是其他文件（HPC 策略的详细信息可能更喜欢基于附加的存储，也可能不是，稍后收集和加入单个文件由 O/S 工具在 HPC 时间配额“之外”安全地执行）

f) 最后收集并加入结果文件，使用 O/S 工具 ex-post ad-libidum

概括 ：

这个秘籍完成了所有以性能为导向的步骤，而无需添加单个（昂贵且重复多次）指令，并且将成为您的 HPC 基础架构上最快的计算策略。

由于专注于性能，这种编排为纯 [SERIAL] 顺序处理增加了最小的附加开销，因此实现的加速将最好与N扩展：

               1
S =  __________________________; where s, ( 1 - s ), N were defined above
                ( 1 - s )            pSO:= [PAR]-Setup-Overhead     add-on
     s  + pSO + _________ + pTO      pTO:= [PAR]-Terminate-Overhead add-on
                    N               

有关 HPC 使用策略和 HPC 资源/HPC 使用配额的详细信息，请咨询您的 HPC 基础设施管理员和技术支持部门。

细节很重要（不同的文件存储文件系统，暂存存储访问/使用/删除策略可以并且将决定最佳的启动前和完成后文件操作，以便整个批处理过程充分利用合法HPC-基础设施资源的使用）

没有其他魔法可以在这里提供帮助。