用于多处理的共享内存中的大型numpy数组:这种方法有问题吗?

时间:2017-10-18 13:45:51

标签: python numpy multiprocessing

多处理是一个很棒的工具,但不是那么直接使用大内存块。您可以在每个进程中加载​​块并将结果转储到磁盘上,但有时您需要将结果存储在内存中。最重要的是,使用花哨的numpy功能。

我已阅读/搜索了很多内容并提出了一些答案:

Use numpy array in shared memory for multiprocessing

Share Large, Read-Only Numpy Array Between Multiprocessing Processes

Python multiprocessing global numpy arrays

How do I pass large numpy arrays between python subprocesses without saving to disk?

Etc等等。

它们都有缺点:不那么主流的图书馆(sharedmem);全局存储变量;不太容易阅读代码,管道等等。

我的目标是在我的工作人员中无缝使用numpy,而不必担心转换和内容。

经过多次试验,我提出了this。它适用于我的ubuntu 16,python 3.6,16GB,8核心机器。与以前的方法相比,我做了很多“快捷方式”。没有全局共享状态,没有需要在工作者中转换为numpy的纯内存指针,作为进程参数传递的大型numpy数组等。

Pastebin link above,但我会在这里放几个片段。

部分导入:

import numpy as np
import multiprocessing as mp
import multiprocessing.sharedctypes
import ctypes

分配一些共享内存并将其包装成一个numpy数组:

def create_np_shared_array(shape, dtype, ctype)
     . . . . 
    shared_mem_chunck = mp.sharedctypes.RawArray(ctype, size)
    numpy_array_view = np.frombuffer(shared_mem_chunck, dtype).reshape(shape)
    return numpy_array_view

创建共享数组并在其中添加内容

src = np.random.rand(*SHAPE).astype(np.float32)
src_shared = create_np_shared_array(SHAPE,np.float32,ctypes.c_float)
dst_shared = create_np_shared_array(SHAPE,np.float32,ctypes.c_float)
src_shared[:] = src[:]  # Some numpy ops accept an 'out' array where to store the results

产生过程:

p = mp.Process(target=lengthly_operation,args=(src_shared, dst_shared, k, k + STEP))
p.start()
p.join()

以下是一些结果(请参阅完整参考的pastebin代码):

Serial version: allocate mem 2.3741257190704346 exec: 17.092209577560425 total: 19.46633529663086 Succes: True
Parallel with trivial np: allocate mem 2.4535582065582275 spawn  process: 0.00015354156494140625 exec: 3.4581971168518066 total: 5.911908864974976 Succes: False
Parallel with shared mem np: allocate mem 4.535916328430176 (pure alloc:4.014216661453247 copy: 0.5216996669769287) spawn process: 0.00015664100646972656 exec: 3.6783478260040283 total: 8.214420795440674 Succes: True

我还做了cProfile(分配共享内存时为什么还有2秒?)并意识到有一些调用tempfile.py{method 'write' of '_io.BufferedWriter' objects}

问题

  • 我做错了吗?
  • (大)阵列来回腌制,我没有获得任何加速的东西吗?请注意,第二次运行(使用常规np数组无法通过正确性测试)
  • 有没有办法进一步改善时间,代码清晰度等? (wrt to multiprocessing paradigm)

备注

  • 我无法使用进程池,因为mem必须在fork中继承,而不是作为参数发送。

1 个答案:

答案 0 :(得分:1)

共享阵列的分配很慢,因为它显然首先写入磁盘,因此可以通过mmap共享。有关参考,请参阅heap.pysharedctypes.py。 这就是tempfile.py出现在探查器中的原因。我认为这种方法的优点是在发生崩溃时可以清理共享内存,而POSIX共享内存无法保证这一点。

你的代码没有发生酸洗,多亏了fork,正如你所说,内存是继承的。第二次运行不起作用的原因是因为子进程不允许写入父进程的内存中。相反,私有页面是动态分配的,只有在子进程结束时才会被丢弃。

我只有一个建议:你不必自己指定一个ctype,正确的类型可以从numpy dtype到np.ctypeslib._typecodes计算出来。或者只使用c_byte作为一切,并使用dtype itemsize来计算缓冲区的大小,无论如何它都会被numpy转换。