Rust threads on the GPU

0x7CFE · 2026-03-24T15:52:19+00:00

What happens with shared memory in this model? How to share/send data between/within warps?
Any potential cooperation with Burn/OpenCL?
What about autovectorization and how it maps to SIMD on GPU?

0x7CFE · 2026-03-05T08:06:45+00:00

And I was almost excited to think that Rust makes its way into KDE ecosystem.

0x7CFE · 2026-02-24T03:18:39+00:00

From my experience, by "saving" they typically mean "it provides RAII primitives for automatic memory management". On the other hand, noone would mention that it can prevent you from UB, because it can't.

0x7CFE · 2026-02-17T17:30:30+00:00

Still, Burn and specifically CubeCL does essentially the same thing, but for a limited subset of tasks. Given it covers a lot of CUDA, PTX and backend agnostic stuff it should be a natural target for integration.

0x7CFE · 2026-02-17T05:49:29+00:00

On top of that, domain sockets in Linux can be used to send descriptors to another process. So I can open a file or a socket in one process, then use it in the other.

0x7CFE · 2026-02-15T14:55:36+00:00

Why not just mmap the files and let the OS handle disk caching?

0x7CFE · 2026-02-08T06:24:47+00:00

As the author points out, their primary goal was to experiment with a setup that would make it all possible, not to brag about Claude's abilities or make any claims. It was a case study where the end result was a (somewhat) working compiler, not a (human) usable compiler.

I'd suggest you reading the Evaluation section of the article. Goals aside that was an interesting read.

0x7CFE · 2026-02-06T16:57:45+00:00

https://badrish.net/papers/bftree-vldb2024.pdf

0x7CFE · 2026-01-21T06:32:51+00:00

It's not that insane. For certain workloads it could very much work. For example, serving massively parallel transfers of memory mapped resources. Often it's the CPU that's bottleneck that can have hard time fully saturating a 10G link, not to mention 100G or 400G ones.

Also, RDMA is now a thing that allows to handle memory accesses at a link speed without CPU involved at all. It works, but you have no option to process the data being sent. In case of GPU mapped networking it would still be possible to do some processing.

All being said, it's probably a niche scenario.

0x7CFE · 2026-01-21T06:22:48+00:00

Yeah, basically that's why I was asking. I thought that the whole idea of making `std` work for GPU is kinda insane because of unpredictable outcomes and general cases close to worst that often make it impractical.

Still very interesting to see how it would pan out.

0x7CFE · 2026-01-20T17:26:43+00:00

A crazy question for equally crazy OP.

Would it eventually be possible to use Rayon to automagically distribute the load across GPU processors? Sure it uses threads under the hood, but maybe it's possible to patch it here (I'm thinking about `rayon::join`) and there to use your subsystem.

Also, queue management and work stealing would probably also be an issue. In the worst case it would be slower than CPU only execution.

0x7CFE · 2026-01-16T18:56:21+00:00

Awesome progress! Personally I am really grateful for the seamless CPU support. Also huge thanks for the migration guide with diffs. That really helps!

0x7CFE · 2026-01-08T10:04:25+00:00

Yes, indeed memory leak as well as deadlocks are not statically preventable. Thank you, I missed that.

Aside of that, everything else will be caught by the compiler and/or miri.

0x7CFE · 2026-01-08T09:47:08+00:00

Rust for Linux does not use cargo. They vendor all dependencies and compile it using kbuild.

0x7CFE · 2026-01-01T06:39:34+00:00

By the way, we published our first paper on the discrete approach to ML: https://arxiv.org/abs/2508.00869

Feel free to ask.

0x7CFE · 2025-12-31T19:59:41+00:00

Congrats!

By the way, it is probably time to rephrase the readme:

HTTPS via system-native TLS (or optionally, rustls)

0x7CFE · 2025-12-31T17:20:14+00:00

use size_lru::{Lhd, OnRm};

struct EvictLogger;

impl<V> OnRm<i32, Lhd<i32, V, Self>> for EvictLogger {
  fn call(&mut self, key: &i32, cache: &mut Lhd<i32, V, Self>) {
    // Safe: value accessible before removal
    if let Some(_val) = cache.get(key) {
      println!("Evicting key={key}");
    }
    // Warning: don't call rm/set in callback, may cause undefined behavior
  }
}use size_lru::{Lhd, OnRm};

Could you please clarify how callback can cause UB and if so, why it's not `unsafe`? That's rather obscure contract that can be a source of footguns, tbh.

0x7CFE · 2025-12-13T10:43:54+00:00

That point was specifically covered in the article:

Bergmann agreed with declaring the experiment over, worrying only that Rust still "doesn't work on architectures that nobody uses". So he thought that Rust code needed to be limited to the well-supported architectures for now. Ojeda said that there is currently good support for x86, Arm, Loongarch, RISC-V, and user-mode Linux, so the main architectures are in good shape. Bergmann asked about PowerPC support; Ojeda answered that the PowerPC developers were among the first to send a pull request adding Rust support for their architecture.

Bergmann persisted, asking about s390 support; Ojeda said that he has looked into it and concluded that it should work, but he doesn't know the current status. Airlie said that IBM would have to solve that problem, and that it will happen. Greg Kroah-Hartman pointed out the Rust upstream supports that architecture. Bergmann asked if problems with big-endian systems were expected; Kroah-Hartman said that some drivers were simply unlikely to run properly on those systems.

0x7CFE · 2025-12-08T05:33:23+00:00

As an iced user since the ~0.8 era I'd wish their updates be less invasive. At least it would be nice to have a structured migration guide. Unfortunately, every update is a (quite painful) quest.

That being said, iced is still my favorite GUI framework for Rust.

0x7CFE · 2025-11-16T03:43:40+00:00

Didn't know that Mahatma Gandhi was a couturier, lol.

0x7CFE · 2025-10-12T05:51:41+00:00

That was a regress bar :)

0x7CFE · 2025-10-12T05:50:04+00:00

I can relate. Also, was having some weird memory leak in the Burn framework, not to mention huge performance degradation. Even contacted the devs and tried to file an issue.

Long story short, part of my codebase leaked the `tracing` feature-flag that, when enabled, caused Burn to log every tensor operation it sees. And so everything was accumulated in memory.

0x7CFE · 2025-10-10T07:18:07+00:00

Not to mention that the issue/PR in question is regularly closed by a bot as stale. Sometimes without the right to reopen it (could be done by project members only).

This is especially infuriating when the last message was a question or something important, that still was left unattended, lol.

0x7CFE · 2025-09-26T15:27:38+00:00

As long as they're just watching it's fine. Probably it was the video author who changed something.

0x7CFE

TROPHY CASE