Yes, and it is extremely expensive. This is a well-known design problem in database engines.
The computational cost of context-switching threads at yield points is often many times higher than the actual workload executed between yield points. To address this you either need fewer yield points, which reduces concurrency, or you need to greatly reduce the cost of yielding. An async architecture reduces the cost of yielding by multiple orders of magnitude relative to threads.
> The computational cost of context-switching threads at yield points is often many times higher than the actual workload executed between yield points.
I would they this often is 1% of cases. As for Rust ecosystem, it doesn't make much case to add so much complexity and inconvenient abstractions to cover 1% of use-cases.
It approaches 100% of cases for systems that care about software performance, since software performance is bandwidth bound. If almost everyone agrees that software performance is optimally fast already then I agree with you.
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.
Yes, and it is extremely expensive. This is a well-known design problem in database engines.
The computational cost of context-switching threads at yield points is often many times higher than the actual workload executed between yield points. To address this you either need fewer yield points, which reduces concurrency, or you need to greatly reduce the cost of yielding. An async architecture reduces the cost of yielding by multiple orders of magnitude relative to threads.
> The computational cost of context-switching threads at yield points is often many times higher than the actual workload executed between yield points.
I would they this often is 1% of cases. As for Rust ecosystem, it doesn't make much case to add so much complexity and inconvenient abstractions to cover 1% of use-cases.
It approaches 100% of cases for systems that care about software performance, since software performance is bandwidth bound. If almost everyone agrees that software performance is optimally fast already then I agree with you.
1 reply →
And how much slower is that? What happens when I run a thousand async tasks? I'll give you a hint, with async/await, it has barely any overhead.
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.
1 reply →