Comparison of Rust async and Linux thread context switch time and memory use
1–10 of 201 posts
Re: Comparison of Rust async and Linux thread context switch time and memory use
#2How does Rust async compare to Goroutine, Erlang threads, Javascript async, Java async in performance and memory usage? Is there any benchmarks for that?
Re: Comparison of Rust async and Linux thread context switch time and memory use
#3How does Rust async compare to Goroutine, Erlang threads, Javascript async, Java async in performance and memory usage? Is there any benchmarks for that?
And also Crystal fibers
Re: Comparison of Rust async and Linux thread context switch time and memory use
#4Quickest summary: Rust async is >3x faster and lighter than Linux threads. This is a great accomplishment for Rust.
Re: Comparison of Rust async and Linux thread context switch time and memory use
#5That's a huge help. I only need about 20 threads in Rust, some of which are compute-bound. So involving "async" is totally the wrong tool for the job. Goodbye, Tokio.
Re: Comparison of Rust async and Linux thread context switch time and memory use
#6Quickest summary: Rust async is >3x faster and lighter than Linux threads. This is a great accomplishment for Rust.
It sound to me like comparing apples and oranges though. Parallelism (threads) and concurrency (aysnc in Rust) are not the same thing and can be actually used in combination.
Re: Comparison of Rust async and Linux thread context switch time and memory use
#7I 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_wait() or something similar. With blocking I/O, you call read(), and the kernel wakes up your thread when the read() completes. With non-blocking I/O, you call read(), get EAGAIN, call epoll_wait(), the kernel wakes up your thread when data is ready, and then you call read() a second time.
In both scenarios, you’re calling a blocking system call and waking up the thread later.
Of course, there are scenarios when epoll_wait() returns multiple events, which reduces the number of context switches. But the general result is that it’s not always easy to beat blocking I/O and kernel threads.
Re: Comparison of Rust async and Linux thread context switch time and memory use
#8I’m curious how this looks on ARM64. (Sorry, Aarch64.). x86 context switches are overcomplicated and inherently slow.
Re: Comparison of Rust async and Linux thread context switch time and memory use
#9I 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.
Re: Comparison of Rust async and Linux thread context switch time and memory use
#10> A context switch takes around 0.2µs between async tasks, versus 1.7µs between kernel threads. But this advantage goes away if the context switch is due to I/O readiness: both converge to 1.7µs.
This is a big surprise.
If you look at the Techempower web benchmark [1], the performance of actix-web is about 20x higher than that of Rocket.
The common explanation is that actix-web is async and hence much faster than Rocket which relies on kernel context switching.
But if Rust async and kernel thread has the same switch time as shown by this benchmark, then why is actix-web so much faster than Rocket?
[1] https://www.techempower.com/benchmarks/#section=data-r20&hw=...