I feel like the title is a bit misleading. I think it should be something like "Using Rust's Standard Library from the GPU". The stdlib code doesn't execute on the GPU, it is just a remote function call, executed on the CPU, and then the response is returned. Very neat, but not the same as executing on the GPU itself as the title implies.

▲

mkj 8 hours ago | parent | next [-]

> For example, std::time::Instant is implemented on the GPU using a device timer

The code is running on the gpu there. It looks like remote calls are only for "IO", the compiled stdlib is generally running on gpu. (Going just from the post, haven't looked at any details)

▲

monocasa 3 hours ago | parent | next [-]

Which is a generally valid implementation of IO. For instance on the Nintendo Wii, the support processor ran its own little microkernel OS and exposed an IO API that looked like a remote filesystem (including plan 9 esque network sockets as filesystem devices).

▲

rao-v 6 hours ago | parent | prev [-]

I'm surprised this article doesn't provide a bigger list of calls that run on the gpu and further examples of what needs some cpu interop.

	▲	LegNeato 5 hours ago \| parent [-]
		Flip on the pedantic switch. We have std::fs, std::time, some of std::io, and std::net(!). While the `libc` calls go to the host, all the `std` code in-between runs on the GPU.

▲

kjuulh 9 hours ago | parent | prev | next [-]

I think it fits quite well. Kind of like the rust standard lib runs on the cpu this does partially run on the gpu. The post does say they fall back on syscalls but for others there a native calls on the gpu itself such as Instant. The same way the standard lib uses syscalls on the cou instead of doing everything in process

▲

LegNeato 5 hours ago | parent | prev [-]

Author here! Flip on the pedantic switch, we agree ;-)