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

Post by bitcharmer » Fri, Feb 12, 2021, 12:32 PM UTC

ithkuil wrote: post #51

otabdeveloper4 wrote: post #37

A meaningless comparison. Linux, being a preemptively multitasking OS, switches thread contexts regardless of what you're running. So the Rust async context switch is on top of the regular Linux context switch, not instead .

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

Post by bitcharmer » Fri, Feb 12, 2021, 12:39 PM UTC

harikb wrote: post #32

jph wrote: post #4

Quickest summary: Rust async is >3x faster and lighter than Linux threads. This is a great accomplishment for Rust.

Keep in mind that a new async task doesn't create a new thread. So yes, "not creating a new thread" is 3x faster than "creating a thread". If the app layer can context switch using language level constructs, and do co-operative switching, then yes, one gets the 3x benefit. imho, whether the async executor and scheduler is performant enough to manage the tasks is what one should worry about.

Post by pas » Fri, Feb 12, 2021, 12:42 PM UTC

baby wrote: post #101

pas wrote: post #87

Earlier quoted context omitted.

Rust's async model takes very little time to grasp. It's very explicit. Nothing runs in the background (contrast that with NodeJS). You have strong static types to help you to know when you got a Future, you can decide where/when to await it. It's programming with threads, where you have a thread pool and pipes to put tasks onto that and a helper function/macro. Await does this under the hood of course.

That is until you get a weird error or try to do something more complicated.

Post by josephg » Fri, Feb 12, 2021, 12:49 PM UTC

masklinn wrote: post #86

Ciantic wrote: post #83

Earlier quoted context omitted.

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.

> should a task execute for too long, the runtime will automatically react by spawning a new executor thread taking over the current thread’s work. That is a super interesting strategy, though obviously only works when you can « afford » a multithreaded scheduler. Anyway I wonder how they manage this, signals?

Post by lxpz » Fri, Feb 12, 2021, 1:15 PM UTC

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…

    let p, c, m = join!(
        GetUserPermission(username),
        GetServerConfig(),
        GetMessageOftheDay()
    );