You involve the kernel also when you are doing async io.

In this context the interesting thing to measure would be doing IO in your green threads vs OS threads.

A stronger theoretical performance argument for async io is that you can do batching, ala io_uring, and do fewer protection domain crossings per IO that way.

▲

a day ago | parent | next [-]

[deleted]

▲

audunw a day ago | parent | prev [-]

Well yeah of course, using APIs io_uring and grand central dispatch is basically the whole point of all this async stuff in a systems programming language. It’s absurd it hasn’t been mentioned more here.

OS Threads are for compute parallelism, async with stackless coroutines (ideally) or green threads is for IO parallelism. It’s pretty straight forward.

And IMO, Zig has show how to do async IO right (the foundational stuff. Other languages could add better syntax for ergonomics.

	▲	nananana9 a day ago \| parent [-]
		It's not the whole point, there's lots of other (albeit smaller) gains to be had once you have a strong async apparatus. The core of your async implementation doesn't have to care about I/O - as long as it has a way to block/schedule fibers, it's easy to implement io_uring/IOCP based I/O on top of that - it's a matter of sticking a single IO poll in your main loop, and when you get a result, schedule the fiber that's waiting for it. Another thing you get almost for free is an accurate Sleep(0.3) - your Sleep pushes the current fiber in a global vector with the time to be resumed, and you loop over that vector in your main loop. We're writing a game engine so WaitForNextFrame() is another useful one - the implementation is literally pushing the current fiber to a vector and resuming it the next tick.