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

21–30 of 273 posts

Re: Async Rust never left the MVP state

#21

Post by groundzeros2015 »

nchie wrote: post #19
groundzeros2015 wrote: post #8

Earlier quoted context omitted.

In that sentence I’m referring to the abstract idea of a thread of execution as a model of programming, not OS threads. A green thread implementation could do it too. But what you said about kernel implementation is true. But are we really saying that the primary motivation for async/await is performance? How many programmers would give that answer? How many programs are actually hitting that bottleneck? Doesn’t that…

> But are we really saying that the primary motivation for async/await is performance? Of course - what else would it be? The whole async trend started because moving away from each http request spawning (or being bound to) an OS thread gave quite extreme improvements in requests/second metrics, didn't it?

I agree. Managing many http requests or responses was a motivating problem.

What I question is whether 1. Most programs resemble that, so that they make it an invasive feature of every general purpose language. 2. Whether programmers are making a conscious choice because they ruled out the perf overhead of the simpler model we have by default.

Re: Async Rust never left the MVP state

#22

Post by MrBuddyCasino »

slopinthebag wrote: post #9

It's so funny that people will do anything to hate on Rust, including nitpicking a few bytes of overhead for a future while they reach for an entire thread or runtime to handle async in their favourite language.

Nobody seriously tries to run Golang or Java on an MCU. But they do run Rust code.

Re: Async Rust never left the MVP state

#23

Post by vlovich123 »

groundzeros2015 wrote: post #17
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…

1. Why can’t we have better green threads implementations with better scheduling models? 2. Unchecked array operations are a lot faster. Manual memory management is a lot faster. Shared memory is a lot faster. Usually when you see someone reach for sharp and less expressive tools it’s justified by a hot code path. But here we jump immediately to the perf hack? 3. How many simultaneous async operations does your progr…

Well, if you offload heavy compute into an async task, then usually it depends strictly on how many concurrent inputs you are given. But even something as “simple” as a performance editor benefits from this if done well - that’s why JS text editors have reasonably acceptable performance whereas Java IDEs always struggled (historically anyway since even Java has adopted green threads).

Re: Async Rust never left the MVP state

#24

Post by conaclos »

I recently started working with Rust async. The main issue I am currently facing is code duplication: I have to duplicate every function that I want to support both asynchronous and blocking APIs. This could be great to have a `maybe-async`. I took a look at the available crates to work around this (maybe-async, bisync), but they all have issues or hard limitations.

Re: Async Rust never left the MVP state

#26

Post by groundzeros2015 »

vlovich123 wrote: post #20
groundzeros2015 wrote: post #4

Async seems like an underbaked idea across the board. Regular code was already async. When you need to wait for an async operation, the thread sleeps until ready and the kernel abstracts it away. But We didn’t like structuring code into logical threads, so we added callback systems for events. Then realized callbacks are very hard to reason about and that sequential control is better. So threads was the right program…

> Regular code was already async. When you need to wait for an async operation, the thread sleeps until ready and the kernel abstracts it away Not really. I’ve observed async code often is written in such a way that it doesn’t maximize how much concurrency can be expressed (eg instead of writing “here’s N I/O operations to do them all concurrently” it’s “for operation X, await process(x)”). However, in a threaded wor…

I am not saying threads are the model for all programming problems. For example a dependency graph like an excel spreadsheet can be analyzed and parallelized.

But as you observed, async/await fails to express concurrency any better. It’s also a thread, it’s just a worse implementation.

Re: Async Rust never left the MVP state

#27

Post by albertzeyer »

conaclos wrote: post #24

I recently started working with Rust async. The main issue I am currently facing is code duplication: I have to duplicate every function that I want to support both asynchronous and blocking APIs. This could be great to have a `maybe-async`. I took a look at the available crates to work around this (maybe-async, bisync), but they all have issues or hard limitations.

The classic function coloring problem. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Re: Async Rust never left the MVP state

#28

Post by vlovich123 »

groundzeros2015 wrote: post #26
vlovich123 wrote: post #20

Earlier quoted context omitted.

> Regular code was already async. When you need to wait for an async operation, the thread sleeps until ready and the kernel abstracts it away Not really. I’ve observed async code often is written in such a way that it doesn’t maximize how much concurrency can be expressed (eg instead of writing “here’s N I/O operations to do them all concurrently” it’s “for operation X, await process(x)”). However, in a threaded wor…

I am not saying threads are the model for all programming problems. For example a dependency graph like an excel spreadsheet can be analyzed and parallelized. But as you observed, async/await fails to express concurrency any better. It’s also a thread, it’s just a worse implementation.

That’s incorrect. Even when expressed suboptimally, it still tends to result in overall higher throughput and consistently lower latency (work stealing executors specifically). And when you’re in this world, you can always do an optimization pass to better express the concurrency. If you’ve not written it async to start with, then you’re boned and have no easy escape hatch to optimize with.

Re: Async Rust never left the MVP state

#29

Post by swiftcoder »

groundzeros2015 wrote: post #21
nchie wrote: post #19

Earlier quoted context omitted.

> But are we really saying that the primary motivation for async/await is performance? Of course - what else would it be? The whole async trend started because moving away from each http request spawning (or being bound to) an OS thread gave quite extreme improvements in requests/second metrics, didn't it?

I agree. Managing many http requests or responses was a motivating problem. What I question is whether 1. Most programs resemble that, so that they make it an invasive feature of every general purpose language. 2. Whether programmers are making a conscious choice because they ruled out the perf overhead of the simpler model we have by default.

That is why we have the function colouring problem and a split ecosystem in the first place - if it were obviously better in all cases, we'd make async the default, and get rid of the split altogether (and there are languages, like Erlang, that fall on this side of the fence)

Re: Async Rust never left the MVP state

#30

Post by groundzeros2015 »

vlovich123 wrote: post #23
groundzeros2015 wrote: post #17

Earlier quoted context omitted.

1. Why can’t we have better green threads implementations with better scheduling models? 2. Unchecked array operations are a lot faster. Manual memory management is a lot faster. Shared memory is a lot faster. Usually when you see someone reach for sharp and less expressive tools it’s justified by a hot code path. But here we jump immediately to the perf hack? 3. How many simultaneous async operations does your progr…

Well, if you offload heavy compute into an async task, then usually it depends strictly on how many concurrent inputs you are given. But even something as “simple” as a performance editor benefits from this if done well - that’s why JS text editors have reasonably acceptable performance whereas Java IDEs always struggled (historically anyway since even Java has adopted green threads).

You think IDEs are written in JS because of the performance benefits of the threading model?

I thought it was because they could copy chromium.

Post reply on HN