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

Asynchronous IO: the next billion-dollar mistake?

yorickpeterse.com

Post reply on HN
Print view View original

151–160 of 165 posts

Re: Asynchronous IO: the next billion-dollar mistake?

#151

Post by yencabulator »

torginus wrote: post #147
yencabulator wrote: post #137

Earlier quoted context omitted.

The "world" these days works by ringbuffers and interrupts, neither of which looks like async/await. Async/await is a chosen abstraction over what hardware/kernel interfaces really look like.

Well, async/await in languages is just promises/futures made to look like regular flow control via state machines. And promises are controlled via callbacks, which are called from some event. It's essentially the same thing as when you get an interrupt from your microcontroller's DMA engine that the ring buffer needs to be refilled, just with 2 layers of abstractions on top to make it look nicer.

So you agree this to be wrong, then..

> Asynchronous IO is just simply how the world works.

How the world works looks more like message passing. What abstraction you construct on top of that is a choice. Async/await is not necessarily the global maxima.

Re: Asynchronous IO: the next billion-dollar mistake?

#152

Post by FridgeSeal »

kaba0 wrote: post #122
BenoitP wrote: post #68

Earlier quoted context omitted.

Thanks for putting words into this. Another cut off could be 3 cm away: the RAM. If data needs to go on the heap, be shared, one can consider the truth lives farther away than 3cm and thus has async/impure effects.

But the same way the CPU works very hard to hide that away from you (reordering, caches, etc), green threads could do the same with barely any performance hit.

Which is fine until we decide that actually, we _would_ like that performance back, and now we re-implement async flows at language level again, realise what an advantage it’s bets us, and then that trickles into other languages as they also seek those advantages.

Re: Asynchronous IO: the next billion-dollar mistake?

#153

Post by lmz »

nullindividual wrote: post #144
wtallis wrote: post #20

Earlier quoted context omitted.

The same Windows NT whose decades-old async IO capabilities are so good they immediately cloned io_uring?

Yes, it is nearly a 1:1 copy of io_uring, but unlike io_uring which applies to a single function, all I/O in the NT kernel is asynchronous. IOCP acts on file, network, mail slot, pipes, etc. IoRing/io_uring is for files only. RegisteredIO is network only. While Windows userland itself may be a 'mess' and archaic in it's own way (among the other anti-consumer bits), the NT kernel is technically quite advanced, not onl…

A free sample chapter from Windows Internals about the I/O system for the curious: https://www.microsoftpressstore.com/articles/article.aspx?p=...

Re: Asynchronous IO: the next billion-dollar mistake?

#154

Post by jclulow »

OutOfHere wrote: post #145

> Languages such as Go and Erlang bake support for asynchronous IO directly into the language, while others such as Rust rely on third-party libraries such as Tokio. This is so wrong. Go and Erlang have message passing, not async. Message passing is its own thing; it should not be mixed with threading or async.

Go offers channels in the standard library, which you can use to do message passing, certainly (so does Rust). But I/O through the stdlib is absolutely asynchronous. I/O routines that would block, like sending and receiving from the network, are all magic async switch points where your goroutine can be replaced on the current OS thread with another. When epoll (or whatever) signals readiness on the blocked descriptor you get switched back on. As described in the previous post, the asynchronous I/O is hidden from you as an implementation detail of the language but it's absolutely there.

Re: Asynchronous IO: the next billion-dollar mistake?

#155

Post by jiggawatts »

yencabulator wrote: post #143
Animats wrote: post #37

Earlier quoted context omitted.

There is a history of trying to support context switching in CPU hardware. That was a hot idea decades ago. Intel had call gates and some other stuff. Some of the RISC machines had hardware to spill all the registers to memory in background. Some early machines, from the days where CPUs were slower than memory, just had a context pointer in hardware. Change that and you're running a different thread. None of this hel…

One interesting angle is Mill (note, vaporware). Their "portal" calls between security boundaries are essentially the same as their EBB function calls. https://www.youtube.com/watch?v=XJasE5aOHSw

Mill is still vaporware. As far as I can tell, they’ve never made anything from silicon.

Compare their progress to RISC-V, which started later and is now shipping in hundreds of products at volume.

Re: Asynchronous IO: the next billion-dollar mistake?

#156

Post by OutOfHere »

jclulow wrote: post #154
OutOfHere wrote: post #145

> Languages such as Go and Erlang bake support for asynchronous IO directly into the language, while others such as Rust rely on third-party libraries such as Tokio. This is so wrong. Go and Erlang have message passing, not async. Message passing is its own thing; it should not be mixed with threading or async.

Go offers channels in the standard library, which you can use to do message passing, certainly (so does Rust). But I/O through the stdlib is absolutely asynchronous. I/O routines that would block, like sending and receiving from the network, are all magic async switch points where your goroutine can be replaced on the current OS thread with another. When epoll (or whatever) signals readiness on the blocked descriptor…

That's in practically every nontrivial language.

Re: Asynchronous IO: the next billion-dollar mistake?

#157

Post by wtallis »

lmz wrote: post #30
wtallis wrote: post #20

Earlier quoted context omitted.

The same Windows NT whose decades-old async IO capabilities are so good they immediately cloned io_uring?

Sorry, which one came first between io_uring and windows RIO? https://learn.microsoft.com/en-us/previous-versions/windows/...

I think you missed the point: io_uring is the newer API. Microsoft saw the new async IO API developed for Linux, and made a version for Windows. If what Windows has had all along is so great, why did they bother cloning io_uring when io_uring came along? It definitely isn't because there's any significant body of software relying on io_uring yet.

My theory: people like to extol the virtues of NT's IOCP as "checking the box" for being async, but seldom bother to assess whether the decades-old async API actually offers good performance in comparison to more recent alternatives. But some parts of Microsoft understand quite well that they have pervasive issues with IO performance: replacing WSL1 with WSL2, introducing DirectStorage and a partial copy of io_uring, the Dev Drive feature in Windows 11—all changes that are driven by the understanding that the status quo isn't all that great.

Re: Asynchronous IO: the next billion-dollar mistake?

#158

Post by dietr1ch »

kaba0 wrote: post #122
BenoitP wrote: post #68

Earlier quoted context omitted.

Thanks for putting words into this. Another cut off could be 3 cm away: the RAM. If data needs to go on the heap, be shared, one can consider the truth lives farther away than 3cm and thus has async/impure effects.

But the same way the CPU works very hard to hide that away from you (reordering, caches, etc), green threads could do the same with barely any performance hit.

With async, things happening far away can completely prevent you from making progress, in which case you are better off doing something else in the meantime, like simply blocking and scheduling a thread from a different process as even the cost of swapping threads, destroying the caches and other cpu state is minimal and nothing else can be done.

The optimization begins instead of a single thing prevents you from making progress, it's a set of things, so you can parallelize the tasks and handle them in the seemingly random order they happen to finish. Now the question is how is this not an event loop running async tasks?

Re: Asynchronous IO: the next billion-dollar mistake?

#159

Post by yencabulator »

jiggawatts wrote: post #155
yencabulator wrote: post #143

Earlier quoted context omitted.

One interesting angle is Mill (note, vaporware). Their "portal" calls between security boundaries are essentially the same as their EBB function calls. https://www.youtube.com/watch?v=XJasE5aOHSw

Mill is still vaporware. As far as I can tell, they’ve never made anything from silicon. Compare their progress to RISC-V, which started later and is now shipping in hundreds of products at volume.

Yeah, Mill hasn't been able to find funding to go beyond simulator+compiler+thoughts about FPGA.

Compared to Mill, RISC-V is nearly identical to Arm and X86-64.

Re: Asynchronous IO: the next billion-dollar mistake?

#160

Post by compressedgas »

pizza wrote: post #90
dudeinjapan wrote: post #81

Earlier quoted context omitted.

I interpreted it as mainly network I/O, but the core point in the article is less about the I/O itself and more about thread-based async I/O handling.

I see, I had this notion that DirectStorage worked by somehow allowing the GPU cores to host multiple parallel threads each doing full requests on their own, but on further research I was mistaken - requests are still CPU-submitted

I recently sought to check if DirectStorage used PCIe P2P to transfer data from the SSD to the GPU memory. It definitely could use it but I didn't see any evidence that it did.
Post reply on HN