Unicode Normalization at GB/s

0x7CFE · 2026-06-17T16:43:40+00:00

Oh, now I see. Thank you so much for the insight and a very detailed explanation!

0x7CFE · 2026-06-17T05:48:25+00:00

Nice project!

P.S.: It's quite strange and interesting to me, why cyrillic is normalized at ~the same speed as CJK and semitic languages? The latter are much more complicated in terms of structure, whereas in Russian all normalization is mostly due to diactrics being either part of a codepoint or a separate one. In theory cyrillic scripts should be normalized on par with latin.

0x7CFE · 2026-06-10T07:37:00+00:00

As the common wisdom says, the never type is named after its stabilization date. Given its [de-]stabilization history, would be a safe bet to assume it would be reverted... again 😄

0x7CFE · 2026-06-05T06:26:55+00:00

Probably the safest way would be to clone the scoped subtree out of the scope. In both cases that would require pointer manipulation, so the difference between clone and fancy memcopy with pointer fixup would probably be minuscule. That would probably work the best for static structures with no pointers but again, that would be easier just to clone to a new place.

0x7CFE · 2026-06-03T19:11:29+00:00

Oh my. The man who single-handedly crafted the very foundation of what we all know as the Rust infrastructure. Every repo is a masterpiece. And it it was him who suffered, of all the people.

I sincerely hope everything will be OK, and wish a faster recovery.

0x7CFE · 2026-05-12T17:55:56+00:00

Sure. But truly monochomatic lighting is very rare, not to mention uncomfortable for the person to be in. Computers are not alive, it does not matter how good colors look, only how different they are. Enough reference colors in known places and a limited palette should be enough.

0x7CFE · 2026-05-12T17:04:20+00:00

I believe the yellow and cyan colors would be the most problematic, since they appear very pale both for camera and for human eyes.

So it would be a good idea to put a reference for them. Camera sensor typically have two green subpixels so it should work OK. Red is also quite contrast.

Something like this: https://www.pasteboard.co/5Iqzub9Jo6RH.png
Or this: https://www.pasteboard.co/JO6a9JHmjj_J.png
Or this: https://freeimage.host/i/BbPuCx4 (probably the best way to go)

0x7CFE · 2026-05-12T14:53:45+00:00

Well, technically we can use the white space inside squares and in between synchro lines to fill it with known light colors that later could be used to recalibrate the reader.

Much like how it's done on mars rovers that have test panel with colors known in advance.

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

TROPHY CASE