linux - 映射位于 ramdisk 上的 numpy 数组所带来的开销是多少？

Question

我有类似这个问题的情况:

Share Large, Read-Only Numpy Array Between Multiprocessing Processes

除了一个显着差异外，我绝对希望整个阵列都存在于 RAM 中。为了清楚起见，重申一下:

我想在多个进程之间共享一个相当大的 numpy 数组，只读，并将整个数组保存在 RAM 中以获得绝对最佳性能。仅 linux 的解决方案很好。我也希望它能在生产环境中工作，所以宁愿避免依赖于研究导向的包，或做任何 hacky。

对于这种情况，在我看来，numpy-sharedmem 风格的方法有点矫枉过正。仍然突出的方法是:

1. 在其他线程中建议 here , 将把数组作为一个全局变量并简单地 fork()。这似乎是尽可能快的。多个进程最终是否会以任何方式竞争共享内存页面，或者以某种方式干扰彼此的缓存，这会引入一些与单进程场景​​相比的开销？

   虽然由于像 this one 这样的评论，我对这种方法持怀疑态度.在我的多处理环境中尝试使用 fork() 也可能不方便(此时我很可能会使用 Twisted)。

2. 虽然 numpy 的内置内存映射 was在另一个线程中提出，它显然适用于比主内存更大的阵列。我不相信我在 stackoverflow 上看到了以下讨论的可能性:为什么不将 npy 文件放入 ramdisk 并对其进行 mmap (mmap_mode='r') 以实现简单和稳定的只读内存中共享 numpy 数组？

   此处的性能注意事项是什么？它与 fork() 方法或真正的共享内存方法(例如 numpy-sharedmem)有很大不同吗？ numpy 中的 mmap 层会产生多少开销？当 npy 文件放在 ramdisk 上时，连续性很重要吗？缓存局部性是否受到影响？进程之间是否会发生争用？

我仅出于稳定性因素而倾向于选项 2，但想了解可能的性能差异，并了解为什么 mmap+ramdisk 对于​​许多与我的应用程序相似或不相似的应用程序来说可能是一种快速简便的解决方案。

Answer 1

使用 ramdisk 将涉及访问文件系统、在 ramdisk 和页面缓存之间复制数据所涉及的所有开销。

如果您使用 ramfs，访问将锁定在 RAM 中的数据将不会产生开销。然而，这意味着其他数据将无法保存在 RAM 中，可能会降低整体性能。

使用 tmpfs 具有与匿名内存相似的性能。