Page 45 - 《软件学报》2026年第6期
P. 45

2364                                                       软件学报  2026  年第  37  卷第  6  期


                                                 表 5 RuyiBuild  编译表现对比

                            类型                x264     SQLite3   GNU GSL       xz      KissFFT   Pixman
                     Clang编译峰值内存 (KB)        141 164   740 512    149 964    500 128   71 812    116 844
                      Clang编译挂钟时间 (s)         57.69    443.20     153.08     41.59      3.05      18.91
                   Clang编译峰值内存 (-flto) (KB)  560 160   826 804    1 302 668  507 772   66 644    242 880
                    Clang编译挂钟时间 (-flto) (s)   154.92   394.27     249.89     49.75      3.14      31.95
                    RuyiBuild编译峰值内存 (KB)     180 052   739 688    250 484    502 884   73 004    116 352
                     RuyiBuild编译挂钟时间 (s)      109.78   628.81     358.96     117.19     6.47      41.42
                      IR→SO峰值内存 (KB)         596 756   739 448    1 380 704  130 976   64 348    280 544
                       IR→SO挂钟时间 (s)          133.65    85.23     160.76     11.00      1.21      31.22

                    比较单纯    Clang  编译和  RuyiBuild  编译可以看到, 整体内存峰值处于同一数量级; RuyiBuild         编译时间约为单
                 纯  Clang  编译的  2  倍左右. 这一差异主要由链接/全程序优化等阶段           (LTO/链接时代码生成) 所致, 属于构建期一次
                 性开销, 不影响交付产物的运行时性能与用户体验, 因此对业务侧“无感”.
                    内存消耗方面, 单纯      Clang 编译与  RuyiBuild 的结果在多数项目中较为接近. x264 在       Clang 编译下最大内存为
                 141 164 KB, 而在  RuyiBuild  中上升至  180 052 KB; GNU GSL  的内存消耗更为明显, 从  Clang  的  149 964 KB  增加
                 到  RuyiBuild  的  250 484 KB. 相比之下, SQLite3  与  xz 的内存消耗峰值差异较小. 综合来看, 内存消耗量均维持在
                 同一数量级.
                    如图  6  和图  7  所示, 比较  IR→SO  转换阶段和使用-flto  选项的   Clang  编译, 不管是时间还是峰值内存占用量,
                 IR→SO  转换均没有超过使用       LTO  选项的  Clang  编译. 同时, x264、SQLite3、GNU GSL、Pixman  的内存峰值占
                 用量均较为接近, 这是因为这些峰值均产生于链接阶段, LTO                  选项会消耗较大内存. 实际上, IR→SO         的转换过程
                 中也使用了    LTO  优化. 使用  RuyiBuild  编译软件所消耗的时间和内存均小于直接使用              Clang  编译的  2.5  倍, 整体
                 编译时间与内存占用量仍处于同一数量级, 且由于编译由服务端完成, 可通过常规工程手段被吸收; 从                                LLVM IR
                 向动态链接库的转换需要消耗一些时间, 其均短于使用                  LTO  选项的  Clang  编译; 从  LLVM IR  向动态链接库的转
                 换需要的内存大致与使用         LTO  选项的  Clang  编译相同, 综合考虑构建期一次性成本与通过             IR  管线带来的产物一
                 致性、可追溯性与跨目标的可重复构建收益, 上述时间与内存开销处于可接受区间.

                    1 600 000
                                               Clang编译             700
                    1 400 000                  Clang LTO编译                                 Clang编译
                    1 200 000                  RuyiBuild编译         600                     Clang LTO编译
                   所需内存 (KB)  1 000 000                           所需时间 (s) 500             IR→SO
                                               IR→SO
                                                                                           RuyiBuild编译
                                                                   400
                     800 000
                                                                   300
                     600 000
                     400 000                                       200
                     200 000                                       100
                         0                                           0
                           x264 SQLite3 GNU GSL  xz  KissFFT Pixman    x264 SQLite3 GNU GSL  xz  KissFFT Pixman
                         图 6    4  种编译方案的内存占用量                         图 7    4  种编译方案的挂钟时间
                  5   总 结

                    随着  RISC-V  指令集架构在学术界与产业界的广泛应用, 其指令集开源以及模块化、可定制的设计理念虽
                 显著推动了芯片领域的创新发展, 但也引发了软件生态的严重碎片化问题, 成为制约                           RISC-V  生态系统扩展的关
                 键挑战. 本文围绕该问题, 系统提出并实现了             RuyiBuild  工具链, 作为面向  RISC-V  平台的软件兼容性感知解决方
                 案. RuyiBuild  以  LLVM IR  作为统一的中间表示形式, 在保持原有构建系统兼容性的前提下, 设计了一种透明化
   40   41   42   43   44   45   46   47   48   49   50