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

Comparison of Rust async and Linux thread context switch time and memory use

github.com

Post reply on HN
Print view View original

91–100 of 201 posts

Re: Comparison of Rust async and Linux thread context switch time and memory use

#91

Post by raggi »

Ciantic wrote: post #83
josephg wrote: post #53

Earlier quoted context omitted.

I’d happily take an async-by-default world over a world where some APIs only exist through blocking calls. A classically threaded program can easily block on a future, but wrapping a blocking call in an otherwise asynchronous program is complicated, expensive and error prone work.

Btw, have you read this: https://async.rs/blog/stop-worrying-about-blocking-the-new-a... async-std allows to run blocking calls without hoops rather efficiently: async fn read_to_string(path: impl AsRef ) -> io::Result { std::fs::read_to_string(path) } It doesn't have await inside! My mind was blown as I saw that.

It also really doesn't scale. It'll do fine on your average <10 core laptop, but once you get on a multi-package system you're going to find you're constantly thrashing memory because it is making disruptive scheduling decisions and your pooled tasks have poor context locality.

Re: Comparison of Rust async and Linux thread context switch time and memory use

#92

Post by the8472 »

jiggawatts wrote: post #88
lxpz wrote: post #75

> People often see that there's some theoretical benefit of async and then they accept far less ergonomic coding styles and the additional bug classes that only happen on async due to accidental blocking etc... despite the fact that when you consider a real-world deployed application, those "benefits" become indistinguishable from noise. However, due to the additional bug classes and worse ergonomics, there is now le…

Speaking of futures_unordered and similar patterns, I think a part of the "async promise" that has failed is the lack of concurrency for a single user request by default in most languages. That is, the 'easy' path is to write code such as the following (in vaguely C# pseudocode): var p = await GetUserPermission( username ); var c = await GetServerConfig(); var m = await GetMessageOfTheDay(); Assume each await call is…

Call me noone then.

I write this kind of stuff all the time because parallelizing long-running tasks without dependencies is one of the easiest wins when it comes to wall-time.

But this kind of optimization is somewhat orthogonal to async/await. You don't need fine-grained async to optimize long-running tasks, you could just throw a bunch of closures into a threadpool for that purpose. Async only makes sense when you're interleaving thousands of tasks with readiness/completion based IO.

Re: Comparison of Rust async and Linux thread context switch time and memory use

#93

Post by ithkuil »

otabdeveloper4 wrote: post #67
ithkuil wrote: post #51

Earlier quoted context omitted.

When you're in sub microsecond time scales, preemption events are relatively rare.

I don't see your point. "Linux thread context switch time" is a meaningless metric, since Linux will switch thread context regardless of what you choose to run on your computer. Any "async" switches are additional overhead; you don't get to not have kernel preemption just because your Rust thread is now switching contexts "asyncly". There are benefits to having an additional user-mode scheduling mechanism inside your…

> switches thread contexts regardless of what you're running

my point was that thread context switches caused by preemption happen at an entirely different time scale than the rate of context switches caused by syscalls (if the system is doing any meaningful level of IO)

Re: Comparison of Rust async and Linux thread context switch time and memory use

#94

Post by the8472 »

khuey wrote: post #9
klodolph wrote: post #7

I am not surprised that the cost of context switching due to I/O readiness can often be roughly equal between async tasks and kernel threads. Normal blocking I/O can be surprisingly efficient because of various factors, such as a reduced need for system calls. Think about it this way—if you have a user-space thread which wakes up due to I/O readiness, then this means that the relevant kernel thread woke up from epoll…

io_uring will help a lot here.

io_uring doesn't mean async though. You can also use it for blocking batch execution of syscalls. E.g. when you need to stat hundreds of files or wait for several child processes at once. So with some batch-oriented convenience wrappers it can help threaded code too.

Re: Comparison of Rust async and Linux thread context switch time and memory use

#95

Post by the8472 »

secondcoming wrote: post #69

Performance profiling on a laptop is largely pointless. There's too much stuff trying to conserve power by limiting performance.

I have done benchmarking on a linux laptop. Once you disable turbo-boost you get quite consistent results for CPU-bound tasks at least.

Re: Comparison of Rust async and Linux thread context switch time and memory use

#96

Post by littlestymaar »

jiggawatts wrote: post #88
lxpz wrote: post #75

> People often see that there's some theoretical benefit of async and then they accept far less ergonomic coding styles and the additional bug classes that only happen on async due to accidental blocking etc... despite the fact that when you consider a real-world deployed application, those "benefits" become indistinguishable from noise. However, due to the additional bug classes and worse ergonomics, there is now le…

Speaking of futures_unordered and similar patterns, I think a part of the "async promise" that has failed is the lack of concurrency for a single user request by default in most languages. That is, the 'easy' path is to write code such as the following (in vaguely C# pseudocode): var p = await GetUserPermission( username ); var c = await GetServerConfig(); var m = await GetMessageOfTheDay(); Assume each await call is…

In Javascript, this is a typical rookie mistake. Every newcomer would do it once, get lectured about `Promise.all` in code review, and move on.

Honestly, I'd be really surprised if this was a common practice in C#.

Re: Comparison of Rust async and Linux thread context switch time and memory use

#97

Post by twic »

jiggawatts wrote: post #88
lxpz wrote: post #75

> People often see that there's some theoretical benefit of async and then they accept far less ergonomic coding styles and the additional bug classes that only happen on async due to accidental blocking etc... despite the fact that when you consider a real-world deployed application, those "benefits" become indistinguishable from noise. However, due to the additional bug classes and worse ergonomics, there is now le…

Speaking of futures_unordered and similar patterns, I think a part of the "async promise" that has failed is the lack of concurrency for a single user request by default in most languages. That is, the 'easy' path is to write code such as the following (in vaguely C# pseudocode): var p = await GetUserPermission( username ); var c = await GetServerConfig(); var m = await GetMessageOfTheDay(); Assume each await call is…

I have written a few programs like this - but not in languages which have async/await! In languages with manual async, getting here by refactoring is fairly easy.

Re: Comparison of Rust async and Linux thread context switch time and memory use

#98

Post by sambe »

lxpz wrote: post #75

> People often see that there's some theoretical benefit of async and then they accept far less ergonomic coding styles and the additional bug classes that only happen on async due to accidental blocking etc... despite the fact that when you consider a real-world deployed application, those "benefits" become indistinguishable from noise. However, due to the additional bug classes and worse ergonomics, there is now le…

The way you have quoted this suggests it is being said by the author, whom you are disagreeing with. It's not: it's being said by someone else (in an issue filed against the repo), and the author also mostly disagrees.

Re: Comparison of Rust async and Linux thread context switch time and memory use

#99

Post by waynesonfire »

lxpz wrote: post #75

> People often see that there's some theoretical benefit of async and then they accept far less ergonomic coding styles and the additional bug classes that only happen on async due to accidental blocking etc... despite the fact that when you consider a real-world deployed application, those "benefits" become indistinguishable from noise. However, due to the additional bug classes and worse ergonomics, there is now le…

It has been a pleasure using the Erlang runtime to scratch my concurrency itch while avoiding the async / await bandaid.

Re: Comparison of Rust async and Linux thread context switch time and memory use

#100

Post by baby »

littlestymaar wrote: post #96
jiggawatts wrote: post #88

Earlier quoted context omitted.

Speaking of futures_unordered and similar patterns, I think a part of the "async promise" that has failed is the lack of concurrency for a single user request by default in most languages. That is, the 'easy' path is to write code such as the following (in vaguely C# pseudocode): var p = await GetUserPermission( username ); var c = await GetServerConfig(); var m = await GetMessageOfTheDay(); Assume each await call is…

In Javascript, this is a typical rookie mistake. Every newcomer would do it once, get lectured about `Promise.all` in code review, and move on. Honestly, I'd be really surprised if this was a common practice in C#.

Rust doesn’t allow you to do this.
Post reply on HN