You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
hair-pin context switches (a thread -> kernel -> the same thread) are able to avoid TLB flushing, and is one reason behind why pinning causes measured differences with tasks to fade
most pthread implementations on linux cache threads and don't actually create a new thread if a cached thread is available
the 8mb of assigned stack memory is virtual - it doesn't actually use hardware until it gets used
async tasks require pessimistic allocations for their worst-case stack, and for real-world use cases like a task that handles TLS and HTTP/GRPC/JSON, the measurable RESIDENT memory usage won't be all that different from threads overall
async implementations may use epoll in oneshot mode, causing a lot of extra interest-related syscalls and increasing in-kernel contention. for workloads where there are more than one IO operation per socket, this can be particularly harmful for throughput. This causes throughput for async implementations to be significantly lower than the throughput of a threaded implementation, and a simple echo server can demonstrate this (see the req_res binaries here).
overall, there are a lot of things here that really fade into insignificance when you consider the simple effort required to deserialize JSON or handle TLS. 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 less energy for actually optimizing the business logic, which is where all of the cycles and resource use are anyway, so in-practice async implementations tend to be buggier and slower.