Async/Await on the GPU

https://www.vectorware.com/blog/async-await-on-gpu/

by Philpax • 5 months ago

228 48 5 months ago

shayonj• 5 months ago

Very cool to see this and something I have been curious about myself and exploring the space as well. I'd be curious what are some parallels and differentiations between this and NVIDIA's stdexec (outside of it being in Rust and using Future, which is also cooL)

zozbot2348• 5 months ago

I'm not quite seeing the real benefit of this. Is the idea that warps will now be able to do work-stealing and continuation-stealing when running heterogenous parallel workloads? But that requires keeping the async function's state in GPU-wide shared memory, which is generally a scarce resource.

LegNeato5• 5 months ago

Yes, that's the idea.

GPU-wide memory is not quite as scarce on datacenter cards or systems with unified memory. One could also have local executors with local futures that are `!Send` and place in a faster address space.

jmalicki• 5 months ago

A ton of GPU workloads require leaving large amounts of RAM resident on the GPU and running computation with some new data from the CPU.

pjmlp• 5 months ago

This is already happening in C++, NVidia is the one pushing the senders/receivers proposal, which is one of the possible co-routine runtimes to be added into C++ standard library.

nxobject• 5 months ago

God, as someone who took their elective on graphics program when GPGPU and computer shaders first became a thing, reading this makes me realize I definitely need an update on what modern GPU uarchs are like now.

Re: heterogenous workload: I'm told by a friend in HPC that the old advice about avoiding diverging branches within warps is no longer much of an issue – is that true?

zozbot2348• 5 months ago

That advice applies within warps, to single 'threads' (effectively SIMD lanes) whereas the article is consistently about running heterogenous tasks on different warps.

textlapse4• 5 months ago

What's the performance like? What would the benefits be of converting a streaming multiprocessor programming model to this?

LegNeato5• 5 months ago

We aren't focused on performance yet (it is often workload and executor dependent, and as the post says we currently do some inefficient polling) but Rust futures compile down to state machines so they are a zero-cost abstraction.

The anticipated benefits are similar to the benefits of async/await on CPU: better ergonomics for the developer writing concurrent code, better utilization of shared/limited resources, fewer concurrency bugs.

textlapse4• 5 months ago

warp is expensive - essentially it's running a 'don't run code' to maintain SIMT.

GPUs are still not practically-Turing-complete in the sense that there are strict restrictions on loops/goto/IO/waiting (there are a bunch of band-aids to make it pretend it's not a functional programming model).

So I am not sure retrofitting a Ferrari to cosplay an Amazon delivery van is useful other than for tech showcase?

Good tech showcase though :)

firefly20002• 5 months ago

Is this Nvidia-only or does it work on other architectures?

LegNeato5• 5 months ago

Currently NVIDIA-only, we're cooking up some Vulkan stuff in rust-gpu though.

monster_truck• 5 months ago

I don't have anything to offer but my encouragement, but there are _dozens_ of ROCm enjoyers out there.

In years prior I wouldn't have even bothered, but it's 2026 and AMD's drivers actually come with a recent version of torch that 'just works' on windows. Anything is possible :)

firefly20002• 5 months ago

Does the lack of forward progress guarantees (ITS) on other architectures pose challenges for async/await?

Arch485• 5 months ago

Very cool!

Is the goal with this project (generally, not specifically async) to have an equivalent to e.g. CUDA, but in Rust? Or is there another intended use-case that I'm missing?

zozbot2348• 5 months ago

The closest equivalent to that is rust-gpu, which this project is pretty closely involved with.

the__alchemist• 5 months ago

Et tu, GPU?

I am, bluntly, sick of Async taking over rust ecosystems. Embedded and web/HTTP have already fallen. I'm optimistic this won't take hold in GPU; well see. Async splits the ecosystem. I see it as the biggest threat to Rust staying a useful tool.

I use rust on the GPU for the following: 3d graphics via WGPU, cuFFT via FFI, custom kernels via Cudarc, and ML via Burn and Candle. Thankfully these are all Async-free.

notnullorvoid• 5 months ago

I don't see the utility of async on the GPU.

Async splits the ecosystem. I see it as the biggest threat to Rust staying a useful tool.

Someone somewhere convinced you there is a async coloring problem. That person was wrong, async is an inherent property of some operations. Adding it as a type level construct gives visibility to those inherent behaviors, and with that more freedom in how you compose them.

8note• 5 months ago

itd be interesting to see a setup where there's only async and you have to specify when you actually want to block on a result.

flip the colouring problem on its head

lmeyerov3• 5 months ago

For graphistry at least, I care less about the surface syntax (async/await) and more about getting gpu-side work stealing, dynamic task scheduling, etc. Our code is written at such a much higher level that these are primitives needed by our runtime, not most of our developers & users. Imagine SQL, cypher, etc on GPUs and our implementations of those being able to use the gpu-side libraries when coordinating 1M+ threads.

winwang• 5 months ago

Is it the performance benefits? Or being able to write concurrent code much more expressively? Though I suppose the latter might imply the former.

xiphias2• 5 months ago

Really cool experiment (the whole company).

Training pipelines are full of data preparation that are first written on CPU then moving to GPU and always thinking of what to keep on CPU and what to put on GPU, when is it worth to create a tensor, or should it be tiling instead. I guess your company is betting on solving problems like this (and async-await is needed for serving inference requests directly on the GPU for example).

My question is a little bit different: how do you want to handle the SIMD question: should a rust function be running on the warp as a machine with 32 long arrays as data types, or always ,,hope'' for autovectorization to work (especially with Rust's iter library helpers).

Cieric3• 5 months ago

I'm not even sure a 32 wide array would be good either since on AMD warps are 64 wide. I wouldn't go fully towards auto vectorization with though.

zozbot2348• 5 months ago

Warp SIMD-width should be a build-time constant. You'd be using a variable-length vector-like interface that gets compiled down to a specified length as part of building the code.

GZGavinZhao• 5 months ago

One concern I have is that this async/await approach is not "AOT"-enough like the Triton approach, in the sense that you know how to most efficiently schedule the computations on which warps since you know exactly what operations you'll be performing at compile time.

Here with the async/await approach, it seems like there needs to be manual book-keeping at runtime to know what has finished, what has not, and _then_ consider which warp should we put this new computation in. Do you anticipate that there will be measurable performance difference?

LegNeato5• 5 months ago

Doing things at compile time / AOT is almost always better for perf. We believe async/await and futures enables more complex programs and doing things you couldn't easily do on the GPU before. Less about performance and more about capability (though we believe async/await perf will be better in some cases, time will tell).

bob1029• 5 months ago

Doing things at compile time / AOT is almost always better for perf

https://devblogs.microsoft.com/dotnet/bing-on-dotnet-8-the-i...

zozbot2348• 5 months ago

If you can tell deterministically whether an 'async' computation is going to be finished, you can most likely use a type-system-like static analysis to ensure that programs are scheduled correctly and avoid any reference to values that are yet to be computed. But this is not possible in many cases, where dynamic scheduling will be preferable.

bionhoward• 5 months ago

genius, great idea and follow through, please keep it up, this could improve the ML industry tremendously, maybe some einops inspired interface for this would be good?

ismailmaj• 5 months ago

Warp specialization is an abomination that should be killed and I'm glad this could be an alternative.

I hope they can minimize the bookkeeping costs because I don't see it gain traction in AI if it hurts big kernels performance.

starkiller• 5 months ago

Love this.

You mention futures are cooperative and GPUs lack interrupts, but GPU warps already have a hardware scheduler that preempts at the instruction level. ARe you intentionally working above that layer, or do you see a path to a fture executor that hooks into warp scheduling more directly to get preemptive-like behavior?

lmeyerov3• 5 months ago

We have been curious about this for rapids cudf. We built the graphistry stack 10 years ago (!) for GPU native end-to-end acceleration - data loading, wrangling, analytics, enrichment, viz, etc, all the way server GPUs to client GPUs - but this has been a huge sticking point. Major constant overheads for smaller workloads that seem avoidable.

Essentially, we solved the problem of writing our stack in a bulk-oriented way that Nvidia kernels can optimize. Think apache arrow, pure vectorized dataframe pipelines, etc. However, cudf is 'eager' with per-step CPU/GPU control plane coordination, even if the data plane lives on the GPU. Polars in theory moves to lazy scheduling that can allow deforesting optimizations for more bulk GPU-side control macro steps, but not really. Nvidia efforts to cut python asyncio costs for multitenant etc flows didn't pan out either. So enabling moving more to the GPU here is super interesting.

Will be watching!

Panzerschrek• 5 months ago

AS I know GPUs execute code pretty fast as long as all threads in a warp go the same execution path. Branching causes performance degradation. But executing exactly the same code for multiple coroutines seems for me to be practically impossible. So, can good performance be reached with such approach at all?

ablob• 5 months ago

The short answer is yes. The post literally has an example of co-routines (think C-style: possible, but ugly). The difference here is how easy it is to write. I'd wager the question is not if it can be achieved, but for which use cases it can be ergonomic.

zozbot2348• 5 months ago

GPU 'threads' are SIMD lanes and this post does not discuss those. It's about running multiple GPU 'warps', i.e. hardware threads with separate control flow and code execution.

(Beyond that, "executing the same code" on multiple instances of a single coroutine ought to be sometimes possible on an opportunistic basis.)

michalsustr• 5 months ago

Very interesting. What is the runtime model, based on the "async trilema" https://without.boats/blog/the-scoped-task-trilemma/ ?

I assume tokio-like, i.e. work-stealing?

Jay_luci4• 5 months ago

The CPU to GPU dispatch overhead this aims to eliminate is a real bottleneck I've measured: my multi-pass Winograd kernel on MI300X (github.com/Jayluci4/nova-wino-amd) launches 3 HIP kernels + 1 rocBLAS GEMM per forward pass — 17-57% faster than MIOpen at batch=1, but at batch=8+ the dispatch latency between stages completely dominates and a fused single-dispatch kernel wins by 2-4x. On the AMD wavefront question: CDNA3's 64-lane wavefront vs NVIDIA's 32-lane warp changes the async scheduling model — you get 64-element register swaps via __shfl in one cycle (my transforms do full 8x8 matrix multiplies through wave shuffles with zero shared memory), but 64-wide means coarser divergence granularity for heterogeneous coroutine paths. An async execution model that pipelines multi-pass kernels without CPU round-trips would directly close the batch>1 gap for workloads like Winograd convolution, batched flash attention, and MoE expert dispatch. @magic_at_nodai — happy to help test AMD support when the time comes; I have working HIP kernels with wave shuffles and MFMA accumulation that would be a good real-workload stress test for the async dispatch model

Async/Await on the GPU

Related Stories