编译器高性能计算【免费下载链接】numbaNumPy aware dynamic Python compiler using LLVM项目地址https://gitcode.com/gh_mirrors/nu/numba点击查看免费下载导读本文以 Numba 官方参考文档中的《Support Policy》见 support_tiers.rst为骨架系统梳理 Numba及其核心依赖 llvmlite对操作系统、硬件架构、打包格式与分发渠道的支持分级制度。文章详细解读 Tier 1 / Tier 1.5 / Tier 2a / Tier 2b 四级支持模型的确切定义、入选条件与保证并结合仓库内真实的 CI/CD 工作流.github/workflows、conda 配方buildscripts/condarecipe.local/meta.yaml与 wheel 构建脚本buildscripts/github/build_wheel_linux.sh等源码证据回答三类高频问题哪些平台/硬件/包格式受支持为什么支持 X 而不支持 Y让 Z 进入受支持列表需要什么条件1. 先厘清八个关键术语理解 Numba 的支持策略首先要区分下面这组容易混淆的概念定义原文出自 support_tiers.rst 的 Definitions 一节术语定义示例硬件目标hardware target代码运行的目标硬件x86_64、aarch64操作系统operating system代码运行的操作系统可包含仿真/类仿真环境WSLWindows Subsystem for Linux、macOS Rosetta打包系统packaging system将源码转换为可分发包的构建系统conda build、pip wheel、rpmbuild包package打包系统产出的、可在分发系统中使用的工件wheel、rpm、源码 tarball包类型package type包的类别wheel、conda、source分发系统distribution system向用户分发包的系统PyPI、Anaconda 仓库、Linux 发行版发布release从特定 git tag 为特定操作系统与硬件目标构建、并投放到分发系统的二进制工件由五元组描述(Numba, aarch64, Linux, wheel, PyPI)源码发布source release从特定 git tag 构建并投放到分发系统的源码工件由三元组描述(Numba, tarball, GitHub)此外还有两个贯穿全文的角色定义CI/CD为发布提供持续集成与持续交付的机制例如基于 GitHub Actions 的发布流程Numba maintainers维护者GitHub Numba 组织下各项目Numba 与 llvmlite的维护者。注意 release 是一个五元组同一项目在不同分发系统上的发布被视为不同的 release。例如 Numba 的 Linux x86_64 wheel 与 Numba 的 Linux x86_64 conda 包 是两次发布分别由 PyPI 与 Anaconda 仓库负责分发。这个颗粒度划分是理解后续各 Tier 列表的基础。2. 四级支持模型总览支持策略按维护承诺的强弱分为四个层级外加一个过渡级层级定位维护主体Tier 1官方正式支持、完整维护的发布配置Numba maintainersTier 1.5面向新兴配置的实验性发布预期将来晋升 Tier 1Numba maintainers实验性质Tier 2a由大型软件发行商构建的发布Linux/BSD 发行版维护者Numba 提供建议支持Tier 2b社区尽力而为的一般性支持社区Numba 仅做尽力协助从源码结构看这一分层与仓库的实际发布矩阵一一对应见 buildscripts/github/workflow_groups.json其中conda与wheel两组工作流各自覆盖linux-64、linux-aarch64、osx-arm64、win-64、win-arm64五个平台恰好对应下文 Tier 1 的四个平台加上 Tier 1.5 的win-arm64。3. Tier 1由 Numba 维护者正式维护的发布3.1 承诺的保证进入 Tier 1 意味着维护者承担以下硬性义务维护公共 CI/CD 并发布软件——构建、测试与发布全流程由 Numba 项目自身掌控不接受破坏 CI/CD 的补丁——任何导致公共 CI 挂掉的改动都无法合并这是对发布质量的第一道闸门重大变更必须出候选版本RC——任何版本的首个 RC 至少提供两周的公开测试窗口。3.2 入选 Tier 1 的四项硬性条件一个发布配置要被列入 Tier 1必须同时满足该操作系统与硬件目标上必须存在基于 conda 的 Python 发行版。原因是 Numba 技术栈的公共 CI/CD即便是 wheel 构建都由 conda/conda 包驱动此条件的目的是降低整体 CI/CD 维护负担操作系统与硬件目标必须被 GitHub Actions 免费额度支持——CI 基础设施成本因此可控发布包类型必须是 conda 或 wheel分发系统必须是 PyPI 或 Anaconda 仓库anaconda.org。Tier 1 地位还以核心依赖的持续支持为前提包括Python、NumPy、LLVM。一旦某个核心依赖停止支持、弃用或无法提供合适版本对应平台将自动降级到 Tier 2——这就是文档明确指出的自动转换机制。3.3 当前 Tier 1 发布清单Numba 与 llvmlite 项目① conda 包anaconda.org 的numbachannelconda 命名与括号澄清如下osx-arm64Apple silicon 上的 macOSlinux-64x86_64上的 Linuxlinux-aarch64aarch64上的 Linuxwin-64x86_64上的 Windows② wheel 包PyPI 分发系统osx-arm64Apple silicon 上的 macOSlinux-64x86_64上的 Linuxlinux-aarch64aarch64上的 Linuxwin-64x86_64上的 Windows③ 为支持 Python 生态而额外维护的两个 Tier 1 发布Numba 维护者要么直接维护、要么协助维护Anaconda 发行版Anaconda Distribution自带的 conda 包同样覆盖osx-arm64、linux-64、linux-aarch64、win-64四个平台Conda-Forge 发行版的 conda 包同样覆盖上述四个平台。3.4 源码佐证Tier 1 平台的 CI 工作流Tier 1 的四平台矩阵在仓库 CI 中有完整落地。以 macOS Apple silicon 与 Linux aarch64 为例numba_osx-arm64_conda_builder.yml 与 numba_osx-arm64_wheel_builder.yml工作流注释中明确 osx-arm64 ... starts first to manage osx runner limit即通过错峰调度规避 macOS runner 配额限制numba_linux-aarch64_conda_builder.yml 与 numba_linux-aarch64_wheel_builder.yml每周六定时触发构建Python 3.14 也在矩阵内。conda 配方的平台条件同样印证了 Tier 1 的细节。以 buildscripts/condarecipe.local/meta.yaml 为例vs2022_{{ target_platform }} # [win and arm64]——Windows ARM64 构建需要 VS2022 工具链llvm-openmp{{ c_compiler_version }} # [osx]——macOS 需要 LLVM 提供的 OpenMP 头文件tbb-devel 2021.6 # [not (aarch64 or ppc64le)]——TBB 依赖在 aarch64/ppc64le 上被排除原因是ppc64le and aarch64 are pending testing so excluded for nowlibopenblas 0.3.18, !0.3.20 # [arm64]——针对 Apple silicon 上 OpenBLAS 0.3.17/0.3.20 的已知 bug 做了版本约束可追溯至 Numba issue #7822、#8096 的关联修复。这些平台条件正是 Tier 1 发布必须由 conda 驱动 与 包类型限定为 conda/wheel 两项条件在配方层面的直接体现。4. Tier 1.5面向新兴发布配置的实验性支持4.1 定位与预期Tier 1.5 覆盖当前使用量有限、但维护者判断其重要性将上升的发布配置。其核心价值是让这些配置尽早获得二进制包从而让下游项目可以提前在其上进行测试。Tier 1.5 包被明确视为实验性的可能存在显著 bug预期这些配置最终会晋升到 Tier 1。4.2 对 Tier 1.5 的具体期望只为有限的 Python 版本构建包可能仅支持最新一个版本包必须能在 Numba 与 llvmlite 使用的 GitHub Actions CI 系统中测试根据生态支持情况如 NumPy 是否可用构建 wheel或conda 包或两者都构建main分支在 Tier 1.5 配置上的构建失败属于发布阻断问题应尽快处理但维护者被鼓励跳过测试、记录已知问题而不是投入大量精力调试因为让main恢复健康状态并非当务之急Tier 1.5 配置上的已知问题可按时间允许时再解决不阻断 Numba 发布。4.3 当前 Tier 1.5 发布清单① Python 3.14 自由线程free-threading构建的 wheel 包PyPIosx-arm64Apple silicon 上的 macOSlinux-64x86_64上的 Linuxlinux-aarch64aarch64上的 Linuxwin-64x86_64上的 Windows②win-arm6464 位 ARM 上的 WindowsPyPI wheel anaconda.org conda 包覆盖Python 3.12 及以上。4.4 源码佐证自由线程与 Windows ARM64 的落地自由线程free-threaded构建在 wheel 构建工作流中有专门处理如 numba_linux-64_wheel_builder.yml 与 numba_linux-aarch64_wheel_builder.yml 中注释指出 For free-threaded builds (e.g. cp314t), the manylinux path is cp314-cp314t——即 CPython 3.14 free-threaded 版本在 manylinux 下使用cp314t标记路径Windows ARM64 有独立的工作流 numba_win-arm64_conda_builder.yml使用bootstrap-win-arm64-round-2-nativechannel以及 wheel 对应工作流整体矩阵见 workflow_groups.jsonconda与wheel两组均包含win-arm64与文档 win-arm64 为 Tier 1.5 的定位一致。5. Tier 2a由大型软件发行商构建的发布Tier 2a 面向不由 Numba 维护者提供 CI/CD 与分发系统、而由大型发行商自行构建的发布。Numba 侧的原则是Tier 1 发布应尽量避免破坏这些发行版构建的包但这属于非阻断条件维护者会提供支持与建议帮助修复任何破坏只要不显著增加维护负担与 Tier 2a 发布维护相关的补丁会被接受CI/CD 与分发系统由外部提供不由 Numba 维护者维护。当前示例包括Linux 发行版RHEL / Fedora / Rocky、Debian / UbuntuBSD 发行版FreeBSD、NetBSD、OpenBSD、DragonFly BSD。理解要点Tier 2a 的本质是别人打包、Numba 协助。发行版维护者负责把 Numba 纳入自己的包仓库如rpmbuild体系Numba 则提供上游支持与修复建议。6. Tier 2b一般社区支持尽力而为Tier 2b 是覆盖面最广、承诺最轻的层级对前面 Definitions 中列出的任何类别提供 best effort 级别的协助。原则包括只要不显著增加维护负担、或不会引入大量无法测试的代码针对项目源码与构建系统的补丁都会被接受CI/CD 与分发如果有由 Numba 项目之外的系统提供不由 Numba 维护者维护。当前示例包括未列入 Tier 1 的 conda 与 wheel 包如osx-64截至 Numba0.63.*已归入此级即 Intel Mac 上的 macOS其他硬件目标s390xIBM 大型机架构、ppc64lePOWER 小端架构、RISC-V。源码侧也有对应痕迹例如 setup.py 中if platform.machine() ppc64le: extra_link_args [-pthread]为 POWER 小端架构做了特殊链接参数处理同时该文件按sys.platformlinux/darwin/win32与platform.machine()做平台分支体现了平台差异由构建系统就地消化的设计——即便某些平台不在 Tier 1 内源码构建层面仍保留了适配路径。7. Tier 之间的迁移机制如何升级或降级Tier 迁移遵循明确的规则与流程降级Tier 1 → Tier 2只要 Tier 1 的任何入选条件被打破例如核心依赖 Python/NumPy/LLVM 停止提供合适版本或硬件目标不再被 GitHub Actions 免费额度支持该发布即自动降级。升级Tier 2 → Tier 1反向亦然——若某 Tier 2 目标满足了 Tier 1 的全部条件可以申请迁入 Tier 1。流程约束双向适用Tier 之间的任何迁移都只能通过 GitHub issue 上的**提案proposal**发起经维护者讨论与批准例如在维护者会议或公开会议中讨论后方可实施。最终决定权在 Numba 维护者手中因为他们是项目的长期承诺者、承担着持续的维护负担。实操含义如果你希望某个平台进入 Tier 1正确路径不是催更而是发起一份提案证明该平台满足 conda 可用、GitHub Actions 免费额度可用、包类型与分发系统合规、且 Python/NumPy/LLVM 生态具备持续支持这四项条件。8. 加速器与特殊硬件支持独立于 Tier 评估GPU 或加速器支持独立于上述发布 Tier 评估。一项加速器支持要成立需要同时满足厂商工具链在宿主硬件目标与操作系统上可用例如 NVIDIA CUDA 工具链维护者具备相应专业知识或有强大的社区贡献支撑具备可用的测试基础设施。这在仓库中有直接体现buildscripts/condarecipe.local/meta.yaml 的run_constrained中约束了cuda-version 11.2、cudatoolkit 11.2、cuda-python 11.6、scipy 1.0等运行时下限说明 CUDA 支持依赖的是外部厂商工具链与 Python/NumPy 生态的配套版本而不是某个Numba 发布 Tier——这也解释了为什么Windows 上 x86_64 属于 Tier 1与CUDA 是否可用是两个独立的决策维度。9. 实践清单如何判断你的环境处于哪个支持层级结合上述定义可以按以下流程快速定位你的使用场景确定 OS 硬件目标是osx-arm64、linux-64、linux-aarch64、win-64之一还是win-arm64、osx-64、s390x、ppc64le、RISC-V等其他组合确定包来源PyPI 的 wheel、anaconda.orgnumbachannel 的 conda 包、Anaconda Distribution/Conda-Forge 自带包、Linux/BSD 发行版仓库、还是源码自行构建对照清单落在四平台 ×conda/wheel×PyPI/anaconda.org内 →Tier 1享有完整 CI/CD 与 RC 候选期保障是 Python 3.14 free-threaded wheel 或win-arm64Py3.12→Tier 1.5预期可用但需容忍实验性 bug且可能只覆盖有限 Python 版本通过 Debian/Ubuntu/RHEL/Fedora/Rocky 或 BSD 发行版安装 →Tier 2aNumba 协助发行版维护者修复问题其余组合如 Intel Mac、s390x、ppc64le、RISC-V→Tier 2b获得社区尽力而为级别的支持涉及 CUDA 等 GPU 支持 → 走独立的加速器评估标准厂商工具链 维护者能力 测试设施。总结Numba 的支持策略是一套以维护成本为核心约束、以 conda GitHub Actions 为技术底座、以 Python/NumPy/LLVM 生态为前置依赖的分级制度Tier 1保证官方 CI/CD 与发布条件是conda 可用 GitHub Actions 免费额度 conda/wheel 包类型 PyPI/Anaconda 分发当前覆盖四大主流平台Tier 1.5以实验姿态提前布局 Python 3.14 free-threaded 与 Windows ARM64 等新兴配置Tier 2a/2b分别由发行商与社区承担主要维护Numba 提供建议与有限补丁接纳平台迁移必须走 GitHub issue 提案流程最终由维护者拍板加速器如 CUDA支持独立评估不受发布 Tier 约束。这套机制既保证了 Numba 在主流平台上的发布质量与可预测性也为新兴架构留出了低成本的实验通道——这正是项目能在 x86_64 主流之外逐步覆盖 Apple silicon、aarch64、Windows ARM64 乃至自由线程 Python 的结构性原因。如果你想深入了解某个平台的具体构建细节可直接阅读仓库中对应的 .github/workflows 工作流文件与 buildscripts/condarecipe.local/meta.yaml 配方。赞分享编译器高性能计算【免费下载链接】numbaNumPy aware dynamic Python compiler using LLVM项目地址https://gitcode.com/gh_mirrors/nu/numba点击查看免费下载相关推荐Espanso 平台支持等级Platform Tiers全解读核心支持、尽力而为与不支持平台的边界Espanso 平台支持等级Platform Tiers全解读核心支持、尽力而为与不支持平台的边界 本文基于仓库文档 docs/src/ch02 01 p桌面应用CLINixpkgs 平台支持分级Platform Support Tiers全面解析从 Tier 1 到 Tier 7 的支持矩阵与源码落地Nixpkgs 平台支持分级Platform Support Tiers全面解析从 Tier 1 到 Tier 7 的支持矩阵与源码落地 Nixpkgs包管理器操作系统AVA 支持的 Node.js 版本Support Statement官方支持策略与维护承诺详解AVA 支持的 Node.js 版本Support Statement官方支持策略与维护承诺详解 AVA 是一个专注于并发执行与开发信心的 Node.js测试创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
编译器高性能计算【免费下载链接】numbaNumPy aware dynamic Python compiler using LLVM项目地址https://gitcode.com/gh_mirrors/nu/numba点击查看免费下载导读本文以 Numba 官方参考文档中的《Support Policy》见 support_tiers.rst为骨架系统梳理 Numba及其核心依赖 llvmlite对操作系统、硬件架构、打包格式与分发渠道的支持分级制度。文章详细解读 Tier 1 / Tier 1.5 / Tier 2a / Tier 2b 四级支持模型的确切定义、入选条件与保证并结合仓库内真实的 CI/CD 工作流.github/workflows、conda 配方buildscripts/condarecipe.local/meta.yaml与 wheel 构建脚本buildscripts/github/build_wheel_linux.sh等源码证据回答三类高频问题哪些平台/硬件/包格式受支持为什么支持 X 而不支持 Y让 Z 进入受支持列表需要什么条件1. 先厘清八个关键术语理解 Numba 的支持策略首先要区分下面这组容易混淆的概念定义原文出自 support_tiers.rst 的 Definitions 一节术语定义示例硬件目标hardware target代码运行的目标硬件x86_64、aarch64操作系统operating system代码运行的操作系统可包含仿真/类仿真环境WSLWindows Subsystem for Linux、macOS Rosetta打包系统packaging system将源码转换为可分发包的构建系统conda build、pip wheel、rpmbuild包package打包系统产出的、可在分发系统中使用的工件wheel、rpm、源码 tarball包类型package type包的类别wheel、conda、source分发系统distribution system向用户分发包的系统PyPI、Anaconda 仓库、Linux 发行版发布release从特定 git tag 为特定操作系统与硬件目标构建、并投放到分发系统的二进制工件由五元组描述(Numba, aarch64, Linux, wheel, PyPI)源码发布source release从特定 git tag 构建并投放到分发系统的源码工件由三元组描述(Numba, tarball, GitHub)此外还有两个贯穿全文的角色定义CI/CD为发布提供持续集成与持续交付的机制例如基于 GitHub Actions 的发布流程Numba maintainers维护者GitHub Numba 组织下各项目Numba 与 llvmlite的维护者。注意 release 是一个五元组同一项目在不同分发系统上的发布被视为不同的 release。例如 Numba 的 Linux x86_64 wheel 与 Numba 的 Linux x86_64 conda 包 是两次发布分别由 PyPI 与 Anaconda 仓库负责分发。这个颗粒度划分是理解后续各 Tier 列表的基础。2. 四级支持模型总览支持策略按维护承诺的强弱分为四个层级外加一个过渡级层级定位维护主体Tier 1官方正式支持、完整维护的发布配置Numba maintainersTier 1.5面向新兴配置的实验性发布预期将来晋升 Tier 1Numba maintainers实验性质Tier 2a由大型软件发行商构建的发布Linux/BSD 发行版维护者Numba 提供建议支持Tier 2b社区尽力而为的一般性支持社区Numba 仅做尽力协助从源码结构看这一分层与仓库的实际发布矩阵一一对应见 buildscripts/github/workflow_groups.json其中conda与wheel两组工作流各自覆盖linux-64、linux-aarch64、osx-arm64、win-64、win-arm64五个平台恰好对应下文 Tier 1 的四个平台加上 Tier 1.5 的win-arm64。3. Tier 1由 Numba 维护者正式维护的发布3.1 承诺的保证进入 Tier 1 意味着维护者承担以下硬性义务维护公共 CI/CD 并发布软件——构建、测试与发布全流程由 Numba 项目自身掌控不接受破坏 CI/CD 的补丁——任何导致公共 CI 挂掉的改动都无法合并这是对发布质量的第一道闸门重大变更必须出候选版本RC——任何版本的首个 RC 至少提供两周的公开测试窗口。3.2 入选 Tier 1 的四项硬性条件一个发布配置要被列入 Tier 1必须同时满足该操作系统与硬件目标上必须存在基于 conda 的 Python 发行版。原因是 Numba 技术栈的公共 CI/CD即便是 wheel 构建都由 conda/conda 包驱动此条件的目的是降低整体 CI/CD 维护负担操作系统与硬件目标必须被 GitHub Actions 免费额度支持——CI 基础设施成本因此可控发布包类型必须是 conda 或 wheel分发系统必须是 PyPI 或 Anaconda 仓库anaconda.org。Tier 1 地位还以核心依赖的持续支持为前提包括Python、NumPy、LLVM。一旦某个核心依赖停止支持、弃用或无法提供合适版本对应平台将自动降级到 Tier 2——这就是文档明确指出的自动转换机制。3.3 当前 Tier 1 发布清单Numba 与 llvmlite 项目① conda 包anaconda.org 的numbachannelconda 命名与括号澄清如下osx-arm64Apple silicon 上的 macOSlinux-64x86_64上的 Linuxlinux-aarch64aarch64上的 Linuxwin-64x86_64上的 Windows② wheel 包PyPI 分发系统osx-arm64Apple silicon 上的 macOSlinux-64x86_64上的 Linuxlinux-aarch64aarch64上的 Linuxwin-64x86_64上的 Windows③ 为支持 Python 生态而额外维护的两个 Tier 1 发布Numba 维护者要么直接维护、要么协助维护Anaconda 发行版Anaconda Distribution自带的 conda 包同样覆盖osx-arm64、linux-64、linux-aarch64、win-64四个平台Conda-Forge 发行版的 conda 包同样覆盖上述四个平台。3.4 源码佐证Tier 1 平台的 CI 工作流Tier 1 的四平台矩阵在仓库 CI 中有完整落地。以 macOS Apple silicon 与 Linux aarch64 为例numba_osx-arm64_conda_builder.yml 与 numba_osx-arm64_wheel_builder.yml工作流注释中明确 osx-arm64 ... starts first to manage osx runner limit即通过错峰调度规避 macOS runner 配额限制numba_linux-aarch64_conda_builder.yml 与 numba_linux-aarch64_wheel_builder.yml每周六定时触发构建Python 3.14 也在矩阵内。conda 配方的平台条件同样印证了 Tier 1 的细节。以 buildscripts/condarecipe.local/meta.yaml 为例vs2022_{{ target_platform }} # [win and arm64]——Windows ARM64 构建需要 VS2022 工具链llvm-openmp{{ c_compiler_version }} # [osx]——macOS 需要 LLVM 提供的 OpenMP 头文件tbb-devel 2021.6 # [not (aarch64 or ppc64le)]——TBB 依赖在 aarch64/ppc64le 上被排除原因是ppc64le and aarch64 are pending testing so excluded for nowlibopenblas 0.3.18, !0.3.20 # [arm64]——针对 Apple silicon 上 OpenBLAS 0.3.17/0.3.20 的已知 bug 做了版本约束可追溯至 Numba issue #7822、#8096 的关联修复。这些平台条件正是 Tier 1 发布必须由 conda 驱动 与 包类型限定为 conda/wheel 两项条件在配方层面的直接体现。4. Tier 1.5面向新兴发布配置的实验性支持4.1 定位与预期Tier 1.5 覆盖当前使用量有限、但维护者判断其重要性将上升的发布配置。其核心价值是让这些配置尽早获得二进制包从而让下游项目可以提前在其上进行测试。Tier 1.5 包被明确视为实验性的可能存在显著 bug预期这些配置最终会晋升到 Tier 1。4.2 对 Tier 1.5 的具体期望只为有限的 Python 版本构建包可能仅支持最新一个版本包必须能在 Numba 与 llvmlite 使用的 GitHub Actions CI 系统中测试根据生态支持情况如 NumPy 是否可用构建 wheel或conda 包或两者都构建main分支在 Tier 1.5 配置上的构建失败属于发布阻断问题应尽快处理但维护者被鼓励跳过测试、记录已知问题而不是投入大量精力调试因为让main恢复健康状态并非当务之急Tier 1.5 配置上的已知问题可按时间允许时再解决不阻断 Numba 发布。4.3 当前 Tier 1.5 发布清单① Python 3.14 自由线程free-threading构建的 wheel 包PyPIosx-arm64Apple silicon 上的 macOSlinux-64x86_64上的 Linuxlinux-aarch64aarch64上的 Linuxwin-64x86_64上的 Windows②win-arm6464 位 ARM 上的 WindowsPyPI wheel anaconda.org conda 包覆盖Python 3.12 及以上。4.4 源码佐证自由线程与 Windows ARM64 的落地自由线程free-threaded构建在 wheel 构建工作流中有专门处理如 numba_linux-64_wheel_builder.yml 与 numba_linux-aarch64_wheel_builder.yml 中注释指出 For free-threaded builds (e.g. cp314t), the manylinux path is cp314-cp314t——即 CPython 3.14 free-threaded 版本在 manylinux 下使用cp314t标记路径Windows ARM64 有独立的工作流 numba_win-arm64_conda_builder.yml使用bootstrap-win-arm64-round-2-nativechannel以及 wheel 对应工作流整体矩阵见 workflow_groups.jsonconda与wheel两组均包含win-arm64与文档 win-arm64 为 Tier 1.5 的定位一致。5. Tier 2a由大型软件发行商构建的发布Tier 2a 面向不由 Numba 维护者提供 CI/CD 与分发系统、而由大型发行商自行构建的发布。Numba 侧的原则是Tier 1 发布应尽量避免破坏这些发行版构建的包但这属于非阻断条件维护者会提供支持与建议帮助修复任何破坏只要不显著增加维护负担与 Tier 2a 发布维护相关的补丁会被接受CI/CD 与分发系统由外部提供不由 Numba 维护者维护。当前示例包括Linux 发行版RHEL / Fedora / Rocky、Debian / UbuntuBSD 发行版FreeBSD、NetBSD、OpenBSD、DragonFly BSD。理解要点Tier 2a 的本质是别人打包、Numba 协助。发行版维护者负责把 Numba 纳入自己的包仓库如rpmbuild体系Numba 则提供上游支持与修复建议。6. Tier 2b一般社区支持尽力而为Tier 2b 是覆盖面最广、承诺最轻的层级对前面 Definitions 中列出的任何类别提供 best effort 级别的协助。原则包括只要不显著增加维护负担、或不会引入大量无法测试的代码针对项目源码与构建系统的补丁都会被接受CI/CD 与分发如果有由 Numba 项目之外的系统提供不由 Numba 维护者维护。当前示例包括未列入 Tier 1 的 conda 与 wheel 包如osx-64截至 Numba0.63.*已归入此级即 Intel Mac 上的 macOS其他硬件目标s390xIBM 大型机架构、ppc64lePOWER 小端架构、RISC-V。源码侧也有对应痕迹例如 setup.py 中if platform.machine() ppc64le: extra_link_args [-pthread]为 POWER 小端架构做了特殊链接参数处理同时该文件按sys.platformlinux/darwin/win32与platform.machine()做平台分支体现了平台差异由构建系统就地消化的设计——即便某些平台不在 Tier 1 内源码构建层面仍保留了适配路径。7. Tier 之间的迁移机制如何升级或降级Tier 迁移遵循明确的规则与流程降级Tier 1 → Tier 2只要 Tier 1 的任何入选条件被打破例如核心依赖 Python/NumPy/LLVM 停止提供合适版本或硬件目标不再被 GitHub Actions 免费额度支持该发布即自动降级。升级Tier 2 → Tier 1反向亦然——若某 Tier 2 目标满足了 Tier 1 的全部条件可以申请迁入 Tier 1。流程约束双向适用Tier 之间的任何迁移都只能通过 GitHub issue 上的**提案proposal**发起经维护者讨论与批准例如在维护者会议或公开会议中讨论后方可实施。最终决定权在 Numba 维护者手中因为他们是项目的长期承诺者、承担着持续的维护负担。实操含义如果你希望某个平台进入 Tier 1正确路径不是催更而是发起一份提案证明该平台满足 conda 可用、GitHub Actions 免费额度可用、包类型与分发系统合规、且 Python/NumPy/LLVM 生态具备持续支持这四项条件。8. 加速器与特殊硬件支持独立于 Tier 评估GPU 或加速器支持独立于上述发布 Tier 评估。一项加速器支持要成立需要同时满足厂商工具链在宿主硬件目标与操作系统上可用例如 NVIDIA CUDA 工具链维护者具备相应专业知识或有强大的社区贡献支撑具备可用的测试基础设施。这在仓库中有直接体现buildscripts/condarecipe.local/meta.yaml 的run_constrained中约束了cuda-version 11.2、cudatoolkit 11.2、cuda-python 11.6、scipy 1.0等运行时下限说明 CUDA 支持依赖的是外部厂商工具链与 Python/NumPy 生态的配套版本而不是某个Numba 发布 Tier——这也解释了为什么Windows 上 x86_64 属于 Tier 1与CUDA 是否可用是两个独立的决策维度。9. 实践清单如何判断你的环境处于哪个支持层级结合上述定义可以按以下流程快速定位你的使用场景确定 OS 硬件目标是osx-arm64、linux-64、linux-aarch64、win-64之一还是win-arm64、osx-64、s390x、ppc64le、RISC-V等其他组合确定包来源PyPI 的 wheel、anaconda.orgnumbachannel 的 conda 包、Anaconda Distribution/Conda-Forge 自带包、Linux/BSD 发行版仓库、还是源码自行构建对照清单落在四平台 ×conda/wheel×PyPI/anaconda.org内 →Tier 1享有完整 CI/CD 与 RC 候选期保障是 Python 3.14 free-threaded wheel 或win-arm64Py3.12→Tier 1.5预期可用但需容忍实验性 bug且可能只覆盖有限 Python 版本通过 Debian/Ubuntu/RHEL/Fedora/Rocky 或 BSD 发行版安装 →Tier 2aNumba 协助发行版维护者修复问题其余组合如 Intel Mac、s390x、ppc64le、RISC-V→Tier 2b获得社区尽力而为级别的支持涉及 CUDA 等 GPU 支持 → 走独立的加速器评估标准厂商工具链 维护者能力 测试设施。总结Numba 的支持策略是一套以维护成本为核心约束、以 conda GitHub Actions 为技术底座、以 Python/NumPy/LLVM 生态为前置依赖的分级制度Tier 1保证官方 CI/CD 与发布条件是conda 可用 GitHub Actions 免费额度 conda/wheel 包类型 PyPI/Anaconda 分发当前覆盖四大主流平台Tier 1.5以实验姿态提前布局 Python 3.14 free-threaded 与 Windows ARM64 等新兴配置Tier 2a/2b分别由发行商与社区承担主要维护Numba 提供建议与有限补丁接纳平台迁移必须走 GitHub issue 提案流程最终由维护者拍板加速器如 CUDA支持独立评估不受发布 Tier 约束。这套机制既保证了 Numba 在主流平台上的发布质量与可预测性也为新兴架构留出了低成本的实验通道——这正是项目能在 x86_64 主流之外逐步覆盖 Apple silicon、aarch64、Windows ARM64 乃至自由线程 Python 的结构性原因。如果你想深入了解某个平台的具体构建细节可直接阅读仓库中对应的 .github/workflows 工作流文件与 buildscripts/condarecipe.local/meta.yaml 配方。赞分享编译器高性能计算【免费下载链接】numbaNumPy aware dynamic Python compiler using LLVM项目地址https://gitcode.com/gh_mirrors/nu/numba点击查看免费下载相关推荐Espanso 平台支持等级Platform Tiers全解读核心支持、尽力而为与不支持平台的边界Espanso 平台支持等级Platform Tiers全解读核心支持、尽力而为与不支持平台的边界 本文基于仓库文档 docs/src/ch02 01 p桌面应用CLINixpkgs 平台支持分级Platform Support Tiers全面解析从 Tier 1 到 Tier 7 的支持矩阵与源码落地Nixpkgs 平台支持分级Platform Support Tiers全面解析从 Tier 1 到 Tier 7 的支持矩阵与源码落地 Nixpkgs包管理器操作系统AVA 支持的 Node.js 版本Support Statement官方支持策略与维护承诺详解AVA 支持的 Node.js 版本Support Statement官方支持策略与维护承诺详解 AVA 是一个专注于并发执行与开发信心的 Node.js测试创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
