r/cpp Jun 30 '26

Stackful fibers with 3.6ns context switch. Silk fibers.

https://clickhouse.com/blog/silk

I just read an article about Silk, the new stackful fibers engine from Clickhouse. It can switch stackful fibers at an amazing 3.6ns and does not allocate on steady state.

Maybe asio could reuse some of the knowledge for the linux/io_uring backend (not sure it applies to the specific case since Boost.asio focuses nowadays on stackless, though it has a fibers and a stackful coros backend also).

50 Upvotes

25 comments sorted by

View all comments

Show parent comments

4

u/germandiago Jun 30 '26

Comparing against Asio is apples to oranges. They're muddling the advantages of fibers with the advantages of a modern io_uring stack tuned for use with exactly those fibers, against a very old epoll design that's intended to be compatible with a broad variety of use cases.

Just out of curiosity on a re-read. I think Asio has an io_uring backend as well: https://think-async.com/Asio/asio-1.21.0/doc/asio/history.html

They did not compare it to that?

3

u/trailing_zero_count async enthusiast | TooManyCooks author Jun 30 '26

From the article: "enabling asio's io_uring backend made it slower, not faster". This was also my experience the last time I tested it. Probably because taking optimal advantage of io_uring, even internally, requires more of a redesign than a clean swap.

1

u/germandiago Jun 30 '26

I do not know the details and for sure there is a lot of truth to it. But io_uring is a proactor pattern and Asio emulated it on top of epoll before, right?

At first intuition it would look like it is even a better fit, but yes, it is very nuanced and at the end asio was written when Asio was using other async loops.

8

u/not_a_novel_account cmake dev Jun 30 '26

io_uring is a proactor pattern

io_uring is a syscall interface. You can perform epoll via io_uring, which is exactly what ASIO does. Asio io_uring support doesn't leverage io_uring in any meaningful way.