Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

lsr: ls with io_uring

rockorager.dev

Post reply on HN
Print view View original

91–100 of 177 posts

Re: lsr: ls with io_uring

#91

Post by fpoling »

richardwhiuk wrote: post #55
Imustaskforhelp wrote: post #16

Earlier quoted context omitted.

Yes I just checked it after installing strace strace -c ls gave me this 100.00 0.002709 13 198 5 total strace -c eza gave me this 100.00 0.006125 12 476 48 total strace -c lsr gave me this 100.00 0.001277 33 38 total So seeing the number of syscalls in the calls directory 198 : ls 476 : eza 33 : lsr A meaningful difference indeed!

That's just observing there is a difference, not explaining why that's a good thing.

syscalls are expensive and their relative latency compared with the rest of code only grow especially in view of mitigations against cache-related and other other hardware bugs.

Re: lsr: ls with io_uring

#92

Post by jeffbee »

rockorager wrote: post #83

Author of the project here! I have a little write up on this here: https://rockorager.dev/log/lsr-ls-but-with-io-uring

How much of the speedup over GNU ls is due to lacking localization features? Your results table is pretty much consistent with my local observations: in a dir with 13k files, `ls -al` needs 33ms. But 25% of that time is spent by libc in `strcoll`. Under `LC_ALL=C` it takes just 27ms, which is getting closer to the time of your program.

Re: lsr: ls with io_uring

#93

Post by mananaysiempre »

fpoling wrote: post #78
SillyUsername wrote: post #3

Love it. I'm trying to understand why all command line tools don't use io_uring. As an example, all my nvme's on usb 3.2 gen 2 only reach 740MB/s peak. If I use tools with aio or io_uring I get 1005MB/s. I know I may not be copying many files simultaneously every time, but the queue length strategies and the fewer locks also help I guess.

io_uring is the asynchronous interface and that requires to use even-based architecture to use it effectively. But many command-line tools are still written is a straightforward sequential style. If C would have async or similar mechanism to pretend doing async programming sequentially, it would be easier to port. But without that a very significant refactoring is necessary. Besides, io_uring is not yet stable and wh…

> If C would have async or similar mechanism to pretend doing async programming sequentially, it would be easier to port.

The *context() family of formerly-POSIX functions (clownishly deprecated as “use pthreads instead”) is essentially a full implementation of stackful coroutines. Even the arguable design botch of them preserving the signal mask (the reason why they aren’t the go-to option even on Linux) is theoretically fixable on the libc level without system calls, it’s just a lot of work and very few can be bothered to do signals well.

As far as stackless coroutines, there’s a wide variety of libraries used in embedded systems and such (see the recent discussion[1] for some links), which are by necessity awkward enough that I don’t see any of them becoming broadly accepted. There were also a number of language extensions, among which I’d single out AC[2] (from the Barrelfish project) and CPC[3]. I’d love for, say, CPC to catch on, but it’s been over a decade now.

[1] https://news.ycombinator.com/item?id=44546640

[2] https://users.soe.ucsc.edu/~abadi/Papers/acasync.pdf

[3] https://www.irif.fr/~jch/research/cpc-2012.pdf

Re: lsr: ls with io_uring

#94

Post by rockorager »

jeffbee wrote: post #92
rockorager wrote: post #83

Author of the project here! I have a little write up on this here: https://rockorager.dev/log/lsr-ls-but-with-io-uring

How much of the speedup over GNU ls is due to lacking localization features? Your results table is pretty much consistent with my local observations: in a dir with 13k files, `ls -al` needs 33ms. But 25% of that time is spent by libc in `strcoll`. Under `LC_ALL=C` it takes just 27ms, which is getting closer to the time of your program.

I didn't include `busybox` in my initial table, so it isn't on the blog post but the repo has the data...but I am 99% sure busybox does not have locale support, so I think GNU ls without locale support would probably be closer to busybox.

Locales also bring in a lot more complicated sorting - so that could be a factor also.

Re: lsr: ls with io_uring

#96

Post by JuettnerDistrib »

rockorager wrote: post #90
maplant wrote: post #52

This seems more interesting as demonstration of the amortized performance increase you'd expect from using io_uring, or as a tutorial for using it. I don't understand why I'd switch from using something like eza. If I'm listing 10,000 files the difference is between 40ms and 20ms. I absolutely would not notice that for a single invocation of the command.

Yeah, I wrote this as a fun little experiment to learn more io_uring usage. The practical savings of using this are tiny, maybe 5 seconds over your entire life. That wasn't the point haha

I'd be curious to know if this helps on supercomputers, which are notorious for frequently hanging for a few seconds on an ls -l.

Re: lsr: ls with io_uring

#97

Post by rockorager »

Bender wrote: post #12

I am curious what would happen if ls and other commands were replaced using io_uring and kernel.io_uring_disabled was set to 1. Would it fall back to an older behavior or would the ability to disable it be removed?

You would have to write your IO to have a fallback. The Ghostty project uses `io_uring`, but on kernels where it isn't available it falls back to an `epoll` model. That's all handled at the library level by libxev.

Re: lsr: ls with io_uring

#98

Post by yencabulator »

Bender wrote: post #12

I am curious what would happen if ls and other commands were replaced using io_uring and kernel.io_uring_disabled was set to 1. Would it fall back to an older behavior or would the ability to disable it be removed?

I just realized that one could probably write a userspace io_uring emulator in a library that spawns a thread to read the ringbuffer and a worker pool of threads to do the blocking operations. You'd need to get the main software to make calls to your library instead of the io_uring syscalls, that's it; the app logic could remain the same.

Then all the software wanting to use io_uring wouldn't need to write their low-level things twice.

Re: lsr: ls with io_uring

#99

Post by tavianator »

rockorager wrote: post #83

Author of the project here! I have a little write up on this here: https://rockorager.dev/log/lsr-ls-but-with-io-uring

My bfs project also uses io_uring: https://github.com/tavianator/bfs/blob/main/src/ioq.c

I'm curious how lsr compares to bfs -ls for example. bfs only uses io_uring when multiple threads are enabled, but maybe it's worth using it even for bfs -j1

Re: lsr: ls with io_uring

#100

Post by seanw444 »

nikodunk wrote: post #79
rkangel wrote: post #18

This was more interesting for the tangled.sh platform it's hosted on. Wasn't aware of that!

Same! Just signed up and will be following tangled and this repo. I like how tangled is built on atproto (bluesky).

Is there any actual focus on ATProto as a decentralized protocol? So far it seems like its only purpose is building Bluesky as a centralized service, which I have no interest in at all.
Post reply on HN