YHK - yet another hacker news clone

We Replaced MMAP with Io_uring in Our Rust Query Engine. It Got Slower

17 points rzk 2 hours ago 9 comments

nottorp 27 minutes ago | parent

Yay, first article (for me!) that i actually click on because the title is interesting, and then it puts me off because it's LLM generated.

By the way, what does Rust have to do with their problem? Is Rust simply bad at io_uring? :)

cbarnes99 23 minutes ago | parent

Rust is just the language they happened to be working in. If you read through the LLM generated garbage it becomes clear that io_uring isnt the problem, their code was just slop / bad.

nottorp 13 minutes ago | parent

That was hinted at in the summary for part 2, which i couldn't bring myself to click on.

But my interpretation is still more fun!

orlp 7 minutes ago | parent

We had a similar experience in Polars trying to use io_uring.

Rust isn't inherently bad at io_uring but at least Tokio currently is. I'm not the one who implemented and benchmarked it so this is second-hand information but if I recall correctly Tokio shares one buffer pool for all threads so as you scale to 100+ threads the whole thing grinds to a halt.

Migrating our I/O to a different async runtime than Tokio was rejected. So we'll wait until it's fixed in Tokio and now use regular blocking reads instead.

muragekibicho 23 minutes ago | parent

The article's subheadings suggest this is AI slop. Seeing a section titles "The Production Symptom" is a Claudism in itself.

wolfi1 15 minutes ago | parent

production symptom? is this equivalent to "kidney disappointment"?

samus 21 minutes ago | parent

It would have been more precise to say O_DIRECT instead of io_uring. The point of io_uring is to avoid syscall overhead. What they were after was actually managing a page cache on their own, and it turned out to be more complicated than they thought.

londons_explore 7 minutes ago | parent

There is a pattern in software engineering of:

* Project exists

* New employees come up with idea for efficiency improvement

* Months spent implementing. Old codepath becomes legacy.

* New thing now has extra features bolted on during build.

* Efficiency of new thing turns out worse than original, but now the new features and 'less technical debt' are the drivers.

* New thing launches, old thing deprecated, but there is little real benefit to all those months of work.

jandrewrogers 4 minutes ago | parent

An issue here is that mmap and io_uring require fundamentally different software architectures in a performance context. You shouldn’t swap them out.

APIs like io_uring, combined with O_DIRECT, allow you to design your own workload-specific userspace scheduler from first principles. If you are delegating scheduling to a runtime then you’ve forfeited most of the performance advantages those APIs were designed to provide. In many cases, the performance will be worse. By contrast, mmap implicitly delegates all scheduling decisions and it has some advantages if delegation is your strategy compared to a runtime.

The benefits of io_uring are limited without a commitment to designing your own schedulers. On the upside, skilled scheduler designers can increase performance by substantial integer factors using these APIs versus mmap. Designing application-specific schedulers is not easy, it is a high-skill endeavor. But the reward is real.

Using io_uring well requires going all-in on the software architecture it requires to show what it can do.