cuda-oxide er bygd som en custom rustc codegen-backend. Med #[cuda_module] markerer du en modul som GPU-kode; #[kernel] markerer hver kjerne. Kompilatoren genererer en typesikker kernels::load-funksjon og én lanseringsmetode per kjerne, og embedder PTX-en i host-binæren. Lavere-nivå-APIene load_kernel_module og cuda_launch! er tilgjengelige hvis du trenger å laste sidecar-artefakter eller bygge custom launch-kode.
Eksempel-vecadd ser slik ut:
#[cuda_module]
mod kernels {
use super::*;
#[kernel]
fn vecadd(a: &[f32], b: &[f32], mut c: DisjointSlice<f32>) {
let idx = thread::index_1d();
let i = idx.get();
if let Some(c_elem) = c.get_mut(idx) {
*c_elem = a[i] + b[i];
}
}
}
GPU-arbeidet komponeres som late DeviceOperation-grafer som schedules på stream pools, og resultater ventes på med .await. Det matcher hvordan tokio-folk er vant til å tenke om async, bare at det er CUDA-streams under.
Safety er førsteklasses mål, men dokumentasjonen understreker selv «safe(ish)». GPU-eierskapsmodellen er ikke identisk med Rust-CPU. DisjointSlice er et eksempel: det gir aliasing-frihet på tvers av tråder uten lifetime-tricks som ikke kan oversettes til SIMT.
For norske Rust-utviklere som har vurdert HPC eller maskinlæring, men ikke ville bytte til Python pluss en tynn Rust-wrapper, er dette første gang verktøykjeden er sanksjonert av Nvidia selv. Det utelukker ikke andre veier; cust og rust-gpu finnes, men 0.1.0-banneret over et nvlabs-domene flytter forventningsbildet.
Hva bør du gjøre?
- Sjekk prereqs før installasjon. Du trenger CUDA toolkit installert lokalt, og Rust nightly er sannsynlig for codegen-backenden. Les
getting-started/installationfør du kloner. - Behold cust eller rust-gpu hvis du allerede har en stabil stack. 0.1.0 er alpha. API-bryting er ventet, bytt etter at 0.2 lander.
- Test
cargo oxide runpå en vecadd du allerede har optimalisert i C++. En direkte ende-til-ende-sammenligning er det raskeste svaret på om compiler-output er konkurransedyktig.