高性能计算科学计算【免费下载链接】OpenBLASOpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version.项目地址https://gitcode.com/gh_mirrors/op/OpenBLAS点击查看免费下载OpenBLAS 的 CI 体系覆盖 x86_64、arm64、Power、z/Architecturezarch与多种 RISC 系架构横跨 Windows、macOS、Linux、FreeBSD 与 Android/iOS 等目标平台并同时验证 GNU make 与 CMake 两套构建系统、多组 C/Fortran 编译器以及 pthreads/OpenMP/单线程等线程模型。本文以仓库 docs/ci.md 的 CI 作业矩阵为骨架结合 azure-pipelines.yml、appveyor.yml 与.github/workflows/下的真实流水线定义逐项讲解矩阵中每个维度架构、编译器、构建系统、线程模型、库类型、CI 提供方的含义、背后的构建选项Makefile.rule以及跨架构验证是如何通过交叉编译、QEMU 模拟和 Docker 容器落地的。读完本文你将能读懂 OpenBLAS 的 CI 矩阵表理解 DYNAMIC_ARCH、INTERFACE64、USE_OPENMP 等核心开关在 CI 场景中的用途并能在自己的仓库中复刻出类似的跨平台构建测试矩阵。一、CI 矩阵总览一张表看懂 OpenBLAS 的测试覆盖面OpenBLAS 是一个面向多架构、多操作系统的高性能 BLAS 实现其内核代码为每种 CPU 微架构分别提供经过手工优化的汇编/内建实现见 kernel/x86_64、kernel/arm64、kernel/power 等目录因此它的 CI 必须回答一个核心问题在无法购买/租用每一种硬件的情况下如何保证每个架构组合上的代码依然可构建、可运行、结果正确。文档 docs/ci.md 用一张CI jobs矩阵表记录了当时正在运行的持续集成作业每一行代表一个独立的 CI 作业job列则代表该作业的维度。把这张表拆解开来可以得到 OpenBLAS CI 的九个观察维度维度取值示例说明Arch宿主机架构x86_64、arm64、power、zarch运行 CI 的宿主 CPU 架构Target CPU目标 CPUIntel、Haswell、SkylakeX、Neoverse N1、Graviton3、pwr9、z14、I6400、P6600 等编译时通过TARGET指定的目标微架构OSWindows、CentOS5、Ubuntu、macOS11/12/14/26、Alpine Linux(musl)、FreeBSD、QEMU构建与测试运行的操作系统Build systemCMAKE、gmake、mingw32-make、CMAKE/Ninja、CMAKE/VS2015、CMAKE/VS2017两套构建体系GNU make 与 CMakeXComp to交叉编译目标-无、arm、arm64、mips64、mips32、riscv64、ia64、x86_64宿主架构与目标架构不一致时的交叉编译目标C Compilermingw6.3、gcc 4.8、gcc、VS2017、LLVM、gcc-10、gcc-12、AppleClang 14、gcc15 等C 编译器及其版本Fortran Compiler-无NOFORTRAN、gfortran、flang、ifort、flang*Fortran 编译器-表示该作业禁用 FortranNOFORTRAN1threadingpthreads、OpenMP、none、空线程模型pthreads 内部线程、OpenMP、或单线程DYN_ARCH、-、list、no_avx512是否启用 DYNAMIC_ARCH 多架构支持list表示配合 DYNAMIC_LIST 指定子集INT64-、是否启用 64 位整数接口INTERFACE641即 ILP64Librariesstatic、shared、both构建静态库、共享库或两者都构建CI ProviderAppveyor、Azure、Github、OSUOSL实际运行 CI 的平台1.1 矩阵里的三种 CI Provider 分工从表中可以看到 OpenBLAS 的 CI 分布在三个提供方上这与仓库根目录下的三个 CI 配置文件一一对应Appveyorappveyor.yml负责最早的 Windows 作业使用 Visual Studio 2015 工作镜像 MinGW gcc 5.3/6.3 编译器走 CMake ctestAzure Pipelinesazure-pipelines.yml负责大部分 Linux/macOS/Windows 作业包括 manylinux Docker 构建、Intel SDE 模拟 AVX-512、OS X 上的 GCC/Clang/ifort/flang 组合、Android NDK 与 iOS 交叉编译、Alpine musl 测试GitHub Actions.github/workflows负责后续新增的 arm64Apple M1 / Neoverse / Graviton3、FreeBSD、以及 MIPS64/RISC-V/LoongArch 的 QEMU 交叉测试OSUOSLOSU Open Source Lab表末两行 Power9pwr9与 z14 的作业直接跑在 IBM Power 与 z/Architecture 的真实硬件上这两行由仓库外的独立配置驱动表中以power与zarch标注。1.2 为什么需要如此多的维度组合BLAS 库的性能与正确性高度依赖 CPU 微架构特性。OpenBLAS 通过TARGET选择为特定微架构优化的内核如 SKYLAKEX、HASWELL、NEHALEM、CORE2、ARMV8、NEOVERSEN1、I6400、P6600、LOONGSON3R5、C910V、pwr9、z14 等通过DYNAMIC_ARCH1把多个目标内核打包进同一个二进制运行时用 cpuid 检测机器并分发到对应内核。CI 矩阵必须保证每个受支持架构既有针对具体微架构的构建验证也有通用二进制DYNAMIC_ARCH的构建验证既有本机原生构建也有通过交叉编译 QEMU 用户态模拟的验证因为 CI 宿主机主要是 x86_64 与 arm64无法原生运行 MIPS/RISC-V/LoongArch 代码。二、CI 中反复出现的核心构建选项从 Makefile 到 CMake矩阵表中的 DYN_ARCH、INT64、threading、Libraries 等列对应的是 OpenBLAS 构建系统Makefile.rule 与 cmake中一组核心开关。理解这些开关是读懂 CI 矩阵的前提。2.1 TARGET为目标微架构定制内核TARGET指定编译目标 CPU。文档矩阵中出现的TARGETCORE2、TARGETNEHALEM、TARGETARMV8、TARGETARMV7、TARGETMIPS64_GENERIC、TARGETSICORTEX、TARGETI6400、TARGETP6600、TARGETI6500、TARGETRISCV64_GENERIC、TARGETC910V、TARGETLOONGSONGENERIC、TARGETLA464、TARGETLA264等分别对应 kernel 下各架构目录中以.generic、.I6400、.P6600、.C910V、.LA464等为后缀的内核变体文件。不指定TARGET时构建系统会自动探测宿主机 CPU如 Makefile.rule 注释所述You can specify the target architecture, otherwise its automatically detected。实战要点交叉编译时必须显式给出TARGET因为宿主机探测到的架构与目标架构不一致。例如 CI 中所有 mips64/riscv64/loongarch64 作业都显式传入了TARGET。2.2 DYNAMIC_ARCH 与 DYNAMIC_LIST一个二进制跑遍多代 CPUDYNAMIC_ARCH1对应 CMake 的-DDYNAMIC_ARCHON会把多个目标 CPU 的内核打包进同一个库运行时根据 cpuid 结果选择最优内核。矩阵中 DYN_ARCH 列取值为-关闭动态架构编译为单一目标如 CentOS5 gcc 4.8 作业、SDE SkylakeX 作业开启全部架构都包含如 macOS11 gcc-10 OpenMP 作业、Apple M1 系列作业、Graviton3 作业list开启但只打包指定子集通过DYNAMIC_LISTSANDYBRIDGE或DYNAMIC_LISTNEHALEM HASWELL SKYLAKEX指定azure-pipelines.yml 的 Windows_mingw_gmake 作业、OSX_OpenMP_Clang 作业no_avx512开启但排除 AVX-512 内核macOS11 CMAKE llvm OpenMP 作业即配合-DNO_AVX5121原因是当时部分 macOS 机器/编译器对 AVX-512 支持不完善。从 Makefile.rule 可以看到DYNAMIC_ARCH 模式下还可以追加DYNAMIC_OLDER 1来把 PENRYN、DUNNINGTON、OPTERON、OPTERON_SSE3、ATOM、NANO 等更老架构也纳入动态列表。CI 矩阵中DYNAMIC_LIST常配合TARGETCORE2使用即以 CORE2 为基线动态附加新架构这是 OpenBLAS 官方推荐的稳健配置性能与兼容性兼顾。2.3 INTERFACE64ILP64 与 LP64 双接口矩阵中的 INT64 列对应INTERFACE641CMake 为-DINTERFACE641。默认 OpenBLAS 采用 LP64 接口int为 32 位INTERFACE641时所有 BLAS/LAPACK 接口改用 64 位整数int64_t便于处理超过 2^31 个元素的大规模问题。CI 中该开关的覆盖集中在 Apple M1 作业.github/workflows/apple_m.yml 矩阵中ilp64: [0, 1]即 LP64 与 ILP64 各跑一遍、msys2 作业idx: [int32, int64]与部分 Windows 作业确保两种 ABI 都能通过make -C test/ctest测试。2.4 threadingpthreads / OpenMP / 单线程矩阵的 threading 列取值有 pthreads、OpenMP、none单线程pthreadsOpenBLAS 默认的多线程后端USE_THREAD1内部自管理线程池OpenMPUSE_OPENMP1改用 OpenMP 运行时Makefile.rule 特别提醒POWER8 目标必须设置 USE_OPENMP1不能设 0这也是矩阵中 pwr9、z14 作业均使用 OpenMP 的原因之一none / 空USE_THREAD0的单线程构建如 OSX_GCC_Nothreads 作业make USE_THREADS0 CCgcc-13 FCgfortran-13。CI 之所以要把三种线程模型都覆盖一遍是因为它们走完全不同的线程调度代码路径driver/level3 下的多线程驱动与 common_thread.h 的线程抽象任何一条路径的回归都必须在多个平台上被捕获。2.5 Librariesstatic / shared / both矩阵 Libraries 列区分静态库static、共享库shared与两者都建both。构建选项上NO_STATIC1跳过静态库、NO_SHARED1跳过共享库Makefile.ruleCMake 则用-DBUILD_SHARED_LIBSON/OFF与-DBUILD_STATIC_LIBS控制。多数跨平台作业选择both以同时验证libopenblas.a与libopenblas.so/.dylib/.dll的生成部分 Windows/静态场景如 VS2015、VS2017、Ninja LLVM 作业只验证 static因为 Windows 上共享库需要处理符号导出见 exports 目录与 exports.h。2.6 NOFORTRAN 与 Fortran 编译器列矩阵中 Fortran Compiler 为-的作业如 Windows mingw、LLVM、部分交叉编译作业代表NOFORTRAN1构建——OpenBLAS 核心是 C 代码可以完全脱离 Fortran 编译此时不包含需要 Fortran 的参考 LAPACK 路径。其余作业分别使用 gfortranGNU、flangLLVM 生态的 Fortran、ifort/ifxIntel、VS 自带 Fortran 等用于编译 LAPACK 参考实现lapack-netlib与测试程序。flang 作业如 Windows_flang_clang、Windows_cl_flang、OSX_LLVM_flangnew专门验证 LLVM 工具链全链路clang C flang Fortran能否完整构建并跑通 ctest。三、按平台拆解 CI 作业Windows / macOS / Linux / FreeBSD / 交叉编译3.1 Windows四套工具链并行验证Windows 是 OpenBLAS 发行版的重要平台CI 为此覆盖了四类工具链MSVCclWindows_cl作业azure-pipelines.yml用cmake -G Visual Studio 17 2022生成 VS 工程构建 Release 后直接运行openblas_utest.exe早期版本appveyor.yml 时代用Visual Studio 15 2017 Win64。由于 MSVC 无 Fortran这类作业走 NOFORTRAN 路径MinGW gccWindows_mingw_gmake作业用mingw32-make CCgcc NOLAPACK1 DYNAMIC_ARCH1 DYNAMIC_LISTSANDYBRIDGE专门验证 Windows 下的 GNU make 构建路径appveyor.yml 中还有 MinGW-gcc-5.3.032 位与 MinGW-gcc-6.3.0-32 的 CMake MSYS Makefiles 构建clang-cl NinjaWindows_clang_cmake作业azure-pipelines.yml在 conda 中安装 ninja 后用cmake -G Ninja -DCMAKE_C_COMPILERclang-cl ... -DNOFORTRAN1 -DMSVC_STATIC_CRTON构建并ctestMSYS2 矩阵.github/workflows/dynamic_arch.yml 中的 msys2 作业进一步按msystem: [UCRT64, MINGW32, CLANG64]×idx: [int32, int64]展开覆盖 UCRT/MinGW/Clang 三套 MSYS2 环境与 LP64/ILP64 两种接口CMake 配置为-DBUILD_SHARED_LIBSON -DBUILD_STATIC_LIBSON -DDYNAMIC_ARCHON -DUSE_THREADON -DNUM_THREADS64 -DTARGETCORE2。这些作业共同保证了无论用户用 VS 工程、MinGW Makefiles 还是 Ninja 构建无论有没有 FortranWindows 上都能得到可用的 OpenBLAS。3.2 macOSGCC / LLVM / ifort 与 Apple SiliconmacOS 作业在矩阵中占据了大量行按其关注点可分为线程模型矩阵OSX_OpenMPmake TARGETCORE2 DYNAMIC_ARCH1 USE_OPENMP1 INTERFACE641 CCgcc-13 FCgfortran-13并执行 install 验证头文件/库的安装布局、OSX_GCC_NothreadsUSE_THREADS0单线程、OSX_OpenMP_Clangllvm clang libompDYNAMIC_LISTNEHALEM HASWELL SKYLAKEXNOFORTRAN1、OSX_dynarch_cmakeCMake -DDYNAMIC_LISTNEHALEM;HASWELL;SKYLAKEX 共享库等Fortran 编译器多样性gfortrangcc-10/12/13/15、ifortIntel HPCKit通过MACOS_HPCKIT_URL下载安装见 azure-pipelines.yml、flang-newOSX_LLVM_flangnew用FC/usr/local/opt/flang/bin/flang构建;Apple M1 原生矩阵.github/workflows/apple_m.yml 在macos-14上以build: [cmake, make]×openmp: [0, 1]×ilp64: [0, 1]展开 8 个组合即make 与 CMake 两套构建 × 是否 OpenMP × 是否 ILP64并在构建后依次执行make -C test、make -C ctest、make -C utest三组测试CMake 路径则运行ctest。这就是 docs/ci.md 中 Apple M1 macOS14 那 8 行作业pthreads/OpenMP × LP64/ILP64 × gmake/CMAKEx86_64 交叉构建xbuild-x86_64作业在macos-26Apple Silicon 宿主上用 Xcode 26 SDK 的 clang 以-arch x86_64交叉编译验证 macOS 上的 x86_64 构建不被破坏。3.3 Linuxglibc、musl 与老工具链Linux 侧除了常规的 Ubuntu 作业外有两类特殊验证值得注意老 glibc / 老工具链manylinux1_gcc作业azure-pipelines.yml在 quay.io/pypa/manylinux1_x86_64 容器里用make QUIET_MAKE1 BINARY64 DYNAMIC_ARCH1 TARGETNEHALEM NUM_THREADS32构建并跑 test/ctest/utest——正如其注释所说该容器的 gcc/glibc 版本很老能提前暴露新代码对老环境的兼容性问题manylinux_32bit作业在 manylinux2014_i686 容器里验证BINARY3232 位构建注意 Makefile.rule 提示 32 位下禁用 AVX/AVX2/AVX-512。矩阵中 CentOS5 gcc 4.8 的 Azure 作业也是同一目的musl libcALPINE_MUSL作业azure-pipelines.yml通过 alpine-chroot-install 进入 Alpine 环境执行make DYNAMIC_ARCH1 BINARY64构建后还额外验证安装的头文件openblas_config.h能在 musl 环境下被正常 include 编译——矩阵中对应的就是 Alpine Linux(musl) pthreads DYN_ARCH 那一行Intel SDE 模拟 AVX-512Intel_SDE_skx作业azure-pipelines.yml先构建 DYNAMIC_ARCH 库再用 Intel SDE 的sde64 -cpuid_in .../skx/cpuid.def在 SkylakeX 的 CPUID 特征下运行 utest——它用 CPU 指令集模拟器补足了CI 宿主机没有 AVX-512 硬件的缺口对应矩阵中的 SDE (SkylakeX) 行。3.4 FreeBSD两大架构的原生验证.github/workflows/freebsd.yml 通过vmactions/freebsd-vmaction 在真实 FreeBSD 虚拟机里执行gmake CCgcc15 FCgfortran15同时覆盖 x86_64bsd-x86与 aarch64bsd-aarch64指定arch: aarch64两个架构对应矩阵末尾 FreeBSD 的两行。注意 BSD 下必须用gmakeGNU make因为 BSD 自带的 make 不兼容 OpenBLAS 的 Makefile 语法。3.5 交叉编译与 QEMU 用户态模拟覆盖无硬件架构CI 宿主机只有 x86_64 / arm64但 OpenBLAS 支持的架构远不止这些。矩阵中的 XComp to 列揭示了解决方案在 x86_64 上用交叉编译器 QEMU 用户态模拟器运行测试。以 .github/workflows/mips64.yml 为例作业流程是安装交叉工具链gcc-mips64el-linux-gnuabi64、gfortran-mips64el-linux-gnuabi64r6 目标用gcc-mipsisa64r6el-linux-gnuabi64从 qemu 源码编译mips64el-linux-user用户态模拟器交叉构建 OpenBLASmake CCccache mips64el-linux-gnuabi64-gcc -static FCccache mips64el-linux-gnuabi64-gfortran -static NO_SHARED1 TARGETMIPS64_GENERIC HOSTCCccache gcc——关键点是静态链接-static与HOSTCC 指向本机 gccMakefile.rule 要求交叉编译时必须设置宿主编译器用qemu-mips64el ./utest/openblas_utest等命令在模拟器中运行全部测试utest、ctest 的 cblat1/2/3 系列以OPENBLAS_NUM_THREADS2传入以同时验证多线程路径以及 test 目录的 sblat1/2/3、dblat1/2/3、cblat1/2/3、zblat1/2/3用.dat输入文件驱动。同一模式还用于RISC-Vc910v.yml同时验证RISCV64_GENERIC与玄铁 C910Vkernel/riscv64 下的.C910V目标后者需下载玄铁官方工具链Xuantie-900-gcc-linux-...并使用 XUANTIE-RV/qemu 补丁后的模拟器由于 C910V 模拟较慢作业中还封装了run_with_retry超时重试逻辑LoongArch.github/workflows/loongarch64.yml 覆盖 LOONGSONGENERIC、LOONGSON3R5、LOONGSON2K1000、LA64_GENERIC、LA464、LA264 与 DYNAMIC_ARCHTARGETGENERIC共 7 个目标使用 Ubuntu 仓库的gcc-14-loongarch64-linux-gnu与qemu-user10.2.1Android/iOS矩阵中 macOS 宿主上的 arm/arm64 交叉行对应 azure-pipelines.yml 的 OSX_NDK_ARMV7Android NDK 的armv7a-linux-androideabi21-clang、OSX_IOS_ARMV8 / OSX_IOS_ARMV7Xcode iOS SDK-arch arm64/armv7以及 apple_m.yml 中的 xbuild-ios 系列作业——它们都是make TARGETARMV8/ARMV7 ... HOSTCCclang NOFORTRAN1的交叉构建仅验证能编出正确的库不做运行时测试无模拟器ia64、mips32矩阵中的 ia64、mips32 行同样由 x86_64 宿主交叉编译验证gmake 对应 GNU 交叉工具链。四、CI 的通用工程实践ccache、测试分层与流水线组织OpenBLAS 的 CI 配置中凝结了一套可复用的构建测试工程实践值得在阅读矩阵表之余留意。4.1 ccache 编译缓存几乎所有 GitHub Actions 作业都配置了 ccache见 .github/workflows/dynamic_arch.yml缓存键包含 runner.os / runner.arch / 构建系统 / 编译器 / Fortran 编译器 / 分支 / commit sha并特意区分 make 与 cmakeGNU make and cmake call the compilers differently ... Keep the ccache for both build tools separate避免两套构建系统互相污染缓存同时把max_size 300M、compression true写入 ccache.conf以适配 GitHub 5GB 缓存配额。Appveyor 时代则用clone_depth: 5、skip_tags: true、[av skip]提交信息跳过机制appveyor.yml来降低 CI 成本。4.2 三层测试体系矩阵表中所有能运行测试的作业都会执行以下三层测试这也是 OpenBLAS 回归保护的核心utestutestC 语言单元测试openblas_utest/openblas_utest_ext覆盖 amax/amin/axpby/axpy/dnrm2/dotu/gemv/rot/rotmg/swap/zscal 等 BLAS 例程及 fork 后行为test_fork、test_post_fork等边界场景ctestctestCBLAS 一致性测试即xscblat1..3、xdcblat1..3、xccblat1..3、xzcblat1..3输入文件为 sin2/din2/cin2/zin2、sin3/din3/cin3/zin3验证 C 接口与 Fortran 参考实现逐元素一致testtestBLAS 测试程序 sblat1/2/3、dblat1/2/3、cblat1/2/3、zblat1/2/3以.dat驱动验证 Fortran 接口正确性。多线程路径由OPENBLAS_NUM_THREADS2或 OMP_NUM_THREADS环境变量在运行测试时激活例如 mips64 作业中同一条目分别以线程数 1 与 2 各跑一遍。此外还有专门的线程压力测试dynamic_arch.yml 的linux_thread_stress/msys2_thread_stress作业用 cpp_thread_test 下的 dgemm/dgemv 多线程程序配合 ctest 过滤条件ctest -R dgemm_thread_safety|...运行tsan 后端还用 clang 的-fsanitizethread Archerlibarcher.so对 OpenMP 场景做数据竞争检测。4.3 触发器与路径过滤各 CI 配置文件对触发时机做了精细控制Azure 流水线只在develop分支的 push 和 PR 上触发并排除docs/**与**/*.md路径文档变更不触发构建GitHub Actions 的 workflow 同样使用paths-ignore: docs/**与concurrency: cancel-in-progress: true同一分支新提交自动取消旧构建appveyor.yml 则通过[av skip]提交信息让开发者主动跳过。所有 workflow 还带fail-fast: false保证矩阵中某个组合失败不会取消其余组合的验证结果。五、如何把 docs/ci.md 的矩阵当作 OpenBLAS 的支持矩阵来读由于 CI 矩阵的每一行都代表当前 CI 确实在验证的配置组合这张表实际上比任何支持平台列表都更准确地反映了 OpenBLAS 的质量保障范围。阅读和使用它的建议先看 Provider 列Appveyor/Azure 行对应 appveyor.yml 与 azure-pipelines.ymlGithub 行对应 .github/workflows 下的具体 workflow 文件OSUOSL 行对应真实的 Power/z 硬件验证——需要复现某个作业时直接打开对应文件查看完整命令关注 DYN_ARCH 与 INT64 的组合这两列直接决定产物的 ABI 与内核覆盖范围。分发场景如 conda-forge、系统包通常选择DYN_ARCH 的通用二进制需要超大矩阵计算的应用则应确认目标发行版是否覆盖INT64 的组合判断你的环境是否被覆盖如果你的部署环境是宿主 x86_64 muslAlpine 容器Apple Silicon OpenMPARM 服务器 ILP64等都能在矩阵中找到对应行意味着该组合持续被 CI 保护理解交叉编译行的边界XComp to 非空的行只验证构建产物正确生成而 QEMU 行mips64/riscv64/loongarch64还能在用户态模拟器里跑完整的三层测试Android/iOS 行则只保证交叉编译成功不包含运行时测试——如果你要为这些平台做深度测试需要自行准备真机或模拟环境。六、结语OpenBLAS 的 CI 矩阵docs/ci.md是一份用一行一行作业说话的跨平台工程记录它同时验证两套构建系统GNU make / CMake、四类以上 C 编译器GCC / clang / MSVC / MinGW、三类 Fortran 编译器gfortran / flang / ifort、三种线程模型pthreads / OpenMP / 单线程、两种 ABILP64 / ILP64、多种库产物形态static / shared / both并通过 Docker 老环境、Intel SDE、QEMU 用户态模拟、OSUOSL 真机等方式把覆盖面延伸到 CI 硬件之外。对于想要为自己的高性能数值库搭建 CI 的开发者这套矩阵及其背后的流水线定义azure-pipelines.yml、.github/workflows本身就是一份可参照的范本用最少的硬件验证最多的架构组合。提示本仓库的 CI 配置会随版本迭代调整阅读 docs/ci.md 时建议结合当时仓库根目录下的 appveyor.yml、azure-pipelines.yml、Jenkinsfile 与.github/workflows/目录如 apple_m.yml、dynamic_arch.yml、mips64.yml、c910v.yml、loongarch64.yml、freebsd.yml、arm64_graviton.yml一并核对这些文件才是每个作业的权威定义。赞分享高性能计算科学计算【免费下载链接】OpenBLASOpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version.项目地址https://gitcode.com/gh_mirrors/op/OpenBLAS点击查看免费下载相关推荐RVC WebUI入门指南用10分钟素材训练自己的AI语音克隆模型RVC WebUI入门指南用10分钟素材训练自己的AI语音克隆模型 RVC WebUIRetrieval based Voice Conversion We人工智能AI 应用语音音频深度学习Slang CI 深度解析LLVM 构建缓存、sccache 与跨平台构建测试矩阵Slang CI 深度解析LLVM 构建缓存、sccache 与跨平台构建测试矩阵 本文以仓库中的 docs/ci.md https://link.gitco编译器图形学编程语言Nushell 平台支持策略全解读跨平台设计、CI 测试矩阵与编译期特性管理Nushell 平台支持策略全解读跨平台设计、CI 测试矩阵与编译期特性管理 本文以仓库开发者文档 devdocs/PLATFORM_SUPPORT.md hCLI开发工具上一篇如何让微信聊天不再“阅后即焚”WeChatMsg带你实现聊天记录永久保存下一篇Deep-Live-Cam终极指南如何实现单图片实时AI换脸创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenBLAS 持续集成（CI）全解析：跨架构、跨编译器的构建与测试矩阵
高性能计算科学计算【免费下载链接】OpenBLASOpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version.项目地址https://gitcode.com/gh_mirrors/op/OpenBLAS点击查看免费下载OpenBLAS 的 CI 体系覆盖 x86_64、arm64、Power、z/Architecturezarch与多种 RISC 系架构横跨 Windows、macOS、Linux、FreeBSD 与 Android/iOS 等目标平台并同时验证 GNU make 与 CMake 两套构建系统、多组 C/Fortran 编译器以及 pthreads/OpenMP/单线程等线程模型。本文以仓库 docs/ci.md 的 CI 作业矩阵为骨架结合 azure-pipelines.yml、appveyor.yml 与.github/workflows/下的真实流水线定义逐项讲解矩阵中每个维度架构、编译器、构建系统、线程模型、库类型、CI 提供方的含义、背后的构建选项Makefile.rule以及跨架构验证是如何通过交叉编译、QEMU 模拟和 Docker 容器落地的。读完本文你将能读懂 OpenBLAS 的 CI 矩阵表理解 DYNAMIC_ARCH、INTERFACE64、USE_OPENMP 等核心开关在 CI 场景中的用途并能在自己的仓库中复刻出类似的跨平台构建测试矩阵。一、CI 矩阵总览一张表看懂 OpenBLAS 的测试覆盖面OpenBLAS 是一个面向多架构、多操作系统的高性能 BLAS 实现其内核代码为每种 CPU 微架构分别提供经过手工优化的汇编/内建实现见 kernel/x86_64、kernel/arm64、kernel/power 等目录因此它的 CI 必须回答一个核心问题在无法购买/租用每一种硬件的情况下如何保证每个架构组合上的代码依然可构建、可运行、结果正确。文档 docs/ci.md 用一张CI jobs矩阵表记录了当时正在运行的持续集成作业每一行代表一个独立的 CI 作业job列则代表该作业的维度。把这张表拆解开来可以得到 OpenBLAS CI 的九个观察维度维度取值示例说明Arch宿主机架构x86_64、arm64、power、zarch运行 CI 的宿主 CPU 架构Target CPU目标 CPUIntel、Haswell、SkylakeX、Neoverse N1、Graviton3、pwr9、z14、I6400、P6600 等编译时通过TARGET指定的目标微架构OSWindows、CentOS5、Ubuntu、macOS11/12/14/26、Alpine Linux(musl)、FreeBSD、QEMU构建与测试运行的操作系统Build systemCMAKE、gmake、mingw32-make、CMAKE/Ninja、CMAKE/VS2015、CMAKE/VS2017两套构建体系GNU make 与 CMakeXComp to交叉编译目标-无、arm、arm64、mips64、mips32、riscv64、ia64、x86_64宿主架构与目标架构不一致时的交叉编译目标C Compilermingw6.3、gcc 4.8、gcc、VS2017、LLVM、gcc-10、gcc-12、AppleClang 14、gcc15 等C 编译器及其版本Fortran Compiler-无NOFORTRAN、gfortran、flang、ifort、flang*Fortran 编译器-表示该作业禁用 FortranNOFORTRAN1threadingpthreads、OpenMP、none、空线程模型pthreads 内部线程、OpenMP、或单线程DYN_ARCH、-、list、no_avx512是否启用 DYNAMIC_ARCH 多架构支持list表示配合 DYNAMIC_LIST 指定子集INT64-、是否启用 64 位整数接口INTERFACE641即 ILP64Librariesstatic、shared、both构建静态库、共享库或两者都构建CI ProviderAppveyor、Azure、Github、OSUOSL实际运行 CI 的平台1.1 矩阵里的三种 CI Provider 分工从表中可以看到 OpenBLAS 的 CI 分布在三个提供方上这与仓库根目录下的三个 CI 配置文件一一对应Appveyorappveyor.yml负责最早的 Windows 作业使用 Visual Studio 2015 工作镜像 MinGW gcc 5.3/6.3 编译器走 CMake ctestAzure Pipelinesazure-pipelines.yml负责大部分 Linux/macOS/Windows 作业包括 manylinux Docker 构建、Intel SDE 模拟 AVX-512、OS X 上的 GCC/Clang/ifort/flang 组合、Android NDK 与 iOS 交叉编译、Alpine musl 测试GitHub Actions.github/workflows负责后续新增的 arm64Apple M1 / Neoverse / Graviton3、FreeBSD、以及 MIPS64/RISC-V/LoongArch 的 QEMU 交叉测试OSUOSLOSU Open Source Lab表末两行 Power9pwr9与 z14 的作业直接跑在 IBM Power 与 z/Architecture 的真实硬件上这两行由仓库外的独立配置驱动表中以power与zarch标注。1.2 为什么需要如此多的维度组合BLAS 库的性能与正确性高度依赖 CPU 微架构特性。OpenBLAS 通过TARGET选择为特定微架构优化的内核如 SKYLAKEX、HASWELL、NEHALEM、CORE2、ARMV8、NEOVERSEN1、I6400、P6600、LOONGSON3R5、C910V、pwr9、z14 等通过DYNAMIC_ARCH1把多个目标内核打包进同一个二进制运行时用 cpuid 检测机器并分发到对应内核。CI 矩阵必须保证每个受支持架构既有针对具体微架构的构建验证也有通用二进制DYNAMIC_ARCH的构建验证既有本机原生构建也有通过交叉编译 QEMU 用户态模拟的验证因为 CI 宿主机主要是 x86_64 与 arm64无法原生运行 MIPS/RISC-V/LoongArch 代码。二、CI 中反复出现的核心构建选项从 Makefile 到 CMake矩阵表中的 DYN_ARCH、INT64、threading、Libraries 等列对应的是 OpenBLAS 构建系统Makefile.rule 与 cmake中一组核心开关。理解这些开关是读懂 CI 矩阵的前提。2.1 TARGET为目标微架构定制内核TARGET指定编译目标 CPU。文档矩阵中出现的TARGETCORE2、TARGETNEHALEM、TARGETARMV8、TARGETARMV7、TARGETMIPS64_GENERIC、TARGETSICORTEX、TARGETI6400、TARGETP6600、TARGETI6500、TARGETRISCV64_GENERIC、TARGETC910V、TARGETLOONGSONGENERIC、TARGETLA464、TARGETLA264等分别对应 kernel 下各架构目录中以.generic、.I6400、.P6600、.C910V、.LA464等为后缀的内核变体文件。不指定TARGET时构建系统会自动探测宿主机 CPU如 Makefile.rule 注释所述You can specify the target architecture, otherwise its automatically detected。实战要点交叉编译时必须显式给出TARGET因为宿主机探测到的架构与目标架构不一致。例如 CI 中所有 mips64/riscv64/loongarch64 作业都显式传入了TARGET。2.2 DYNAMIC_ARCH 与 DYNAMIC_LIST一个二进制跑遍多代 CPUDYNAMIC_ARCH1对应 CMake 的-DDYNAMIC_ARCHON会把多个目标 CPU 的内核打包进同一个库运行时根据 cpuid 结果选择最优内核。矩阵中 DYN_ARCH 列取值为-关闭动态架构编译为单一目标如 CentOS5 gcc 4.8 作业、SDE SkylakeX 作业开启全部架构都包含如 macOS11 gcc-10 OpenMP 作业、Apple M1 系列作业、Graviton3 作业list开启但只打包指定子集通过DYNAMIC_LISTSANDYBRIDGE或DYNAMIC_LISTNEHALEM HASWELL SKYLAKEX指定azure-pipelines.yml 的 Windows_mingw_gmake 作业、OSX_OpenMP_Clang 作业no_avx512开启但排除 AVX-512 内核macOS11 CMAKE llvm OpenMP 作业即配合-DNO_AVX5121原因是当时部分 macOS 机器/编译器对 AVX-512 支持不完善。从 Makefile.rule 可以看到DYNAMIC_ARCH 模式下还可以追加DYNAMIC_OLDER 1来把 PENRYN、DUNNINGTON、OPTERON、OPTERON_SSE3、ATOM、NANO 等更老架构也纳入动态列表。CI 矩阵中DYNAMIC_LIST常配合TARGETCORE2使用即以 CORE2 为基线动态附加新架构这是 OpenBLAS 官方推荐的稳健配置性能与兼容性兼顾。2.3 INTERFACE64ILP64 与 LP64 双接口矩阵中的 INT64 列对应INTERFACE641CMake 为-DINTERFACE641。默认 OpenBLAS 采用 LP64 接口int为 32 位INTERFACE641时所有 BLAS/LAPACK 接口改用 64 位整数int64_t便于处理超过 2^31 个元素的大规模问题。CI 中该开关的覆盖集中在 Apple M1 作业.github/workflows/apple_m.yml 矩阵中ilp64: [0, 1]即 LP64 与 ILP64 各跑一遍、msys2 作业idx: [int32, int64]与部分 Windows 作业确保两种 ABI 都能通过make -C test/ctest测试。2.4 threadingpthreads / OpenMP / 单线程矩阵的 threading 列取值有 pthreads、OpenMP、none单线程pthreadsOpenBLAS 默认的多线程后端USE_THREAD1内部自管理线程池OpenMPUSE_OPENMP1改用 OpenMP 运行时Makefile.rule 特别提醒POWER8 目标必须设置 USE_OPENMP1不能设 0这也是矩阵中 pwr9、z14 作业均使用 OpenMP 的原因之一none / 空USE_THREAD0的单线程构建如 OSX_GCC_Nothreads 作业make USE_THREADS0 CCgcc-13 FCgfortran-13。CI 之所以要把三种线程模型都覆盖一遍是因为它们走完全不同的线程调度代码路径driver/level3 下的多线程驱动与 common_thread.h 的线程抽象任何一条路径的回归都必须在多个平台上被捕获。2.5 Librariesstatic / shared / both矩阵 Libraries 列区分静态库static、共享库shared与两者都建both。构建选项上NO_STATIC1跳过静态库、NO_SHARED1跳过共享库Makefile.ruleCMake 则用-DBUILD_SHARED_LIBSON/OFF与-DBUILD_STATIC_LIBS控制。多数跨平台作业选择both以同时验证libopenblas.a与libopenblas.so/.dylib/.dll的生成部分 Windows/静态场景如 VS2015、VS2017、Ninja LLVM 作业只验证 static因为 Windows 上共享库需要处理符号导出见 exports 目录与 exports.h。2.6 NOFORTRAN 与 Fortran 编译器列矩阵中 Fortran Compiler 为-的作业如 Windows mingw、LLVM、部分交叉编译作业代表NOFORTRAN1构建——OpenBLAS 核心是 C 代码可以完全脱离 Fortran 编译此时不包含需要 Fortran 的参考 LAPACK 路径。其余作业分别使用 gfortranGNU、flangLLVM 生态的 Fortran、ifort/ifxIntel、VS 自带 Fortran 等用于编译 LAPACK 参考实现lapack-netlib与测试程序。flang 作业如 Windows_flang_clang、Windows_cl_flang、OSX_LLVM_flangnew专门验证 LLVM 工具链全链路clang C flang Fortran能否完整构建并跑通 ctest。三、按平台拆解 CI 作业Windows / macOS / Linux / FreeBSD / 交叉编译3.1 Windows四套工具链并行验证Windows 是 OpenBLAS 发行版的重要平台CI 为此覆盖了四类工具链MSVCclWindows_cl作业azure-pipelines.yml用cmake -G Visual Studio 17 2022生成 VS 工程构建 Release 后直接运行openblas_utest.exe早期版本appveyor.yml 时代用Visual Studio 15 2017 Win64。由于 MSVC 无 Fortran这类作业走 NOFORTRAN 路径MinGW gccWindows_mingw_gmake作业用mingw32-make CCgcc NOLAPACK1 DYNAMIC_ARCH1 DYNAMIC_LISTSANDYBRIDGE专门验证 Windows 下的 GNU make 构建路径appveyor.yml 中还有 MinGW-gcc-5.3.032 位与 MinGW-gcc-6.3.0-32 的 CMake MSYS Makefiles 构建clang-cl NinjaWindows_clang_cmake作业azure-pipelines.yml在 conda 中安装 ninja 后用cmake -G Ninja -DCMAKE_C_COMPILERclang-cl ... -DNOFORTRAN1 -DMSVC_STATIC_CRTON构建并ctestMSYS2 矩阵.github/workflows/dynamic_arch.yml 中的 msys2 作业进一步按msystem: [UCRT64, MINGW32, CLANG64]×idx: [int32, int64]展开覆盖 UCRT/MinGW/Clang 三套 MSYS2 环境与 LP64/ILP64 两种接口CMake 配置为-DBUILD_SHARED_LIBSON -DBUILD_STATIC_LIBSON -DDYNAMIC_ARCHON -DUSE_THREADON -DNUM_THREADS64 -DTARGETCORE2。这些作业共同保证了无论用户用 VS 工程、MinGW Makefiles 还是 Ninja 构建无论有没有 FortranWindows 上都能得到可用的 OpenBLAS。3.2 macOSGCC / LLVM / ifort 与 Apple SiliconmacOS 作业在矩阵中占据了大量行按其关注点可分为线程模型矩阵OSX_OpenMPmake TARGETCORE2 DYNAMIC_ARCH1 USE_OPENMP1 INTERFACE641 CCgcc-13 FCgfortran-13并执行 install 验证头文件/库的安装布局、OSX_GCC_NothreadsUSE_THREADS0单线程、OSX_OpenMP_Clangllvm clang libompDYNAMIC_LISTNEHALEM HASWELL SKYLAKEXNOFORTRAN1、OSX_dynarch_cmakeCMake -DDYNAMIC_LISTNEHALEM;HASWELL;SKYLAKEX 共享库等Fortran 编译器多样性gfortrangcc-10/12/13/15、ifortIntel HPCKit通过MACOS_HPCKIT_URL下载安装见 azure-pipelines.yml、flang-newOSX_LLVM_flangnew用FC/usr/local/opt/flang/bin/flang构建;Apple M1 原生矩阵.github/workflows/apple_m.yml 在macos-14上以build: [cmake, make]×openmp: [0, 1]×ilp64: [0, 1]展开 8 个组合即make 与 CMake 两套构建 × 是否 OpenMP × 是否 ILP64并在构建后依次执行make -C test、make -C ctest、make -C utest三组测试CMake 路径则运行ctest。这就是 docs/ci.md 中 Apple M1 macOS14 那 8 行作业pthreads/OpenMP × LP64/ILP64 × gmake/CMAKEx86_64 交叉构建xbuild-x86_64作业在macos-26Apple Silicon 宿主上用 Xcode 26 SDK 的 clang 以-arch x86_64交叉编译验证 macOS 上的 x86_64 构建不被破坏。3.3 Linuxglibc、musl 与老工具链Linux 侧除了常规的 Ubuntu 作业外有两类特殊验证值得注意老 glibc / 老工具链manylinux1_gcc作业azure-pipelines.yml在 quay.io/pypa/manylinux1_x86_64 容器里用make QUIET_MAKE1 BINARY64 DYNAMIC_ARCH1 TARGETNEHALEM NUM_THREADS32构建并跑 test/ctest/utest——正如其注释所说该容器的 gcc/glibc 版本很老能提前暴露新代码对老环境的兼容性问题manylinux_32bit作业在 manylinux2014_i686 容器里验证BINARY3232 位构建注意 Makefile.rule 提示 32 位下禁用 AVX/AVX2/AVX-512。矩阵中 CentOS5 gcc 4.8 的 Azure 作业也是同一目的musl libcALPINE_MUSL作业azure-pipelines.yml通过 alpine-chroot-install 进入 Alpine 环境执行make DYNAMIC_ARCH1 BINARY64构建后还额外验证安装的头文件openblas_config.h能在 musl 环境下被正常 include 编译——矩阵中对应的就是 Alpine Linux(musl) pthreads DYN_ARCH 那一行Intel SDE 模拟 AVX-512Intel_SDE_skx作业azure-pipelines.yml先构建 DYNAMIC_ARCH 库再用 Intel SDE 的sde64 -cpuid_in .../skx/cpuid.def在 SkylakeX 的 CPUID 特征下运行 utest——它用 CPU 指令集模拟器补足了CI 宿主机没有 AVX-512 硬件的缺口对应矩阵中的 SDE (SkylakeX) 行。3.4 FreeBSD两大架构的原生验证.github/workflows/freebsd.yml 通过vmactions/freebsd-vmaction 在真实 FreeBSD 虚拟机里执行gmake CCgcc15 FCgfortran15同时覆盖 x86_64bsd-x86与 aarch64bsd-aarch64指定arch: aarch64两个架构对应矩阵末尾 FreeBSD 的两行。注意 BSD 下必须用gmakeGNU make因为 BSD 自带的 make 不兼容 OpenBLAS 的 Makefile 语法。3.5 交叉编译与 QEMU 用户态模拟覆盖无硬件架构CI 宿主机只有 x86_64 / arm64但 OpenBLAS 支持的架构远不止这些。矩阵中的 XComp to 列揭示了解决方案在 x86_64 上用交叉编译器 QEMU 用户态模拟器运行测试。以 .github/workflows/mips64.yml 为例作业流程是安装交叉工具链gcc-mips64el-linux-gnuabi64、gfortran-mips64el-linux-gnuabi64r6 目标用gcc-mipsisa64r6el-linux-gnuabi64从 qemu 源码编译mips64el-linux-user用户态模拟器交叉构建 OpenBLASmake CCccache mips64el-linux-gnuabi64-gcc -static FCccache mips64el-linux-gnuabi64-gfortran -static NO_SHARED1 TARGETMIPS64_GENERIC HOSTCCccache gcc——关键点是静态链接-static与HOSTCC 指向本机 gccMakefile.rule 要求交叉编译时必须设置宿主编译器用qemu-mips64el ./utest/openblas_utest等命令在模拟器中运行全部测试utest、ctest 的 cblat1/2/3 系列以OPENBLAS_NUM_THREADS2传入以同时验证多线程路径以及 test 目录的 sblat1/2/3、dblat1/2/3、cblat1/2/3、zblat1/2/3用.dat输入文件驱动。同一模式还用于RISC-Vc910v.yml同时验证RISCV64_GENERIC与玄铁 C910Vkernel/riscv64 下的.C910V目标后者需下载玄铁官方工具链Xuantie-900-gcc-linux-...并使用 XUANTIE-RV/qemu 补丁后的模拟器由于 C910V 模拟较慢作业中还封装了run_with_retry超时重试逻辑LoongArch.github/workflows/loongarch64.yml 覆盖 LOONGSONGENERIC、LOONGSON3R5、LOONGSON2K1000、LA64_GENERIC、LA464、LA264 与 DYNAMIC_ARCHTARGETGENERIC共 7 个目标使用 Ubuntu 仓库的gcc-14-loongarch64-linux-gnu与qemu-user10.2.1Android/iOS矩阵中 macOS 宿主上的 arm/arm64 交叉行对应 azure-pipelines.yml 的 OSX_NDK_ARMV7Android NDK 的armv7a-linux-androideabi21-clang、OSX_IOS_ARMV8 / OSX_IOS_ARMV7Xcode iOS SDK-arch arm64/armv7以及 apple_m.yml 中的 xbuild-ios 系列作业——它们都是make TARGETARMV8/ARMV7 ... HOSTCCclang NOFORTRAN1的交叉构建仅验证能编出正确的库不做运行时测试无模拟器ia64、mips32矩阵中的 ia64、mips32 行同样由 x86_64 宿主交叉编译验证gmake 对应 GNU 交叉工具链。四、CI 的通用工程实践ccache、测试分层与流水线组织OpenBLAS 的 CI 配置中凝结了一套可复用的构建测试工程实践值得在阅读矩阵表之余留意。4.1 ccache 编译缓存几乎所有 GitHub Actions 作业都配置了 ccache见 .github/workflows/dynamic_arch.yml缓存键包含 runner.os / runner.arch / 构建系统 / 编译器 / Fortran 编译器 / 分支 / commit sha并特意区分 make 与 cmakeGNU make and cmake call the compilers differently ... Keep the ccache for both build tools separate避免两套构建系统互相污染缓存同时把max_size 300M、compression true写入 ccache.conf以适配 GitHub 5GB 缓存配额。Appveyor 时代则用clone_depth: 5、skip_tags: true、[av skip]提交信息跳过机制appveyor.yml来降低 CI 成本。4.2 三层测试体系矩阵表中所有能运行测试的作业都会执行以下三层测试这也是 OpenBLAS 回归保护的核心utestutestC 语言单元测试openblas_utest/openblas_utest_ext覆盖 amax/amin/axpby/axpy/dnrm2/dotu/gemv/rot/rotmg/swap/zscal 等 BLAS 例程及 fork 后行为test_fork、test_post_fork等边界场景ctestctestCBLAS 一致性测试即xscblat1..3、xdcblat1..3、xccblat1..3、xzcblat1..3输入文件为 sin2/din2/cin2/zin2、sin3/din3/cin3/zin3验证 C 接口与 Fortran 参考实现逐元素一致testtestBLAS 测试程序 sblat1/2/3、dblat1/2/3、cblat1/2/3、zblat1/2/3以.dat驱动验证 Fortran 接口正确性。多线程路径由OPENBLAS_NUM_THREADS2或 OMP_NUM_THREADS环境变量在运行测试时激活例如 mips64 作业中同一条目分别以线程数 1 与 2 各跑一遍。此外还有专门的线程压力测试dynamic_arch.yml 的linux_thread_stress/msys2_thread_stress作业用 cpp_thread_test 下的 dgemm/dgemv 多线程程序配合 ctest 过滤条件ctest -R dgemm_thread_safety|...运行tsan 后端还用 clang 的-fsanitizethread Archerlibarcher.so对 OpenMP 场景做数据竞争检测。4.3 触发器与路径过滤各 CI 配置文件对触发时机做了精细控制Azure 流水线只在develop分支的 push 和 PR 上触发并排除docs/**与**/*.md路径文档变更不触发构建GitHub Actions 的 workflow 同样使用paths-ignore: docs/**与concurrency: cancel-in-progress: true同一分支新提交自动取消旧构建appveyor.yml 则通过[av skip]提交信息让开发者主动跳过。所有 workflow 还带fail-fast: false保证矩阵中某个组合失败不会取消其余组合的验证结果。五、如何把 docs/ci.md 的矩阵当作 OpenBLAS 的支持矩阵来读由于 CI 矩阵的每一行都代表当前 CI 确实在验证的配置组合这张表实际上比任何支持平台列表都更准确地反映了 OpenBLAS 的质量保障范围。阅读和使用它的建议先看 Provider 列Appveyor/Azure 行对应 appveyor.yml 与 azure-pipelines.ymlGithub 行对应 .github/workflows 下的具体 workflow 文件OSUOSL 行对应真实的 Power/z 硬件验证——需要复现某个作业时直接打开对应文件查看完整命令关注 DYN_ARCH 与 INT64 的组合这两列直接决定产物的 ABI 与内核覆盖范围。分发场景如 conda-forge、系统包通常选择DYN_ARCH 的通用二进制需要超大矩阵计算的应用则应确认目标发行版是否覆盖INT64 的组合判断你的环境是否被覆盖如果你的部署环境是宿主 x86_64 muslAlpine 容器Apple Silicon OpenMPARM 服务器 ILP64等都能在矩阵中找到对应行意味着该组合持续被 CI 保护理解交叉编译行的边界XComp to 非空的行只验证构建产物正确生成而 QEMU 行mips64/riscv64/loongarch64还能在用户态模拟器里跑完整的三层测试Android/iOS 行则只保证交叉编译成功不包含运行时测试——如果你要为这些平台做深度测试需要自行准备真机或模拟环境。六、结语OpenBLAS 的 CI 矩阵docs/ci.md是一份用一行一行作业说话的跨平台工程记录它同时验证两套构建系统GNU make / CMake、四类以上 C 编译器GCC / clang / MSVC / MinGW、三类 Fortran 编译器gfortran / flang / ifort、三种线程模型pthreads / OpenMP / 单线程、两种 ABILP64 / ILP64、多种库产物形态static / shared / both并通过 Docker 老环境、Intel SDE、QEMU 用户态模拟、OSUOSL 真机等方式把覆盖面延伸到 CI 硬件之外。对于想要为自己的高性能数值库搭建 CI 的开发者这套矩阵及其背后的流水线定义azure-pipelines.yml、.github/workflows本身就是一份可参照的范本用最少的硬件验证最多的架构组合。提示本仓库的 CI 配置会随版本迭代调整阅读 docs/ci.md 时建议结合当时仓库根目录下的 appveyor.yml、azure-pipelines.yml、Jenkinsfile 与.github/workflows/目录如 apple_m.yml、dynamic_arch.yml、mips64.yml、c910v.yml、loongarch64.yml、freebsd.yml、arm64_graviton.yml一并核对这些文件才是每个作业的权威定义。赞分享高性能计算科学计算【免费下载链接】OpenBLASOpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version.项目地址https://gitcode.com/gh_mirrors/op/OpenBLAS点击查看免费下载相关推荐RVC WebUI入门指南用10分钟素材训练自己的AI语音克隆模型RVC WebUI入门指南用10分钟素材训练自己的AI语音克隆模型 RVC WebUIRetrieval based Voice Conversion We人工智能AI 应用语音音频深度学习Slang CI 深度解析LLVM 构建缓存、sccache 与跨平台构建测试矩阵Slang CI 深度解析LLVM 构建缓存、sccache 与跨平台构建测试矩阵 本文以仓库中的 docs/ci.md https://link.gitco编译器图形学编程语言Nushell 平台支持策略全解读跨平台设计、CI 测试矩阵与编译期特性管理Nushell 平台支持策略全解读跨平台设计、CI 测试矩阵与编译期特性管理 本文以仓库开发者文档 devdocs/PLATFORM_SUPPORT.md hCLI开发工具上一篇如何让微信聊天不再“阅后即焚”WeChatMsg带你实现聊天记录永久保存下一篇Deep-Live-Cam终极指南如何实现单图片实时AI换脸创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考