Warning: file_get_contents(/data/phpspider/zhask/data//catemap/2/python/346.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
并行化python代码中的内存共享_Python_Matrix_Parallel Processing_Pass By Reference_Shared Memory - Fatal编程技术网

并行化python代码中的内存共享

并行化python代码中的内存共享,python,matrix,parallel-processing,pass-by-reference,shared-memory,Python,Matrix,Parallel Processing,Pass By Reference,Shared Memory,我是一名大学新生和Python新手,所以请容忍我。我正在尝试将一些矩阵运算并行化。下面是我使用ParallelPython模块的尝试: def testfunc(connectionMatrix, qCount, iCount, Htry, tStepCount): test = connectionMatrix[0:qCount,0:iCount].dot(Htry[tStepCount-1, 0:iCount]) return test f1

我是一名大学新生和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%似乎达到了极限。矩阵越小,增加越少,矩阵越小,串行代码速度越快。我的猜测是,问题在于论点的传递。复制大型矩阵的开销实际上要比作业本身花费更长的时间。我能做些什么来避开这件事?是否有某种方法可以合并内存共享和通过引用传递矩阵?如您所见,没有修改任何参数,因此它可以是只读访问


谢谢。

好吧,ParallelPython的要点是,您可以编写代码,而不管它是否分布在线程、进程甚至多台计算机上,而使用内存共享将打破这种抽象

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

如果您愿意放弃分布式处理选项,可以使用multiprocessing.Array(或multiprocessing.Value或multiprocessing.sharedTypes)访问共享内存。但是在这一点上,您可能想考虑只使用多处理而不是并行Python来进行作业分配,因为多重处理是标准库的一部分,并且具有更强大的API,并且您明确地放弃了并行Python的一个主要优点。 或者,您可以将这两个选项结合起来,在许多方面都是最糟糕的,但就您对现有代码的更改而言,可能是最好的:只需使用一个本地文件并对其进行mmap


但是,在你做这些之前,你可能想考虑剖析,看看复制矩阵是否真的是瓶颈。如果是的话,你可能想考虑是否有算法修复,只是复制每个工作所需的部分而不是复制整个矩阵。(当然,这是否有意义取决于每个作业所需的部分是否明显少于整个作业。)

好的,ParallelPython的要点是,您可以编写代码,而不管它是否分布在线程、进程甚至多台计算机上,使用内存共享将打破这种抽象

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

如果您愿意放弃分布式处理选项,可以使用multiprocessing.Array(或multiprocessing.Value或multiprocessing.sharedTypes)访问共享内存。但是在这一点上,您可能想考虑只使用多处理而不是并行Python来进行作业分配,因为多重处理是标准库的一部分,并且具有更强大的API,并且您明确地放弃了并行Python的一个主要优点。 或者,您可以将这两个选项结合起来,在许多方面都是最糟糕的,但就您对现有代码的更改而言,可能是最好的:只需使用一个本地文件并对其进行mmap


但是,在你做这些之前,你可能想考虑剖析,看看复制矩阵是否真的是瓶颈。如果是的话,你可能想考虑是否有算法修复,只是复制每个工作所需的部分而不是复制整个矩阵。(当然,这是否有意义取决于每个作业所需的部分是否明显少于整个作业。)

老实说,我不完全确定复制是否是减速,但在分析时,
{method'acquire'of'thread.lock'objects}
{cPickle.dumps}
运行整个脚本需要66%的时间。我以为这是酸洗,然后是复印。我暑期项目的最终目标是利用一组机器,这样多处理模块就不能工作了。至于只复制某些部分,我可以尝试重写矩阵操作,使其只处理小块,然后重新组合它们。这就是你的意思吗?嗯,锁可能与复制无关,但cPickle.dumps几乎肯定与复制有关。您可以通过在生成子对象之前手动酸洗矩阵,然后共享酸洗(并在子对象中手动取消酸洗)来节省时间。或者提出比普通酸洗更快和/或更紧凑的表示法。但首先……你确定这是整个过程的66%,还是在父进程本身中的66%(可能很少做实际工作)?最后,是的,如果可能的话,我的意思是重写操作来处理小块。哦,如果最终目标是使用集群,除非它有某种形式的集群内存共享(可以从Python访问),那么在最终版本中显然无法使用共享内存,所以我不会在这个初步版本中使用它。共享文件系统加上mmap可能是值得的,但如果不在集群上实际使用它,可能很难进行性能测试。它们肯定占用了66%的时间。包含我最初发布的代码的方法需要脚本运行525秒中的522秒。该方法在一个for循环中,该循环在一个不断变化的矩阵上运行。重写矩阵运算的唯一问题是,例如,在乘法运算中,每行都要乘以b