【发布时间】:2017-06-16 18:16:54
【问题描述】:
我有类似这个问题的情况:
Share Large, Read-Only Numpy Array Between Multiprocessing Processes
除了一个显着的区别,我绝对希望整个阵列都存在于 RAM 中。为了清楚起见,重申一下:
我想在多个进程之间共享一个相当大的 numpy 数组,只读,并将整个数组保存在 RAM 中以获得绝对最佳的性能。 仅限 linux 的解决方案很好。我也希望它能够在生产环境中工作,所以宁愿避免依赖于面向研究的包,或者做任何 hacky。
对于这种情况,在我看来numpy-sharedmem 风格的方法是矫枉过正。仍然突出的方法是:
-
在另一个线程here 中建议,将数组保留为全局变量并简单地
fork()。这似乎会尽可能快。多个进程最终会以任何方式竞争共享内存页面,还是会以某种方式干扰彼此的缓存,从而与单进程方案相比会引入一些开销?由于像this one 这样的cmets,我对这种方法持怀疑态度。在我的多处理环境中尝试使用
fork()也可能不方便(此时我很可能会使用 Twisted)。 -
虽然 numpy 的内置内存映射 was 在另一个线程中出现,但它显然是面向比主内存大的数组。我不相信我在 stackoverflow 上看到过以下可能性:为什么不将 npy 文件放入 ramdisk 并将其映射 (
mmap_mode='r') 以获得简单且稳定的只读内存共享 numpy 数组?这里有哪些性能注意事项?它与
fork()方法或真正的共享内存方法(例如numpy-sharedmem)有很大不同吗? numpy 中的 mmap 层会产生多少开销?当 npy 文件放在 ramdisk 上时,连续性很重要吗?缓存位置是否受到影响?进程之间是否会发生争用?
我倾向于仅考虑稳定性因素的选项 2,但想了解可能的性能差异,并了解为什么 mmap+ramdisk 可能是许多与我相似或不那么相似的应用程序的快速简便的解决方案。
【问题讨论】:
-
Linux 上的共享内存已经实现为 tmpfs 上的 mmap,所以没问题。
标签: linux numpy multiprocessing fork shared-memory