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

21–30 of 177 posts

Re: lsr: ls with io_uring

#21

Post by quibono »

Lovely, I might try doing this for some other "classic" utility!

A bit off-topic too, but I'm new to Zig and curious. This here: ``` const allocator = sfb.get();

    var cmd: Command = .{ .arena = allocator };
``` means that all allocations need to be written with an allocator in mind? I.e. one has to pick an allocator per each memory allocation? Or is there a default one?

Re: lsr: ls with io_uring

#22

Post by danbruc »

Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? It seems pretty annoying to have to install replacements for the most basic command line tools. And especially in this case, where you do not even do it for additional features, just for getting the exact same thing done a bit faster.

Re: lsr: ls with io_uring

#23

Post by nailer »

danbruc wrote: post #22

Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? It seems pretty annoying to have to install replacements for the most basic command line tools. And especially in this case, where you do not even do it for additional features, just for getting the exact same thing done a bit faster.

`ls` is in C, `lsr` is in Zig. The `lsr` programmer probably doesn't want to make new code in C.

Re: lsr: ls with io_uring

#24

Post by kristoff_it »

quibono wrote: post #21

Lovely, I might try doing this for some other "classic" utility! A bit off-topic too, but I'm new to Zig and curious. This here: ``` const allocator = sfb.get(); var cmd: Command = .{ .arena = allocator }; ``` means that all allocations need to be written with an allocator in mind? I.e. one has to pick an allocator per each memory allocation? Or is there a default one?

Allocator is an interface so you write library code only once, and then the caller decides which concrete implementation to use.

There's cases where you do want to change your code based on the expectation that you will be provided a special kind of allocator (e.g. arenas), but that's a more niche thing and in any case it all comes together pretty well in practice.

Re: lsr: ls with io_uring

#25

Post by mschuster91 »

danbruc wrote: post #22

Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? It seems pretty annoying to have to install replacements for the most basic command line tools. And especially in this case, where you do not even do it for additional features, just for getting the exact same thing done a bit faster.

> Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring?

Good luck getting that upstreamed and accepted. The more foundational the tools (and GNU coreutils definitely is foundational), the more difficult that process will be.

Releasing a standalone utility makes iteration much faster, partially because one is not bound to the release cycles of distributions.

Re: lsr: ls with io_uring

#26

Post by tiagod »

danbruc wrote: post #22

Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? It seems pretty annoying to have to install replacements for the most basic command line tools. And especially in this case, where you do not even do it for additional features, just for getting the exact same thing done a bit faster.

You don't have to install it. You can modify ls yourself too.

Re: lsr: ls with io_uring

#27

Post by adgjlsfhk1 »

It's a shame to see uutils doing so poorly here. I feel like they're our best hope for an organization to drive this sort of core modernization forward, but 2x slower than GNU isn't a good start.

Re: lsr: ls with io_uring

#28

Post by loeg »

nailer wrote: post #23
danbruc wrote: post #22

Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? It seems pretty annoying to have to install replacements for the most basic command line tools. And especially in this case, where you do not even do it for additional features, just for getting the exact same thing done a bit faster.

`ls` is in C, `lsr` is in Zig. The `lsr` programmer probably doesn't want to make new code in C.

In addition, the author might not want to sign away their rights to the FSF.

Re: lsr: ls with io_uring

#29

Post by [deleted] »

danbruc wrote: post #22

Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? It seems pretty annoying to have to install replacements for the most basic command line tools. And especially in this case, where you do not even do it for additional features, just for getting the exact same thing done a bit faster.

[deleted]

Re: lsr: ls with io_uring

#30

Post by vlovich123 »

Retr0id wrote: post #20
tyingq wrote: post #15

Earlier quoted context omitted.

Probably historical preference for portability without a bunch of #ifdef means platform+version-specific stuff is very late to get adopted. Though, at this point, the benefit of portability across various posixy platforms is much lower.

Has anyone written an io_uring "polyfill" library with fallback to standard posix-y IO? It could presumably be done via background worker threads - at a perf cost.

Seems like a huge lift since io_uring is an ever growing set of interfaces that is encompassing more and more of the kernel surface area. Also, the problem tends to not necessarily be that the io_uring interface isn’t available at compile time but a) the version you distribute to has a kernel with it disabled or you don’t have permission to use it meaning you need to do LD_preload magic or use a framework b) the kernel you’re using supports some of the interfaces you’re trying to use but not all. Not sure how you solve that one without using a framework.

But I agree. It would be cool if it was transparent, but this is actually what a bunch of io-uring runtimes do, using epoll as a fallback (eg in Rust monoio)

Post reply on HN