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

Async Rust never left the MVP state

tweedegolf.nl

Post reply on HN
Print view View original

241–250 of 273 posts

Re: Async Rust never left the MVP state

#241

Post by [deleted] »

fulafel wrote: post #163
nananana9 wrote: post #13

Earlier quoted context omitted.

> the thread sleeps until ready and the kernel abstracts it away. Sure, but once you involve the kernel and OS scheduler things get 3 to 4 orders of magnitude slower than what they should be. The last time I was working on our coroutine/scheduling code creating and joining a thread that exited instantly was ~200us, and creating one of our green threads, scheduling it and waiting for it was ~400ns. You don't need to w…

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.

[deleted]

Re: Async Rust never left the MVP state

#242

Post by nananana9 »

audunw wrote: post #239
fulafel wrote: post #163

Earlier quoted context omitted.

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.

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…

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.

Re: Async Rust never left the MVP state

#243

Post by mike_hearn »

ptx wrote: post #195
vlovich123 wrote: post #153

Earlier quoted context omitted.

only netbeans is written in swing . Eclipse and Jetbrains use their own thing and still generally struggled.

No, JetBrains use Swing in IntelliJ IDEA. You can tell from how it (for example) fails to layout dialogs correctly the first time they're displayed, just like every other Swing application. And how windows have no minimum size because Swing doesn't expose that functionality. And the various baffling bugs involving window focus that are inherent to Swing applications. Eclipse uses SWT instead, which wraps the platform…

When did you last use IntelliJ, 30 years ago? I've never seen it fail to lay out dialogs correctly, windows do have minimum sizes, and I haven't seen any focus bugs.

Re: Async Rust never left the MVP state

#244

Post by p2detar »

tombert wrote: post #201
groundzeros2015 wrote: post #194

Earlier quoted context omitted.

If this is a classic exercise can you show me the material? Why can’t a scheduler be written which optimizes around IO? What additional information is present in code that has async/await annotations?

I believe that's actually how the virtual threads in the newer Java works. It's smart enough to notice IO and properly park it and move to another thread. I think it's still basically doing epoll behind the scenes [1], but you have straightforward sequential code in the process and the actual implementation is invisible to the user, and you can use old boring blocking code with an object that is a drop-in replacement…

> but I'm definitely an outlier for that

You are not. I prefer the same and that's how my product works right now. My HTTP API is Vert.x-only with futures. My particular use case is thousands of devices sending small packages to the API in undefined periods of time or in bursts, so I find Vert.x event-loop performance quite a good match for my use case. In fact it has been very positive given customer feedback thusfar.

Background tasks in my app are processed in a different module, which uses plain old ScheduledExecutorService-based thread pool to poll. The tasks are visible in the UI as well. I still haven't switched to VTs, because I don't know what load-implications that may have on the database pool. The JEP writes `Do not pool virtual threads` [0]. I assume if a db connection is not available in the pool, the VT will get parked, but I feel this isn't quite what a background scheduler should look like, e.g., hundreds of "in-process" tasks blocked while waiting for db connection to free up. Testing is on my todo list for some time now.

The JEP doesn't mention epoll, but there is a write up about that on github: `On Linux the poller uses epoll, and on Windows wepoll (which provides an epoll-like API on the Ancillary Function Driver for Winsock)` [1]

0 - https://openjdk.org/jeps/444#Do-not-pool-virtual-threads

1 - https://gist.github.com/ChrisHegarty/0689ae92a01b4311bc8939f...

Re: Async Rust never left the MVP state

#246

Post by staticassertion »

adastra22 wrote: post #176
staticassertion wrote: post #173

Earlier quoted context omitted.

I'm not prominent but I disagreed with it at the time and I was wrong.

I’m curious - why were you wrong? It still seems like a wart to me, all these years later. What am I missing?

I was a proponent of the postfix macro solution. `.await!` or `.await!()`, essentially. The idea was that this could be generalized, it was closer to existing syntax, etc.

I was worried about features that I still don't love like `.match` etc (I'm more open to these now).

Post-fix macros would have been very complex. Scoping alone is complex.

`.await` kinda just works. It does everything you want and the one cost is that it looks like a property access but it isn't. A trivial cost in retrospect that I was a huge baby about, and I'll always feel bad about that.

Re: Async Rust never left the MVP state

#247

Post by groundzeros2015 »

t-writescode wrote: post #230
groundzeros2015 wrote: post #34

Earlier quoted context omitted.

I agree. I don’t think callbacks are an underbaked language feature.

In another part of the thread, you lament the use of callbacks. May I ask you what you think async/await is, except syntactic sugar that wraps around the callback pattern?

Certain architectures focused around callbacks have problems. But their existence is not a burden on the language design.

Node.js has a problem where every standard library function has a callback and blocking version. At least they just committed to doing both.

Re: Async Rust never left the MVP state

#248

Post by groundzeros2015 »

Salgat wrote: post #236
bigstrat2003 wrote: post #233

Earlier quoted context omitted.

The vast, vast majority of programmers are going to be writing software where there are only a handful of threads (if that). The "I need thousands of concurrent executions" case is simply not relevant to most people.

You do realize what servers do in parallel right? Async/await allows ASP.NET to scale beyond 1 thread per request.

Are you going to put multiple customer’s data in the same OS process?

Did you know you can get even more performance if you manually manage memory and don’t use virtual functions?

Re: Async Rust never left the MVP state

#249

Post by xpe »

nixpulvis wrote: post #96
diondokter wrote: post #59

Earlier quoted context omitted.

So on the title, I picked this because it's simply the truth. Since async landed in 2019 or so, not much has changed. Yes, we can have async in traits and closures now. But those are updates to the typesystem, not to the async machinery itself. Wakers are a little bit easier to work with, but that's an update to std/core. As I understand it, the people who landed async Rust were quite burnt out and got less active an…

I think it's partially accurate, and partially a consequence of how async fractures the design space, so it will always feel like a somewhat separate thing, or at least until we figure out how to make APIs agnostic to async-ness.

Claim-1: the async versus sync distinction cannot be meaningfully dissolved at the programmer level.

Claim-2: async versus sync is a fundamental division in CS

Discuss amongst yourselves. I lean towards thinking both are probably true (P~70%, P~90%)

See: “What Color is Your Function?” by Bob Nystrom (2015). https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Re: Async Rust never left the MVP state

#250

Post by vlovich123 »

groundzeros2015 wrote: post #197
vlovich123 wrote: post #154

Earlier quoted context omitted.

Hate to break it to you but windows gui programming, emblemified by VS6, is about as far away from a blocking threaded model as you get. You literally have a UI event loop and any compute intensive work is meant to be offloaded to other threads via messages/COM. This is why when they failed to do that correctly the entire UI would lock up - because they didn’t have good hygiene around how to offload compute intensive…

Wait which programming model are you arguing is the low latency one? I thought you said it was JS because non-blocking.

Event loops are also non blocking. That’s literally why JS is non blocking. But event loops and callbacks are extremely hard to scale and maintain and keep non blocking. That’s why async/await is a more powerful abstraction - you don’t pretend I/O is this blocking thing, you interleave other work while it’s being done, and you don’t get impossible to follow callback hell. VS6 suffered from non responsive hangs all the time because some developer forgot to offload something that turned out to be compute heavy under certain conditions.
Post reply on HN