Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust’s Standard Library on the GPU

vectorware.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Rust’s Standard Library on the GPU

#11

Post by rao-v »

mkj wrote: post #5
nu11ptr wrote: post #2

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.

> 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)

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.

Re: Rust’s Standard Library on the GPU

#13

Post by kig »

koyote wrote: post #7

Are there any details around how the round-trip and exchange of data (CPU GPU) is implemented in order to not be a big (partially-hidden) performance hit? e.g. this code seems like it would entirely run on the CPU? print!("Enter your name: "); let _ = std::io::stdout().flush(); let mut name = String::new(); std::io::stdin().read_line(&mut name).unwrap(); But what if we concatenated a number to the string that was cal…

"We leverage APIs like CUDA streams to avoid blocking the GPU while the host processes requests.", so I'm guessing it would let the other GPU threads go about their lives while that one waits for the ACK from the CPU.

I once wrote a prototype async IO runtime for GLSL (https://github.com/kig/glslscript), it used a shared memory buffer and spinlocks. The GPU would write "hey do this" into the IO buffer, then go about doing other stuff until it needed the results, and spinlock to wait for the results to arrive from the CPU. I remember this being a total pain, as you need to be aware of how PCIe DMA works on some level: having your spinlock int written to doesn't mean that the rest of the memory write has finished.

Re: Rust’s Standard Library on the GPU

#14

Post by LegNeato »

nu11ptr wrote: post #2

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.

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

Re: Rust’s Standard Library on the GPU

#15

Post by LegNeato »

rao-v wrote: post #11
mkj wrote: post #5

Earlier quoted context omitted.

> 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)

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.

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.

Re: Rust’s Standard Library on the GPU

#16

Post by LegNeato »

koyote wrote: post #7

Are there any details around how the round-trip and exchange of data (CPU GPU) is implemented in order to not be a big (partially-hidden) performance hit? e.g. this code seems like it would entirely run on the CPU? print!("Enter your name: "); let _ = std::io::stdout().flush(); let mut name = String::new(); std::io::stdin().read_line(&mut name).unwrap(); But what if we concatenated a number to the string that was cal…

We use the cuda device allocator for allocations on the GPU via Rust's default allocator.

Re: Rust’s Standard Library on the GPU

#17

Post by monocasa »

mkj wrote: post #5
nu11ptr wrote: post #2

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.

> 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)

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).

Re: Rust’s Standard Library on the GPU

#19

Post by shihab »

To the author (or anyone from vectorware team), can you please give me, admittedly a skeptic, a motivating example of a "GPU-native" application?

That is, where does it truly make a difference to dispatch non-parallel/syscalls etc from GPU to CPU instead of dispatching parallel part of a code from CPU to GPU?

From the "Announcing VectorWare" page:

> Even after opting in, the CPU is in control and orchestrates work on the GPU.

Isn't it better to let CPUs be in control and orchestrate things as GPUs have much smaller, dumber cores?

> Furthermore, if you look at the software kernels that run on the GPU they are simplistic with low cyclomatic complexity.

Again, there's a obvious reason why people don't put branch-y code on GPU.

Genuinely curious what I'm missing.

Re: Rust’s Standard Library on the GPU

#20

Post by shihab »

the__alchemist wrote: post #8

I'm confused about this: As the article outlines well, Std Rust (over core) buys you GPOS-provided things. For example: - file system - network interfaces - dates/times - Threads, e.g. for splitting across CPU cores The main relevant one I can think which applies is an allocator. I do a lot of GPU work with rust: Graphics in WGPU, and Cuda kernels + cuFFT mediated by Cudarc (A thin FFI lib). I guess, running Std lib…

I work with GPUs and I'm also trying to understand the motivations here.

Side note & a hot take: that sort of abstraction never really existed for GPU and it's going to be even harder now as Nvidia et al races to put more & more specialized hardware bits inside GPUs

Post reply on HN