// the take
A small C++/CUDA extension for PyTorch providing scatter and segment reduce operations (sum/mean/min/max) that aren't in core PyTorch, plus composite ops like softmax and logsumexp built on top. It's a foundational dependency for PyTorch Geometric and anyone doing graph/point-cloud work with irregular, index-based aggregation.
Kernels are hand-written per backend (CPU and CUDA) with matching backward passes, not just a thin wrapper around existing ops, so it's genuinely faster than doing the equivalent with masked scatter_add loops. segment_csr using compressed pointers avoids the sorting/argsort overhead that segment_coo and plain scatter need for the same reduction. The composite ops (scatter_softmax, scatter_log_softmax, scatter_std) are a real convenience since getting numerically stable softmax over variable-length groups right by hand is easy to mess up.
Being a native extension means you're pinned to an exact torch+CUDA+Python wheel combination from data.pyg.org; drift off that matrix and you're compiling from source with nvcc and TORCH_CUDA_ARCH_LIST fiddling, which is a recurring source of CI and Docker pain in the PyG ecosystem. Since PyTorch 1.12 shipped torch.scatter_reduce_ and index_reduce_ natively, a chunk of this library's core use case now has a built-in, better-maintained alternative, so its long-term relevance is shrinking even as it's still the faster option for segment ops specifically. It's effectively a single-maintainer project (rusty1s, same as PyG itself), so bus-factor risk is real for something this deep in the dependency tree. No Python-only fallback path exists if you can't get a matching binary and can't build native extensions (e.g. restricted CI environments).
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →