Page 34 - 《软件学报》2025年第12期
P. 34

沈莉 等: swJulia: 面向新一代神威超级计算机的         Julia 语言编译系统                               5415


                 种基于   Krylov  空间的算法, 能有效解决线性系统问题、计算特征值、奇异值, 以及处理函数应用于线性映射的问
                 题. 同样, TensorOperations.jl [32] , 这一旨在加速并简化  Julia 语言中高维数组操作的开源包, 也是我们的重要工具.
                 而  LinearAlgebra.jl 则对  swblas 及  swlapack  等众核线性代数库中的常用接口提供了高效封装, 能够轻松应对矩阵
                 计算、高斯消元、LU       分解等多种线性代数问题.
                    在分布式通信方面, 我们采用了          Distributed.jl [33] 和  MPI.jl [34] 两种方式. Distributed.jl 允许我们在独立的内存空
                 间中创建新的进程, 其主从分布式架构使得小规模并行化变得简洁方便. 而                         MPI.jl 则是消息传递接口     (message
                 passing interface, MPI) 协议的  Julia 封装, 并且针对  SW26010Pro  进行了高度优化. 它灵活支持各种    MPI 实现, 并
                 且提供与   C  函数名称几乎相同的接口, 使得通过          Julia 使用  MPI 变得简单易行.
                    为了充分利用      Julia 的高性能和  Python  的丰富生态, 我们还引入了      PyCall.jl [35] 这一核心包. 它允许用户无缝地
                 在  Julia 中调用外部  Python  函数. PyCall.jl 底层依赖于新一代神威超级计算机上的         swPython  解释器, 该解释器为
                 申威处理器提供了包括        AI 框架、数值计算、分布式通信、高性能应用工具等在内的上百个第三方库, 从而满足
                 了人工智能和科学计算的高性能需求. 值得一提的是, PyCall.jl 通过使用                  Cython  编译器生成的    C API 直接与
                 swPython  的动态类型系统交互, 确保了调用        Python  函数时的低延迟和高效率.
                  3.3   高效的文件系统支撑
                    新一代神威超级计算机的计算节点不配备本地存储, 而是依赖基于                       Lustre 的全局文件系统    [36] 提供存储服务.
                 当  NNQS-Transformer 执行时, 每个计算节点需要加载大约        500  个动态库和预编译文件, 总数据量高达约            1 GB. 在
                 大规模并行文件读写的应用场景下, Lustre 的元数据服务器可能成为性能瓶颈.
                    为了解决这个问题, 新一代神威超级计算机同时配备了只读文件系统                       (read-only file system, ROFS). ROFS  在
                 多个  SSD  存储服务节点上创建虚拟块设备, 并将应用的动态库和预编译文件等复制到这些虚拟设备中. 随后, 这
                 些虚拟块设备通过网络以只读模式输出到计算节点. 当程序执行时, 应用会从这些远程虚拟块设备中加载所需的
                 可执行程序、动态库和预编译文件.
                    值得一提的是, Julia 编译器支持“方法年龄”的概念, 这使得动态方法能够重新定义. 每当源代码片段被编辑
                 时, 其“年龄”就会发生变化, 进而触发预编译机制以生成新的预编译文件. 在将数据复制到虚拟块设备之前, 我们
                 首先在基于    Lustre 的可读写块设备中完成预编译操作. 随后, 将           ROFS  的虚拟块设备挂载到相同路径, 从而有效避
                 免了在   ROFS  中执行写操作的问题.
                    在新一代神威超级计算机上, 我们配置了              600  个数据服务器作为虚拟块的        Target 端, 同时约有  9  万个计算节
                 点作为   Host 端. 这些  Host 端通过哈希方式映射到这       600  个  Target 端上. 根据实际测试数据, 采用    ROFS  后, 整机
                 规模的动态库和预编译文件加载时间从原本的                22 min  显著缩短至约   3 min.

                  4   实验与分析

                  4.1   实验环境与测试用例
                    本文以新一代神威超级计算机为实验平台, 借助前端机的作业管理系统, 将可执行文件提交至                               SW26010Pro
                 计算节点运行. 实验中采用的          swJulia  编译器基于  Julia 1.8.1  开源版本进行移植, 并依托于     swLLVM 18.0.1  的
                 ORCJIT  引擎构建而成. 同时, SW26010Pro   的原生编译器采用       swGCC 7.1.0  版本, 其底层汇编器、链接器等二进
                 制工具链版本为      2.24, GLIBC  基础库的版本为   2.23.
                    Micro-Benchmarks [37] 是一套用于测试  Julia 编译器性能的基准测试集, 它涵盖了多种常见的代码模式, 如函数
                 调用、字符串解析、排序、数值循环、随机数生成、递归和数组操作等. 在该测试集中, 测试课题被设计为使用
                 不同编程语言实现相同的算法模式, 并在相同的软件环境和硬件条件下执行, 以确保测试的公平性. 本文使用
                 Micro-Benchmarks 对比了  Julia 语言相对于其他编程语言的性能, 并将测试结果以             C  语言实现为基准进行归一化
                 处理, 以验证   swJulia 编译器在解决“两种语言”问题上的有效性.
                    本文采用    Rodinia [38] 测试集以全面评估  swJulia 在众核加速及运行时开销等方面的表现. Rodinia 是针对并行
   29   30   31   32   33   34   35   36   37   38   39