如何解决在与DASK + CFGrib并行的线程中打开文件确实很慢
我一直在使用以下代码构建GRIB文件读取工具。我有异构文件,所以不能使用xarray.open_mfdatasets或类似的东西。
def create_open_delays(file_list: List[str],expected_dataset_count:int) -> List[Delayed]:
"""
This function runs through list of files and creates a
list of delayed open commands.
"""
return [
dask.delayed(cfgrib.open_datasets,nout=expected_dataset_count)(file,backend_kwargs={
"indexpath": ""
},cache=True) for file in file_list
]
在运行代码时,我注意到与完全并行处理(每个dask worker只有1个线程)相比,在并行并行处理中性能降低了10倍。我想这与GIL有关,我猜对任何人都没有真正的惊喜。 dask文档确实将其视为优化机会。拥有如此多的工作人员有一些缺点,因为他们现在的内存有限,要启动所有工作人员会增加额外的开销,更不用说更多的过程通信了。每个任务大约需要10秒钟,因此我不必担心dask.delayed的开销。
我有两个问题:
- 底层CFGrib / Eccodes软件包中有什么可以改善多线程性能的东西吗?根据我的模糊理解,numpy等在基础编译代码中采取步骤来释放GIL?
- 是否可以在dask中利用新的asyncIO python功能? (我不是要任何人都要求立即开发此功能,我只是想知道是否存在或正在开发类似的东西,这是否是一个愚蠢的想法)
谢谢。
解决方法
如果您还没有看过它,我建议您看一下Xarray,至少看看它们如何处理Grib。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。