GPU 上的 Rust SIMD

原文 ↗ Hacker News 讨论 ↗

Rust 开发者正在尝试把 Rust 的 portable SIMD 抽象带到 GPU 上，目标是在无需改写为 CUDA 或专用 ML 框架的情况下，让现有面向 CPU 的库高效运行在图形硬件上。评论者讨论了所提议的、由 trait 和类型驱动的 IR 如何映射到 GPU 执行模型（warp、shuffle、barrier），以及这与传统 SIMT 编程和架构特定 intrinsic 相比有哪些收益和局限。帖子还涉及 Rust SIMD 生态的成熟度、“真正可移植” SIMD 在 CPU 与 GPU 之间的挑战，以及一家初创公司如何在开源编译器栈的同时构建其上的商业产品。

项目目标与设计

  • 该工作旨在让现有、未经修改的 CPU 库（包括使用 core::simd 的代码）能够在 GPU 上运行。
  • 使用一个强类型 IR，并通过按操作参数化的 trait（归约、扫描、shuffle、strip mining）来表达。
  • 执行“形状”编码在类型中；无效组合（例如带有设备屏障的 warp 执行器）会在编译期报错。
  • 设计使用类型级常量来表示 shuffle 模式和 strip-mining 参数；据称可在编译期捕获许多 GPU 误用模式。
  • 目标是在 CPU 和 GPU 之间复用相似的抽象，而不是去“替代”CPU。

编译器、可用性与商业模式

  • 当前实现依赖一个自定义的编译器分支；尚未公开。
  • 计划是：在产品发布后开源编译器和标准库相关部分；商业模式建立在其上层构建的产品之上，而不是出售编译器本身。
  • 一些评论者表示沮丧，因为现在还无法试用或做基准测试。

用例与现有 ML 栈

  • 怀疑意见：如果必须使用数组编程 DSL（scan/gather 等），为什么不直接用 Torch/TF/JAX/MLIR？
  • 回应：这对手写的 ML 工作负载帮助不大；其价值在于让通用 CPU 库在不知不觉中获得 GPU 加速。

GPU vs CPU 以及 SIMD/SIMT 讨论

  • 多条解释说明 GPU 的“核心”如何映射到 SIMD lane、warp/wave、巨大的寄存器文件，以及如何通过大量驻留线程来隐藏延迟。
  • 对比：CPU 优化的是低延迟和复杂的缓存/推测执行；GPU 优化的是吞吐量和高带宽。
  • 对术语的争论：GPU 算 SIMD 还是 SIMT；有人强调它们是披着“线程”编程模型的向量 ISA。

Portable SIMD、nightly Rust 与生态

  • Rust 的 portable SIMD 目前只在 nightly 可用；一些用户因此转向了替代方案（例如 fearless_simd）以获得稳定版构建。
  • 对长期停留在 nightly 上的看法不一：有人认为这是谨慎的打磨期；也有人对“基础”工具和切片/指针方法多年仍不稳定感到沮丧。
  • 关于 portable SIMD 的争论：
    • 批评：大多数示例选择固定向量宽度，这损害了真正的可移植性和性能可移植性。
    • 反驳：可以做与宽度无关的泛型；当自动向量化不够、但又不需要特定 ISA 调优时，portable SIMD 是一个有用的折中方案。
    • 也承认最优宽度因架构而异，有时还取决于运行时条件；讨论中提到可通过 cfg、多版本化或 JIT 来选择策略。
    • 有人认为 SIMD ISA 差异足够大，因此只有一部分用例能真正可移植；也有人指出，“平凡”的向量/矩阵运算已经覆盖了大多数实际需求。

其他

  • 有人好奇其目标应用领域，尤其是 LLM 之外；文中提到的论点是：大多数设备自带的 GPU 都没有被充分利用。
  • 有人要求提供具体、有竞争力的基准测试（例如 radix sort）；线程中没有给出，因此性能影响仍不明确。
  • 还有一些轻微的元讨论：例如是否存在机器人评论，以及博客的“pedantic mode”开关是否用于提供更多技术细节。