python grid函数_Python – matplotlib griddata的多处理器

我在Python 3.4.2中运行了示例代码，具有numpy版本1.9.1和matplotlib版本1.4.2，在具有4个物理CPU的Macbook Pro上(即，与“虚拟”CPU相反，Mac硬件架构也是提供一些用例)：

import numpy as np

import matplotlib.mlab as mlab

import time

import multiprocessing

# This value should be set much larger than nprocs, defined later below

size = 500

Y = np.arange(size)

X = np.arange(size)

x, y = np.meshgrid(X, Y)

u = x * np.sin(5) + y * np.cos(5)

v = x * np.cos(5) + y * np.sin(5)

test = x + y

tic = time.clock()

test_d = mlab.griddata(

x.flatten(), y.flatten(), test.flatten(), x+u, y+v, interp='linear')

toc = time.clock()

print('Single Processor Time={0}'.format(toc-tic))

# Put interpolation points into a single array so that we can slice it easily

xi = x + u

yi = y + v

# My example test machine has 4 physical CPUs

nprocs = 4

jump = int(size/nprocs)

# Enclose the griddata function in a wrapper which will communicate its

# output result back to the calling process via a Queue

def wrapper(x, y, z, xi, yi, q):

test_w = mlab.griddata(x, y, z, xi, yi, interp='linear')

q.put(test_w)

# Measure the elapsed time for multiprocessing separately

ticm = time.clock()

queue, process = [], []

for n in range(nprocs):

queue.append(multiprocessing.Queue())

# Handle the possibility that size is not evenly divisible by nprocs

if n == (nprocs-1):

finalidx = size

else:

finalidx = (n + 1) * jump

# Define the arguments, dividing the interpolation variables into

# nprocs roughly evenly sized slices

argtuple = (x.flatten(), y.flatten(), test.flatten(),

xi[:,(n*jump):finalidx], yi[:,(n*jump):finalidx], queue[-1])

# Create the processes, and launch them

process.append(multiprocessing.Process(target=wrapper, args=argtuple))

process[-1].start()

# Initialize an array to hold the return value, and make sure that it is

# null-valued but of the appropriate size

test_m = np.asarray([[] for s in range(size)])

# Read the individual results back from the queues and concatenate them

# into the return array

for q, p in zip(queue, process):

test_m = np.concatenate((test_m, q.get()), axis=1)

p.join()

tocm = time.clock()

print('Multiprocessing Time={0}'.format(tocm-ticm))

# Check that the result of both methods is actually the same; should raise

# an AssertionError exception if assertion is not True

assert np.all(test_d == test_m)

我得到以下结果：

/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/matplotlib/tri/triangulation.py:110: FutureWarning: comparison to `None` will result in an elementwise object comparison in the future.self._neighbors)

Single Processor Time=8.495998

Multiprocessing Time=2.249938

我不太确定什么是导致triangulation.py的“未来警告”(显然我的版本的matplotlib不喜欢最初提供的问题的输入值)，但不管多处理确实似乎达到所需的加速度为8.50 / 2.25 = 3.8，(编辑：请参阅注释)，大约在4X左右，我们期望具有4个CPU的机器。而最后的断言声明也成功执行，证明这两种方法得到相同的答案，所以尽管有一些微小的警告信息，我相信上面的代码是一个有效的解决方案。

编辑：一位评论家指出，我的解决方案以及原作者发布的代码片段都可能使用错误的方法time.clock()来衡量执行时间;他建议使用time.time()。我想我也来到他的观点。 (进一步挖掘Python文档，我仍然不相信，即使这个解决方案是100％正确的，因为较新版本的Python似乎已经不推荐使用time.clock()，有利于time.perf_counter()和time.process_time().但无论如何，我同意，time.time()绝对是采用这种测量的最正确方法，它仍然可能比我之前使用过的更为正确，time.clock())。

假设评论者的观点是正确的，那意味着我以为我测量的大约4X的加速度其实是错误的。

然而，这并不意味着底层代码本身没有被正确地并行化;相反，这只是意味着并行化在这种情况下并没有实际的帮助;分割数据并在多个处理器上运行并没有改善任何事情。为什么会这样？其他用户有pointed out，至少在numpy / scipy中，一些功能在多个核心上运行，有些不会，最终用户可能是一个严重挑战性的研究项目，试图找出哪些功能是哪一个。

根据这个实验的结果，如果我的解决方案正确地实现了Python内的并行化，但是没有进一步加速，那么我建议最简单的解释是，matplotlib也可能是并行化其“引擎盖”下的一些功能，所以在编译的C库中，就像numpy / scipy已经做的那样。假设是这种情况，那么这个问题的正确答案就是没有什么可以做的：如果基础C库已经在多个内核上静默运行，Python将进一步并行化将不会很好。