3 ms·
> In either case you need to load the context for other requests. For async tasks, it means return, then call. For threads, it means moving to an entirely diff
by joconde 5y ago
> In either case you need to load the context for other requests.
For async tasks, it means return, then call. For threads, it means moving to an entirely different stack, somewhere else in memory. “Loading context” is more expensive in the latter case.
> Maybe using a stack means using more cache lines than coroutines, but you'd have to be right at the edge of capacity for active requests for it to matter.
Why? Cache doesn’t only speed things up when capacity is full. Anything we have to reload from RAM will take time to load.
- akvadrako 5y agoTo do anything with a request you are going to have a context which will function just like the stack of a thread. The only question is how many cache lines each takes. It only matters if you are at capacity because otherwise the active requests will be cached.
- joconde 5y ago> To do anything with a request you are going to have a context which will function just like the stack of a thread. But a thread has a separate call stack. Returning and calling another function in the same stack just involves moving the stack pointer by a few bytes. Switching to another thread’s stack will invalidate much more cache, while running an async task until await will make the best use of the existing cache, and switch (much closer in RAM than in another thread) only when it makes sense, i.e. the previous task started waiting on something. > It only matters if you are at capacity because otherwise the active requests will be cached. CPU cache is a few megabytes. That definitely won’t hold hundreds of requests if they all transfer substantial data, even if you can handle thousands or more.