Python Multiprocessing with PyCUDA
我遇到了一个问题,我想在多个 CUDA 设备上拆分,但我怀疑我当前的系统架构阻碍了我;
我设置的是一个 GPU 类,具有在 GPU 上执行操作的函数(奇怪)。这些操作的风格是
1 2
|
for iteration in range(maxval):
result[iteration]=gpuinstance.gpufunction(arguments,iteration)
|
我原以为 N 个设备会有 N 个 gpuinstance,但我对多处理了解不够,无法看到应用此功能的最简单方法,以便异步分配每个设备,而且奇怪的是我的示例很少偶遇具体演示了处理后的整理结果。
谁能给我这方面的任何指点?
更新
感谢 Kaloyan 在多处理领域的指导;如果 CUDA 不是特别的症结所在,我会将您标记为已回答。对不起。
在使用此实现之前,gpuinstance 类使用 import pycuda.autoinit 启动了 CUDA 设备,但这似乎不起作用,只要每个(正确范围的)线程遇到 cuda 命令,就会抛出 invalid context 错误。然后我尝试在类的 __init__ 构造函数中手动初始化…
1 2 3 4
|
pycuda.driver.init()
self.mydev=pycuda.driver.Device(devid) #this is passed at instantiation of class
self.ctx=self.mydev.make_context()
self.ctx.push()
|
我的假设是在创建 gpuinstances 列表和线程使用它们之间保留上下文,因此每个设备都处于自己的上下文中。
(我还实现了一个析构函数来处理 pop/detach 清理)
问题是,只要线程尝试接触 CUDA,仍然会出现 invalid context 异常。
各位有什么想法吗?感谢能走到这一步。自动为”香蕉”工作的人投票! :P
- gpuinstance.gpufunction(arguments,iteration) 是异步的还是会阻止执行?
你需要先把你所有的香蕉都放在 CUDA 方面,然后考虑用 Python 完成这项工作的最佳方法[我知道无耻的代表嫖娼]。
CUDA 多 GPU 模型在 4.0 之前非常简单 – 每个 GPU 都有自己的上下文,每个上下文必须由不同的主机线程建立。所以伪代码中的想法是:
应用程序启动,进程使用 API 来确定可用 GPU 的数量(注意 Linux 中的计算模式之类的东西)
应用程序为每个 GPU 启动一个新的主机线程,传递一个 GPU id。每个线程隐式/显式调用等效的 cuCtxCreate() 传递它已分配的 GPU id
利润!
在 Python 中,这可能看起来像这样:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
|
import threading
from pycuda import driver
class gpuThread(threading.Thread): def __init__(self, gpuid): threading.Thread.__init__(self) self.ctx = driver.Device(gpuid).make_context() self.device = self.ctx.get_device()
def run(self): print"%s has device %s, api version %s" // % (self.getName(), self.device.name(), self.ctx.get_api_version()) # Profit!
def join(self): self.ctx.detach() threading.Thread.join(self)
driver.init() ngpus = driver.Device.count() for i in range(ngpus): t = gpuThread(i) t.start() t.join() |
这假设只建立一个上下文而不事先检查设备是安全的。理想情况下,您会检查计算模式以确保尝试安全,然后在设备繁忙时使用异常处理程序。但希望这能给出基本的想法。
-
@talonmies 一如既往,谢谢,但快速查询:如果我理解正确,每个线程都被”实例化”、执行并加入。这不会导致执行串行运行吗?我认为最简单的解决方法是将 t.join() 分成一个单独的循环。
-
@Andrew Bolter:是的,我想应该在一个循环中调用所有的 start 方法,然后再调用所有的连接。我也想知道在那种情况下的全局解释器锁……我必须承认我为我的 python 多 GPU 使用了 mpi4py,我也有一个用于多 GPU 的 pthreads 框架,但通常只使用 C/ C 和 Fortran。
-
@Andrew Bolter:我刚刚在我发布的代码的修改版本中添加了一点工具,我开始怀疑为此使用 python 线程的理智。我不想打赌我在这一点上发布的内容的正确性……
-
我怀疑我会以 MPI 为目标来重构问题,但我觉得这应该更微不足道。此外,为了解决线程缺陷,我也一直在研究多处理。
-
另外,我不太了解您的”pre-4.0″评论,因为我理解它仍然支持以前的上下文相关的多设备操作?
-
在 cuda 4.0 中,一个线程可以保存多个 GPU 上下文,您只需在任何操作之前使用上下文选择来使用任何给定的 GPU。在 4.0 之前,每个 GPU 上下文有 1 个主机线程。这里的问题可能是虽然python线程是pthread,但它仍然依赖于父线程解释器,这对于CUDA线程安全来说可能还不够,CUDA 4.0之前
-
这就是我在 PG 中读到的内容,但我认为解决方法是声明式选择设备? (如你的回答)我会做一些实验。再次感谢。
-
@talonmies,在讨论过的摆弄之后,仍然得到无效的上下文(有或没有额外的上下文推送/弹出)现在查看 mpi4py 但想了解为什么这不像想象的那样工作。免责声明:我正在运行 4.0
-
原来 driver.init()s 也必须在 run 函数中。 ref:article.gmane.org/gmane.comp.python.cuda/1539/… 但由于这或多或少是 autoinit 的行为,暂时使用它,但我想要实现的是有效地实例化 4 gpu对象,我可以一遍又一遍地调用多个函数,如果这有意义吗?
-
这确实有道理。大多数人使用多 GPU 的方式是设置持久线程,每个线程都有自己的上下文,在应用程序的生命周期中,这些线程可以根据需要多次发送工作。该链接是基于多处理的,因此它与线程不同,因为您正在运行不同的进程,它们不共享解释器。
-
此 wiki 链接显示了如何进行线程化 – wiki.tiker.net/PyCuda/Examples/MultipleThreads,它似乎确实有效。您可能可以使用线程互斥锁和信号量原语为它们提供工作,并让它们根据需要调用您的单个 gpu 工作实例。
您需要的是 map 内置函数的多线程实现。这是一种实现。只需稍作修改即可满足您的特定需求,您将获得:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
|
import threading
def cuda_map(args_list, gpu_instances):
result = [None] * len(args_list)
def task_wrapper(gpu_instance, task_indices): for i in task_indices: result[i] = gpu_instance.gpufunction(args_list[i])
threads = [threading.Thread( target=task_wrapper, args=(gpu_i, list(xrange(len(args_list)))[i::len(gpu_instances)]) ) for i, gpu_i in enumerate(gpu_instances)] for t in threads: t.start() for t in threads: t.join()
return result |
它或多或少与您上面的相同,最大的不同是您不必花时间等待 gpufunction 的每个完成。
- 感谢您的评论,它引导我找到解决方案,但它遇到了与设备上下文相关的 CUDA 相关问题。现在更新问题以反映这一点
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/267865.html