基本上，我有一个大型对象，我想在其上执行一些功能，它非常适合并行处理。在这个例子中，我有一个大矩阵，我想计算列向量之间的所有成对内积。
请看下面IPython Notebook。
我意识到 @interactive 装饰器在这种情况下不是必需的，我尝试删除 @require 装饰器，但它的影响可以忽略不计。
我的问题是：有什么方法可以提高并行机器的性能吗？
我不知道map 方法的实现细节，我可以通过推送与视图中的引擎并行执行的函数来避免开销吗？不过，我无法想象它会随每个参数一起发送。
我自己将参数列表分块并编写一个远程使用的函数似乎也很愚蠢。
我在四核机器上试用了笔记本，笔记本中的结果是两核机器。
【问题讨论】：
标签： parallel-processing ipython
这里的主要性能问题是您应用的 fortran 连续优化无法通过网络传输，因此引擎上的 mat 是 C 连续的，而不是 push 之后的 F 连续的。
你可以看到这个：
print mat.flags
%px print mat.flags
添加：
%px mat = numpy.asfortranarray(mat)
应该让你的表现恢复（如我的笔记本中的tweaked version 所示）。
为了诊断这个问题，我尽我所能找出瓶颈所在。对此有用的是AsyncResult.serial_time 和AsyncResult.wall_time。当serial_time 很长时，这意味着任务实际上需要很长时间在引擎上，而不是在 IPython 管道中花费大量时间。这让我认为任务本身在引擎上很慢，所以我在一个引擎上远程完成了任务，
而且它仍然很慢（不涉及并行）。这是a notebook 跟踪问题。
旁注：
@interactive 装饰器仅对交互定义的函数（即模块函数，而不是笔记本中定义的函数）是必需的，因此它在你的笔记本中是多余的。
【讨论】：
ascontiguousarray，它实际上最终将 F 连续数组强制转换为 C 连续数组，尽管它可能不需要（它可能有时，取决于切片）。我将研究 F-contiguous 数组的零拷贝发送会涉及什么以避免这种奇怪的情况。