Hacker Newsnew | past | comments | ask | show | jobs | submit | tavianator's commentslogin


Presumably that's just a mistake. The author calls it "stochastic gradient descent" correctly elsewhere in the article


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


Oh that's cool. `find` is another tool I thought could benefit from io_uring like `ls`. I think it's definitely worth enabling io_uring for single threaded applications for the batching benefit. The kernel will still spin up a thread pool to get the work done concurrently, but you don't have to manage that in your codebase.


I did try it a while ago and it wasn't profitable, but that was before I added stat() support. Batching those is probably good


and grep / ripgrep. Or did ripgrep migrate to using io_uring already?


No, ripgrep doesn't use io_uring. Idk if it ever will.


Curious: Why? Is it not a good fit for what ripgrep does? Isn't the sort of "streaming" "line at a time" I/O that ripgrep does a good fit for async io?


For many workloads, ripgrep spends the vast majority of its time searching through files.

But more practically, it would be a terror to implement. ripgrep is built on top of platform specific standard file system APIs. io_uring would mean a whole heap of code to work with a different syscall pattern in addition to the existing code pattern for non-Linux targets.

So to even figure out whether it would be worth doing that, you would need to do a whole bunch of work just to test it. And because of my first point above, there is a hard limit on how much of an impact it could even theoretically have.

Where I would expect this to help is to batch syscalls during directory tree traversal. But I have nonidea how much it would help, if at all.


I believe that io_uring does not support getdents (despite multiple patch series being proposed). So you'd get async stat(), if you need them, but nothing else.


Oh. Well, that's definitely a deal breaker then. ripgrep already avoids stat calls on most files.


You may want to look into improvements to A* for grids, like Rectangular Symmetry Reduction.



If just use A*, but you rank open to loop for lowest (f, h) pairs, then the search frontier just dives despite having multiple optimal paths, as the new node tie-breaking ensures we prefer nodes that seem closest to the goal.


afaik jump point search would work for uniform cost grids but not if there's the exponential term that OP has



There was no active one. We saw this and thought it would be a nice nod to history. We've actually spoken to some developers at apple who thought this was really neat :)


They were referencing the title of a specific paper, which invented type classes: https://dl.acm.org/doi/10.1145/75277.75283


Thank you, I did not know this paper and totally missed the reference.


The C standard (since C99) says that `main()` has an implicit `return 0`, you don't need to write it explicitly.


Sure but are we teaching good habits to students, or are we golfing?


Given how many tutorials leave best practices out on how to do proper error handling, strings and arrays in C, doing analysis as part of the build, I would say golfing most of the time.


I was looking for a relevant paper and found this one, which isn't what I was looking for but is related: https://sigops.org/s/conferences/hotos/2023/papers/liargkova...


My actual "production" implementation of this concept does support that: https://github.com/tavianator/bfs/blob/main/configure

But I wanted the blog post sized version to be simpler for exposition.


Very nice


Just tried reconfiguring LLVM:

    27.24s user 8.71s system 99% cpu 36.218 total
Admittedly the LLVM build time dwarfs the configuration time, but still. If you're only building a smaller component then the config time dominates:

    ninja libc  268.82s user 26.16s system 3246% cpu 9.086 total


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: