3 ms·

While the general point the article is making is correct there are some issues. - (minor issue) async example is artificially limited to 1 thread (the article

While the general point the article is making is correct there are some issues. - (minor issue) async example is artificially limited to 1 thread (the article states that). The issue is comparing 8 OS threads no async to 1 thread async is fundamentally not very useful as long as you didn't pin all threads to the same physical core.. So in general you should compare something async with num_cpus threads vs. num_cpus*X OS threads. Through this wouldn't have been that useful in this example without pinning the tokio async threads to CPUs to forcefully highlight the page issue, and doing it is bothersome so I wouldn't have done so either. - (bigger issue) The singled thread async "traditional IO" example is NOT single threaded. Async _file_ IO anything between not a thing or very bad in most OSes hence most async engines including tokio do file IO in worker threads. This means the "single threaded" conventional IO async example is running 8 threads for reading IO and one to "touch the buffer" (i.e. do hardly anything). To be clear the single threaded not being single threaded issue isn't discrediting the article, the benchmarks still show the problem it's that the 8 threaded conventional and 1 threaded async conventional are accidentally basically both 8 thraded.

dbaupp 2y ago
(Author here) > The singled thread async "traditional IO" example is NOT single threaded The threads backing the single-threaded IO are an implementation detail of fulfilling the `.read().await` calls. The key is that there's a single coordinator thread that's issuing all the work, with the user-space runtime multiplexing tasks on that thread. I thought the fact that the "start a request and come back when it is finished" behaviour happens to be implemented via user-space threads rather than kernel-level epoll (or similar) is unlikely to affect behaviour. I considered scaling up the number of files and using a multi-threaded runtime, but I felt that'd make everything more complicated without fundamentally changing behaviour. However, maybe my theory is incorrect, in which case someone else can do their own experiments to provide more concrete information. (This is referenced in a footnote: https://huonw.github.io/blog/2024/08/async-hazard-mmap/#fn:tokio-single-threaded https://huonw.github.io/blog/2024/08/async-hazard-mmap/#fn:t... ) > The issue is comparing 8 OS threads no async to 1 thread async is fundamentally not very useful as long as you didn't pin all threads to the same physical core The point is not to benchmark async vs. non-async, but provide a general reference point for "mmap working well" for comparison. As you suggest you agree with the "minor" issue tag, I don't think the parallelism vs. concurrency distinction matters much here... but again, definitely happy to see some concrete data that suggests otherwise!
- dathinab 2y ago
  yes no of the issues are affecting the outcome of the blog about memory mapped files > The threads backing the single-threaded IO are an implementation detail of fulfilling the `.read().await` calls. IMHO it's not just an implementation detail, it's a very relevant design aspect for anything related to blocking and benchmarks. Through yes it doesn't matter to much for this blog.

dbaupp 2y ago

(Author here) > The singled thread async "traditional IO" example is NOT single threaded The threads backing the single-threaded IO are an implementation detail of fulfilling the `.read().await` calls. The key is that there's a single coordinator thread that's issuing all the work, with the user-space runtime multiplexing tasks on that thread. I thought the fact that the "start a request and come back when it is finished" behaviour happens to be implemented via user-space threads rather than kernel-level epoll (or similar) is unlikely to affect behaviour. I considered scaling up the number of files and using a multi-threaded runtime, but I felt that'd make everything more complicated without fundamentally changing behaviour. However, maybe my theory is incorrect, in which case someone else can do their own experiments to provide more concrete information. (This is referenced in a footnote: https://huonw.github.io/blog/2024/08/async-hazard-mmap/#fn:tokio-single-threaded https://huonw.github.io/blog/2024/08/async-hazard-mmap/#fn:t... ) > The issue is comparing 8 OS threads no async to 1 thread async is fundamentally not very useful as long as you didn't pin all threads to the same physical core The point is not to benchmark async vs. non-async, but provide a general reference point for "mmap working well" for comparison. As you suggest you agree with the "minor" issue tag, I don't think the parallelism vs. concurrency distinction matters much here... but again, definitely happy to see some concrete data that suggests otherwise!

dathinab 2y ago
yes no of the issues are affecting the outcome of the blog about memory mapped files > The threads backing the single-threaded IO are an implementation detail of fulfilling the `.read().await` calls. IMHO it's not just an implementation detail, it's a very relevant design aspect for anything related to blocking and benchmarks. Through yes it doesn't matter to much for this blog.