Hi! Let me introduce my new project "Massively".
Today, it's very common to build systems in Rust and GPU hardware is everywhere. However, coding parallel algorithms for GPUs is very hard. That's why I started massively, a GPU parallel algorithms library for Rust.
Similar library like NVIDIA's Thrust ever exists for CUDA ecosystem but it's for C++ and for NVIDIA GPUs only. That's why I build massively on top of CubeCL, a new abstraction layer for GPU programming.
Lot of improvements are done since the initial post above. Now Massively has support for lazy iterator for fuision and algorithms for segmented iterators.
Please see the latest rustdoc for what is available in Massively.
Hi akiradeveloper !
It is always nice to see this project, it is interesting and do you have compared to wgpu and your massively in speed/easy/coding ? Sorry I am new to Rust and I would like to know your thought about that ? 
If i use the Rust programming as regular, I will want to test your library for my games or 3D stuff for later, do you have an example of your demo running from your library like massively ?
Thanks for sharing and keep it up, dude, please !
Happy coding !
The lazy iterator fusion in the recent update is the part I'd want to understand best, because in my experience it's the thing that decides whether a Thrust-style API is usable in practice or not.
The failure mode with algorithm libraries at this level is that each call looks cheap in isolation and the transfer dominates everything. I've been building GPU aggregates against DuckDB on Metal and CUDA, and the number that ended up mattering most wasn't kernel throughput at all — the resident kernels run near the memory-bandwidth ceiling of the silicon either way, 563 GB/s on CUDA and 503 GB/s on Metal — it was how many times you touch the same buffer. A one-time upload took roughly 100 to 150 repeated queries to pay for itself. Under that, the CPU wins outright and it isn't close.
So the question: when you chain fused operations over the same input, does Massively keep the intermediate buffers resident on the device across the chain, and is there a way to pin an input buffer and reuse it across separate algorithm calls? Fusion within one expression is the obvious win, but the case I keep hitting is the same data being asked different questions over and over, which fusion inside a single chain doesn't help with.
Related, and this is the part I got wrong at first: whole-column min/max turned out to be a loss for me even fully resident, because the CPU side had zonemap statistics and could answer without scanning at all. It made me a lot more careful about which algorithms actually belong on the GPU versus which just look parallel. Does CubeCL give you any way to see that boundary, or is that necessarily the caller's problem?
Happy to run comparisons on an M4 Max and a 4090 Laptop if a benchmark shape would be useful to you — that's the hardware I have measured on for gpudb.