Vectorware – From Creators of `rust-Gpu` and `rust-Cuda`
Posted3 months agoActive3 months ago
vectorware.comTechstory
calmmixed
Debate
60/100
GPU ComputingRust Programming LanguageSoftware Development
Key topics
GPU Computing
Rust Programming Language
Software Development
VectorWare, a company founded by creators of rust-GPU and rust-CUDA, announces its mission to develop GPU-native software, sparking discussion about the current state of GPU applications and the potential for improvement.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
21m
Peak period
11
0-2h
Avg / period
3
Comment distribution24 data points
Loading chart...
Based on 24 loaded comments
Key moments
- 01Story posted
Oct 23, 2025 at 11:41 AM EDT
3 months ago
Step 01 - 02First comment
Oct 23, 2025 at 12:03 PM EDT
21m after posting
Step 02 - 03Peak activity
11 comments in 0-2h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 24, 2025 at 12:23 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45683153Type: storyLast synced: 11/20/2025, 7:50:26 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> If you look at existing GPU applications, their software implementations aren't truly GPU-native. Instead, they are architected as traditional CPU software with a GPU add-on.
I feel that this is due to the current hardware architecture, not the fault of software.
(Don't miss the "Pedantic mode" switch on the linked page, it adds relevant and detailed footnotes to the blog post.)
We’re talking at least hundreds of thousands of cells, depending on the calculation, or at least a number that will make the UI very sad long before you’ll see a slowdown from calculation.
Databases, on the other hand…
If you have a Rust application or library and want to use the GPU, these approaches are comparatively smooth:
I am using WGPU and Cudarc for structural biology + molecular dynamics computations, and they work well.Rust - CUDA feels like lots-of-PR, but not as good of a toolkit as these quieter alternatives. What would be cool for them to deliver, and I think is in their objectives: Cross-API abstractions, so you could, for example, write code that runs on Vulkan Compute in addition to CUDA.
Something else that would be cool: High-level bindings to cuFFT and vkFFT. You can FFI them currently, but that's not ideal. (Not too bad to impl though, if you're familiar with FFI syntax and the `cc` crate)
wgpu, ash, and cudarc are great. We're focusing on the actual code that runs on the GPU in Rust, and we work with those projects. We have cust in rust-cuda, but that existed before cudarc and we have been seriously discussing just killing it in favor of cudarc.
We didn't post this or the title, we would never claim we created the projects from scratch.
I routinely have to fix the autoformating done by HN.
seems like embark has disembarked from Rust and support for it altogether
2. Can modern GPU hardware efficiently make system calls? (if you can do this, you can eventually build just about anything, treating the CPU as just another subordinate processor).
3. At what order-of-magnitude size might being GPU-native break down? (Can CUDA dynamically load new code modules into an existing process? That used to be problematic years ago)
Thinking about what's possible, this looks like an exceptionally fun project. Congrats on working on an idea that seems crazy at first glance but seems more and more possible the more you think about it. Still it's all a gamble of whether it'll perform well enough to be worth writing applications this way.
2. Yes
3. We're still investigating the limitations. A lot of them are hardware dependent, obviously data center cards have higher limits more capability than desktop cards.
Thanks! It is super fun trailblazing and realizing more of the pieces are there than everybody expects.
But, languages like Java or python simply lack even programming constructs to program on GPUs easily.
No standardised ISA on GPUs also mean compilers can’t really provide a translation layer.
Let’s hope things get better over time!
https://modal.com/docs/examples/batched_whisper
> We are building software that is GPU-native. We intend to put the GPU in control. This does not happen today due to the difficulty of programming GPUs, the immaturity of GPU software and abstractions, and the relatively few developers targeting GPUs.
Really feels like fad engineering. The CPU works better as a control structure and the design of GPUs are not fitted for proper orchestration compared to CPUs. What really worries me is their mention of GPU abstractions, which is completely the wrong way to think about hardware designed for HPC. Their point about PyTorch. and kernels having low cyclomatic complexity is confusing to me. GPUs aren't optimize for control flow. The nature of SIMD/SIMT values throughput and the hardware design forgoes things like branch prediction. Having many independent paths a GPU kernel could take would make it perform much worse. You could very well end up with kernels that are slower than their optimize CPU counterparts.
I'm sure the people behind this are talented and know what they're doing, but these statements don't make sense to me. GPU algorithms are harder to reason about and implement. You often need to do more work just to gain the parallizable benefit. There aren't actually that many use cases were the GPU being the primary compute platform is a better choice. My cynical view is that people like the GPU because they compare unoptimize slow CPU code with decent GPU/tensorized code. They never see how much a modern CPU can actually do, and how fast it can be.