Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > the rust-gpu project has to emulate pointers[8], which we consider a blocking issue for most HPC benchmarks.
Why is it a blocking issue?
I feel like this is very aligned with the goals of rust-gpu.
by jasonjmcghee - Pointers are sort of needed for high performance memory management for HPC targets for existing design patterns, maybe we can think of better solutions down the line but it's hard for me to say anything I just use/abuse CUDA pointers as well.by minraws
- does anyone know Mojo well enough to comment how Rust + gpu-offload compares to it?by maxchisto
- Mojo is not fully open sourced yet, but it will eventually be, would be an interesting comparison though.
- > multi-vendor GPU compilation framework
Technically true, since it supports NVIDIA and AMD.
But we have a different definition of portability, if I cannot bring a Metal device and expect it to work.
by Archit3ch - I’ve been having success doing this with AdaptiveCpp (formerly OpenSYCL) bindings in Rust to get PG OLAP and geospatial workloads to run on a metal/cuda gpus - pure rust the whole way through sounds really nice!by contrahax
- is this mainly about making host binaries self-contained for heterogenous workloads?
also, seems like this is mostly targeted towards HPC audience?
- That's promising but did they publish any code? I can't find anything in the abstract.by Thomashuet
- It is a part of the rust codebase:
https://rustc-dev-guide.rust-lang.org/offload/internals.html https://github.com/rust-lang/rust/issues/131513
by supermatt - Ownership tracking should map well to GPU memory lifetimes. That's one place Rust has a real edge over C++.by Driftbench
- I write all my code in Rust because I am a Rustacean. In many of my custom LLM inference engine projects, the biggest fight has always been bindings. I don’t want to maintain and write bindings; also, if I use an existing project that provides bindings, then I have to wait for the owner to update or fork it and then maintain it on top. It has been a big headache. Running Rust core on GPU sounds like something I will try from day one. Kudos to the team and will watch it closely.by bicepjai
- > I write all my code in Rust because I am a Rustacean.
Why is Rust the only language to have literal acolytes? It's as if people believe they are part of some collective computer religion ushering in the messiah. Weird, man.
by MisterTea - So... why go through LLVM at all instead of having the MIR target PTX/HIP C directly then?
If they really wanted a vendor neutral solution for Rust GPU, that already exists: you write the CPU side code, including buffering, allocation, concurrency, etc through Vulkan binding and consume the compute kernel in SPIR-V from HLSL/GLSL/WGSL etc. As it stands, the way they use Rust here feels more like using it like TypeScript types/interfaces than anything else.
Again, the size of most operations that should be done on the GPU is known ahead of time before compilation, so it's very much possible to statically allocate memory at compile time instead of going through all this trouble to write what's essentially a Rust shaped DSL for GPU compute.
by YuechenLi - People go through trouble to write Python-shaped DSL for GPU compute. We will go "why o why?", but apparently such things are necessary to succeed in the market.by sanxiyn
- Because it's convenient? Shader and vulkan semantics can be quite limiting and annoying to write.
Maybe it doesn't matter in a post AI world but perhaps it will allow better abstractions.
No need to yuck someone else's yum.
by minraws - > This module is under active development. Once upstream, it should allow Rust developers to run Rust code on GPUs. We aim to develop a rusty GPU programming interface, which is safe, convenient and sufficiently fast by default. This includes automatic data movement to and from the GPU, in a efficient way. We will (later) also offer more advanced, possibly unsafe, interfaces which allow a higher degree of control.
I really appreciate the work and the effort that went into this. However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust?
by whateverboat - > However, such an approach has previously not really worked for C++ with LLVM offload
... isn't Metal shading language just C++17 compiled with LLVM ? working on every Mac and iPhone in the world is not what I would call "not really worked". Likewise, SYCL works just fine.
by jcelerier - Seems to work out well for Mojo, so I'd guess it's more an issue with C++.by boxed
- > However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust?
I think that will depend on the exact reason(s) C++ with LLVM offload didn't work out? If Rust differs from C++ in a way that addresses pain points/failure modes/etc. from the C++ attempt, for instance, then perhaps it isn't unreasonable to think Rust could succeed where C++ didn't (c.f., Mozilla's pre-Rust attempts to parallelize Firefox's CSS styling engine). Inversely, if Rust doesn't do things differently in the right way perhaps one might expect the effort to also not work out. Or maybe the problems are entirely non-technical and things could work out in either language.
by aw1621107 - > However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust?
They're very different languages, with different semantics. Without reading more than the synopsis of the paper, they're 100% leveraging the substructural type system and will have a really tight requirement for you to use a certain kind of Rust code at the CPU/GPU boundary.
by ux266478