我在具有 4 个物理 CPU 的 Macbook Pro（即，与 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 的预期加速（edit: see cmets），这大约是我们期望的机器的 4 倍左右4 个 CPU。并且最后的断言语句也执行成功了，证明这两种方法得到了相同的答案，所以尽管警告信息有些奇怪，但我相信上面的代码是一个有效的解决方案。
编辑：一位评论者指出，我的解决方案以及原作者发布的代码 sn-p 都可能使用了错误的方法 time.clock() 来测量执行时间；他建议改用time.time()。我想我也正在接受他的观点。 （进一步深入研究 Python 文档，我仍然不相信即使这个解决方案是 100% 正确的，因为较新版本的 Python 似乎已经弃用 time.clock() 以支持 time.perf_counter() 和 time.process_time()。但不管，我确实同意time.time() 是否绝对是进行此测量的最正确方法，它可能仍然比我以前使用的方法更正确，time.clock()。）
假设评论者的观点是正确的，那么这意味着我认为我测量的大约 4 倍的加速实际上是错误的。
但是，这并不意味着底层代码本身没有正确并行化；相反，这只是意味着在这种情况下并行化实际上并没有帮助；拆分数据并在多个处理器上运行并没有改善任何东西。为什么会这样？其他用户有pointed out，至少在 numpy/scipy 中，一些函数在多个内核上运行，而有些则没有，对于最终用户来说，试图找出哪些是哪些是一个非常具有挑战性的研究项目.
根据这个实验的结果，如果我的解决方案在 Python 中正确实现了并行化，但没有观察到进一步的加速，那么我建议最简单的可能解释是 matplotlib 可能也在“在后台并行化它的一些函数” "，可以这么说，在编译的 C++ 库中，就像 numpy/scipy 已经做的那样。假设是这种情况，那么这个问题的正确答案将是无法再做进一步的事情：如果底层 C++ 库一开始就已经在多个内核上静默运行，那么在 Python 中进一步并行化将没有任何好处。