Rust标准库直接能在GPU上运行了

以前咱们总觉得GPU（就是显卡里那个干重活的处理器）像个只会埋头算数学的沉默天才，让它画个三角形、训练个AI模型它在行，但你让它干点“普通电脑”的活儿，比如打开个文件、问问现在几点钟、甚至跟你打个招呼说“你好”，那简直是对牛弹琴。为啥？因为GPU天生就没装“操作系统”这套软件，它那块地盘上，很多咱们习以为常的“服务”比如文件系统、网络接口、时钟，都是不存在的。这就好比一个力大无穷的机器人，但没给它装眼睛、耳朵和嘴巴，它再能干，也没法跟你聊天或者自己去找工具箱。

但是，一家叫VectorWare的酷公司，最近干成了一件听起来像魔法一样的事情：他们让Rust编程语言的标准库，在GPU上跑起来了！

这意味着啥？简单说，就是程序员现在可以用写普通电脑程序一样的、更舒服更方便的Rust代码，来指挥GPU干活了，而且GPU代码也能做很多以前只有CPU代码才能做的事情。这可不是小打小闹的优化，这简直是给GPU这个沉默的天才装上了“五官”和“社交能力”！

Rust标准库是个啥？为啥它上GPU这么难？

先来唠唠Rust这个语言。Rust特别聪明，它把自己的“标准库”这个工具箱，分成了三层，像搭积木一样。最底层叫“core”，是最基础的部分，啥操作系统啊、内存堆啊这些高级货它都不需要，光杆司令也能跑。往上一层是“alloc”，它加上了管理堆内存（就是那种可以随时申请一大块来用的内存）的能力。最顶层才是咱们通常说的“std”标准库，它最厉害，包含了文件操作、网络通信、多线程等等需要操作系统支持的高级功能。

Rust的妙处就在于，你可以根据情况选择用哪一层。如果你在给一个小单片机或者一个驱动程序写代码，那里没有完整的操作系统，你就可以声明“我不需要用std”，只用core或者alloc就行。这个特性让Rust能上天入地，从卫星到手表都能用。不过，当人们想把Rust代码放到GPU上运行时，就一直卡在这里：GPU没有操作系统，所以只能被迫使用“no_std”模式，也就是放弃最强大、最好用的那一层工具箱。这虽然也能跑，而且比别的语言环境已经强很多（很多为“no_std”环境写的开源库可以直接拿来用），但总觉得有点憋屈，很多现成的、好用的代码和库因为需要std就用不了。

时代变了！GPU也开始需要“系统服务”了

那么，为啥现在这事儿变得有可能而且有必要了呢？因为GPU的活儿越来越高级了！以前GPU主要就负责图形渲染，现在呢？人工智能、机器学习、大数据分析，这些重头戏都靠它。这些高级任务，可不仅仅是算算数就完事了，它们经常需要快速地读写数据、甚至通过网络获取信息。

于是，像英伟达这样的公司，就搞出了“GPUDirect存储”、“GPUDirect RDMA”这些黑科技，让GPU能够更直接地去访问硬盘和网络，不用老是麻烦CPU当中转站。苹果的M系列芯片、还有各种神经网络处理器（NPU）、张量处理器（TPU）的出现，都说明一个趋势：CPU和GPU的架构正在互相学习、互相靠近，它们之间的界限越来越模糊。

GPU正在变得越来越“像”一个功能更全面的处理器，那么，给它配上一些“系统服务”能力，也就顺理成章了。

VectorWare的魔法：“主机调用”

那VectorWare到底是怎么做到的呢？他们的核心技术叫做“主机调用”。这个名字听起来有点唬人，其实原理不难懂。你可以把它想象成GPU向CPU发出的一个“求助信号”或者“点单请求”。当GPU代码运行到某处，需要干一件自己干不了的事情（比如“打开那个叫‘资料.txt’的文件”），它就会通过一个设计好的通道，给CPU发个消息：“嘿，兄弟，帮我开个文件，路径是……”。CPU那边一直有个“服务生”在等着呢，一收到消息，就立刻动用自己操作系统的一切能力，去找到并打开那个文件，然后把结果（比如文件内容或者一个成功打开的句柄）再传回给GPU。GPU拿到结果后，就继续愉快地执行后面的代码。

对写代码的程序员来说，这一切都是自动的、看不见的。他们还是像以前一样，写 std::fs::File::open("资料.txt") 这样的代码，完全不用操心背后是GPU自己搞定的，还是CPU帮忙搞定的。

VectorWare团队很机智，他们为了让改动最小，选择在底层模拟了“libc”（一个C语言的标准库接口）的行为。Rust的标准库本来在Unix类系统上就是通过libc和操作系统打交道的，现在，在GPU环境下，就把这些libc调用“偷梁换柱”成向主机CPU发出的“主机调用”。这样，上层的Rust代码几乎不用改，就能在GPU上获得类似的功能。

看看这神奇的GPU代码！

光说不练假把式，来看一段真的能在GPU上跑的Rust代码吧！这段代码干的事可多了：先跟你打声招呼，然后请你输入名字，接着获取当前时间，最后还把一段话写进一个文件里。这一切，都是在显卡内部发生的！

rust
use std::io::Write;
use std::time::{SystemTime, UNIX_EPOCH};
 
#[unsafe(no_mangle)]
pub extern "gpu-kernel" fn kernel_main() {
    println!("Hello from VectorWare and the GPU!");
 
    print!("Enter your name: ");
    let _ = std::io::stdout().flush();
    let mut name = String::new();
    std::io::stdin().read_line(&mut name).unwrap();
 
    let name = name.trim_end();
    println!("Hello, {}! Nice to meet you from the GPU!", name);
 
    let now = SystemTime::now();
    let duration_since_epoch = now.duration_since(UNIX_EPOCH).unwrap();
    println!(
        "Current time (seconds since epoch): {}",
        duration_since_epoch.as_secs()
    );
 
    let msg = format!(
        "This file was created *from a GPU*, using the Rust standard library \n\
         We are {:?}\n\
         Current time (seconds since epoch): {}\n\
         User name: {}",
        "VectorWare".to_owned(),
        duration_since_epoch.as_secs(),
        name
    );
    std::fs::File::create("rust_from_gpu.txt")
        .unwrap()
        .write_all(msg.as_bytes())
        .unwrap();
 
    println!("File written successfully!");
}

是不是和你在普通电脑上写的Rust程序一模一样？唯一的区别就是开头那行 #[unsafe(no_mangle)] 和 extern "gpu-kernel"，这只是用来告诉编译器“喂，这是个GPU程序的入口点，名字别给我改乱了”。VectorWare说以后连这个标记都想办法去掉，让代码看起来更普通。想象一下，你的显卡内核不仅会算矩阵乘法，还会礼貌地问你叫啥、记住时间、并写日记，这画面是不是有点科幻？

“主机调用”不一定是主机干：灵活的分配策略

“主机调用”这个名字其实有点“名不副实”，因为它不一定非要主机（CPU）来响应。这个设计非常高明，它允许一种“渐进增强”的策略。随着GPU硬件和软件越来越牛，有些功能可以直接在GPU上实现，就不用劳烦CPU跑一趟了，这样速度更快。比如，获取一个高精度的计时时刻（std::time::Instant），如果GPU自己有高精度计时器（像CUDA的%globaltimer），那这个调用就直接在GPU内部消化了。但是，获取当前的日历时间（std::time::SystemTime），因为GPU自己没有“钟表”，这个请求还是得发给主机去问系统时间。

这种灵活性打开了更多高级玩法的大门。比如，GPU可以在自己这边搞个“缓存”，把一些从主机问来的结果（比如某文件的内容）存起来，下次再需要时直接读缓存，省得来回通信浪费时间。再比如，GPU甚至可以维护一个自己视角下的“虚拟文件系统”，需要的时候再和主机同步一下。他们甚至可以在不破坏现有代码的情况下，增加一些新特性，比如规定把文件写到“/gpu/tmp”这个路径，就意味着这个文件最好留在GPU内存里；或者发起一个网络连接到“localdevice:42”，其实就是和同一个GPU上的第42号线程块聊天。这些脑洞大开的想法，VectorWare说他们已经在探索了。

实现起来可不容易：细节决定成败

想法很美妙，但真要把这套系统做出来，并且做得又对又快，那可是个技术活。VectorWare的工程师们用了不少标准的GPU编程技巧来确保一切顺利。比如“双缓冲”技术，这有点像餐厅备菜，准备一套的同时，另一套已经在用了，保证供应不断档，用来避免GPU在等主机回信的时候干瞪眼。他们还用了原子操作来确保多个GPU线程同时发请求时不会乱套，数据不会“撕破”。整个通信协议设计得尽量简单，让GPU这边的逻辑负担轻一些。有时候，为了不让GPU在等主机的时候彻底阻塞，他们会利用CUDA的“流”这样的功能，让计算和通信重叠进行。主机那边的“服务生”代码，也是用Rust标准库写的，这样便于移植和测试。

作为以安全著称的Rust的践行者，VectorWare团队对正确性有执念。他们甚至把整个“主机调用”的运行时和内核代码，放在一个叫“miri”的Rust内存检查工具下跑过，用CPU线程来模拟GPU的行为，检查代码里有没有隐藏的内存错误。这种严谨的态度，让人对这项技术的可靠性更有信心。

目前，他们的实现主要面向使用Linux系统和NVIDIA显卡（通过CUDA）的环境。但他们说，这并没有根本性的限制，未来完全可以支持AMD显卡（通过HIP接口）或者Vulkan图形API。因为“主机调用”这个协议本身是通用的，不依赖于某一家厂商。

前人的探索和VectorWare的不同

其实，给GPU代码提供系统类API的想法，之前也有人尝试过。NVIDIA的CUDA本身就带了一个设备端的C/C++运行时库（比如libcu++），实现了很多标准库的功能。但那是专门为CUDA定制的，和C/C++绑定很深，而且并没有提供一个完整的、通用的操作系统抽象层，像文件系统、网络、墙上时钟这些，基本上还是得靠CPU。

还有一些研究项目，比如“GPU上的libc”，尝试把C语言的标准库调用转发给主机。VectorWare表示他们是在独立做出成果后，才发现有这些相似的工作，英雄所见略同嘛。但他们强调，自己的工作有两个关键的不同点。第一，他们直接瞄准了Rust的“std”标准库，而不是引入一套全新的、GPU专用的API。这样做最大的好处是“源代码兼容”，以前写的无数Rust库和代码，未来可能只需要极少的修改甚至不用改，就能在GPU环境下编译运行，这生态力量可就太恐怖了。第二，他们把“主机帮忙”这件事彻底藏在了标准库的实现背后，对程序员完全透明，而不是把它作为一个显式的、需要额外学习的编程模型。

所以说，这项工作的核心，与其说是发明了一个新的GPU运行时，不如说是把Rust已有的、强大的抽象能力，成功地扩展到了GPU这个异构计算的核心上。VectorWare的愿景是“把GPU带到Rust的世界里”，而不仅仅是“把Rust语言带到GPU上”。这个视角的转变，意义重大。

开源、融合与更多可能

VectorWare团队正在整理代码，准备把它开源出来。有意思的是，这个团队里有好几位本身就是Rust编译器团队的成员，所以他们非常希望能把这个成果融合到Rust的官方项目中去。当然，改动标准库是件大事，需要非常谨慎的审查和漫长的时间。

目前还有一个有趣的开放性问题：到底应该在哪里划这条抽象边界最合适？现在这个实现利用了“libc”这个现成的接口，改动小，见效快。但从长远看，是不是应该让Rust的标准库本身变得更“GPU感知”，通过更原生的Rust API来实现这些功能呢？那样可能更安全、效率也更高，当然，需要做的工作也更多。

最后，VectorWare也提到，他们作为一家公司，明白不是所有人都用Rust。他们未来的产品会支持多种编程语言和运行时环境。但是，他们坚信Rust在构建高性能、高可靠性的GPU原生应用方面，具有独特而强大的优势，这也是他们目前最兴奋的方向。

总之，Rust标准库成功登陆GPU，就像是给这个强大的计算引擎插上了翅膀，让它不仅能“算”，还能“感知”和“交互”。这为未来更复杂、更智能的GPU应用铺平了道路。也许不久的将来，由GPU主导的、具备完整系统服务能力的“协处理应用”会变得司空见惯。让我们拭目以待，看看VectorWare和开源社区接下来会带来什么更酷的玩意儿！

Rust std在GPU上的实现方案采用“主机调用”核心技术。其独特性在于直接集成Rust标准库而非创建新API，并与Rust编译器团队深度关联。