如果我在工作节点之间预先分散一个数据对象,它是否会被完整地复制到每个工作节点?如果该数据对象很大,这样做是否有优势?
使用 futures
以界面为例:
client.scatter(data, broadcast=True)
results = dict()
for i in tqdm_notebook(range(replicates)):
results[i] = client.submit(nn_train_func, data, **params)
使用
delayed
以界面为例:client.scatter(data, broadcast=True)
results = dict()
for i in tqdm_notebook(range(replicates)):
results[i] = delayed(nn_train_func, data, **params)
我之所以这么问,是因为我注意到了以下现象:
delayed
似乎将数据重新发送到工作节点,因此内存使用量大约增加了一倍。看起来预分散没有做我期望它做的事情,这允许工作节点引用预分散数据。 futures
interface 需要很长时间才能遍历循环(明显更长)。我目前不确定如何确定这里的瓶颈在哪里。 delayed
界面,从时间compute()
函数被调用到事件反射(reflect)在仪表板上的时间,有一个广泛的延迟,我怀疑是由于数据复制。 最佳答案
预分散旨在避免将大对象数据放入任务图中。
x = np.array(lots_of_data)
a = client.submit(add, x, 1) # have to send all of x to the scheduler
b = client.submit(add, x, 2) # again
c = client.submit(add, x, 3) # and again
你会感受到这种痛苦,因为
client.submit
返回会很慢,Dask 甚至可能会抛出警告。所以相反,我们分散我们的数据,得到一个 future 的返回
x = np.array(lots_of_data)
x_future = client.scatter(x)
a = client.submit(add, x_future, 1) # Only have to send the future/pointer
b = client.submit(add, x_future, 2) # so this is fast
c = client.submit(add, x_future, 3) # and this
在您的情况下,您几乎要这样做,唯一的区别是您分散数据,然后忘记它返回的 future ,然后再次发送数据。
client.scatter(data, broadcast=True) # whoops! forgot to capture the output
data = client.scatter(data, broadcast=True) # data is now a future pointing to its remote value
您可以选择
broadcast
或不。如果您知道您的所有员工都需要这些数据,那么这样做并不是一件坏事,但无论如何一切都会好起来的。
关于python - 在 Dask 中预先分散数据对象是否有优势?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52997229/