【问题标题】:Memory sharing in parallelized python code并行化 python 代码中的内存共享
【发布时间】:2012-07-19 06:29:34
【问题描述】:

我是一名大学新生和 Python 新手,请多多包涵。我正在尝试并行化一些矩阵运算。这是我使用 ParallelPython 模块的尝试:

 def testfunc(connectionMatrix, qCount, iCount, Htry, tStepCount):
        test = connectionMatrix[0:qCount,0:iCount].dot(Htry[tStepCount-1, 0:iCount]) 
        return test  

    f1 = job_server.submit(testfunc, (self.connectionMatrix, self.qCount, self.iCount, self.iHtry, self.tStepCount), modules = ("scipy.sparse",))
    f2 = job_server.submit(testfunc, (self.connectionMatrix, self.qCount, self.iCount, self.didtHtry, self.tStepCount), modules = ("scipy.sparse",))
    r1 = f1()
    r2 = f2()
    self.qHtry[self.tStepCount, 0:self.qCount] = self.qHtry[self.tStepCount-1, 0:self.qCount] + self.delT * r1 + 0.5 * (self.delT**2) * r2

似乎有一条正态曲线,x 轴上的矩阵大小和 y 轴上的加速百分比。在 100x100 矩阵上,它似乎以 30% 的速度增加达到上限。越来越小的矩阵导致增加的幅度越来越小,并且矩阵足够小和足够大,串行代码更快。我的猜测是,问题在于论点的传递。复制大矩阵的开销实际上比作业本身花费的时间更长。我能做些什么来解决这个问题?有没有办法结合内存共享和通过引用传递矩阵?如您所见,没有修改任何参数,因此它可以是只读访问。

谢谢。

【问题讨论】:

  • 哇,我认为大一编程应该比我当时更容易。我想你可以使用 Python 而不是 C 或只有一半标准库的奇怪的 lisp 方言这一事实​​意味着它们可以让你编写更有趣的程序。 :)
  • 我有点不知所措,但我相信我是唯一一个具有丰富编程经验的暑期项目申请者,所以我是唯一的选择,无论是否理想。但是,我仍在尽我最大的努力。

标签: python matrix parallel-processing pass-by-reference shared-memory


【解决方案1】:

嗯,ParallelPython 的意义在于,您可以编写不关心它是否分布在线程、进程甚至多台计算机上的代码,并且使用内存共享会破坏这种抽象。

一种选择是使用共享文件系统上的文件之类的东西,您可以在每个工作人员中映射该文件。当然这更复杂,它的好坏取决于文件系统、共享协议和网络的很多细节,但这是一种选择。

如果您愿意放弃分布式处理的选项,您可以使用 multiprocessing.Array(或 multiprocessing、Value 或 multiprocessing.sharedctypes)来访问共享内存。但此时,您可能需要考虑仅使用多处理而不是 ParallelPython 来分配作业,因为多处理是标准库的一部分,并且具有更强大的 API,而且您明确放弃了 ParallelPython 的一个主要优势.

或者您可以将这两个选项结合起来,以在许多方面实现两全其美,但就您需要更改现有代码的程度而言,也许是最好的:只需使用本地文件并将其映射。

但是,在您执行任何此操作之前,您可能需要考虑分析以查看复制矩阵是否真的是瓶颈。而且,如果是,您可能需要考虑是否有算法修复,只需复制每个作业需要的部分,而不是复制整个矩阵。 (这是否有意义取决于每个工作所需的部分是否明显少于整体。)

【讨论】:

  • 说实话,我不完全确定复制是否是减速,但在分析时,{method 'acquire' of 'thread.lock' objects}{cPickle.dumps} 需要 66% 的时间来运行整个脚本。我以为这些是酸洗,然后是复制。我暑期项目的最终目标是利用机器集群,因此多处理模块将无法工作。至于仅复制某些部分,我可以尝试重写矩阵运算以仅使用小块,然后重新组合它们。你是这个意思吗?
  • 嗯,锁可能与复制无关,但 cPickle.dumps 几乎可以肯定是。您可以通过在生成孩子之前手动腌制矩阵,然后共享腌菜(并在孩子中手动取消腌制)来节省时间。或者想出你自己的比一般酸洗更快和/或更紧凑的表示,甚至。但首先……你确定这是整个时间的 66%,还是父进程本身的 66% 时间(这可能做的实际工作很少)?最后,是的,如果可行的话,我的意思是重写操作以处理小块。
  • 哦,如果最终目标是使用集群,除非它具有某种形式的集群内存共享(可通过 Python 访问),否则您显然无法在最终版本,所以我不会在这个初步版本中使用它。共享文件系统加上 mmap 可能值得,但如果不在集群上实际使用它可能很难进行性能测试。
  • 他们肯定会占用整个时间的 66%。包含我最初发布的代码的方法需要脚本运行 525 秒中的 522 秒。该方法位于一个 for 循环中,该循环对不断变化的矩阵进行操作。重写矩阵运算的唯一问题是,例如,在乘法中,每一行都与另一个矩阵中的每一列相乘。我没有看到一种方法可以在不将相同值的副本发送到不同进程并因此使用不必要的内存量的情况下分解数据(减少传输时间)。
  • 嗯,没有比将整个内容复制到每个进程更多的不必要的内存......但听起来你是在说没有明显的方法来分解数据并在最后组合所有内容。因此,假设您必须将整个内容复制到每个进程,可能在单独的计算机上。因此,关于手动管理酸洗、比 cPickle 做得更好或映射共享文件的建议似乎是唯一可行的前进方式。 (您可以依赖整个集群访问,例如,NFS 或 SMB 共享吗?您现在可以访问集群吗?)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-10-17
  • 1970-01-01
  • 1970-01-01
  • 2012-10-15
  • 2015-10-13
  • 2013-06-04
相关资源
最近更新 更多