浅析spack较受关注的场景
Posted 王万林 Ben
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了浅析spack较受关注的场景相关的知识,希望对你有一定的参考价值。
前几天,与技术好友做了一个spack的分享会。收集到了一些比较关注的场景:
spack建议安装在本地还是NFS?
按照自己的公司规模与管理规范来。如是小公司,机器数量不多,计算服务器有本地硬盘,可以用spack将包安装到本地,访问速度更快。反之如果是大公司,拥有性能好的NFS,机器数量多,则将其安装到NFS。
对比于传统的包管理器如yum、apt、pip、conda等,spack它有什么优势?
前者做出的一些相当常见(但值得怀疑)的假设:
- 每个平台上,源码与二进制文件是1:1的关系。有利于重现,不利于性能优化。
- 二进制文件尽可能可移植。大多数发行版是这样做的,同样不利于性能优化。
- 工具链在整个生态系统是相同的。一个编译器、一组运行时库,解释性语言的话没有编译器。
而高性能计算与上述假设相违背:
- 代码通常以源码分发。供应商的库、编译器除外。
- 同一个包,经常会以不同的选项进行构建:开发者间的构建存在很大差异,当机器是新的时候,需要做首次的大量构建。
- 代码被优化适配于处理器与GPU:这可以高效地利用硬件,最高可以带来10-100x的性能提升。
- 很依赖于系统包:需要使用随机器的优化过的库,需要使用主机GPU库与网络。
- 多语言:C, C++, Fortran, Python等,全部都在同一个生态里。
spack可以管理多平台、多版本共存、多种编译选项的同版本包共存。
spack可以管理这么多包,但这些包不在spack服务器里面,那它的依赖是如何解决的?
spack管理的每一个包,都在各自的package.py文件里面,定义好了该包获取的路径与校验码,以及依赖包。但此处定义的依赖包关系则不会指定路径。依赖包的路径,又由对应的依赖包的package.py文件里面定义其获取包的路径。由此递归。
spack可以支持管理哪些包?
以上是关于浅析spack较受关注的场景的主要内容,如果未能解决你的问题,请参考以下文章