4 ms·

It would seem you summarised whole post. That’s the point: “mmap” is slow because it is serial.

arghwhat 1y ago
mmap isn't "serial", the code that was using the mapping was "serial". The kernel will happily fill different portions of the mapping in parallel if you have multiple threads fault on different pages. (That doesn't undermine that io_uring and disk access can be fast, but it's comparing a lazy implementation using approach A with a quite optimized one using approach B, which does not make sense.)
- deleted 1y ago
  [deleted]
- amelius 1y ago
  OK, so we need a comparison between a multi threaded mmap approach and io_uring. Which would be faster?
  - nabla9 1y ago
    If the memory access pattern is the same, there are no significant differences.
    - jared_hulbert 1y ago
      Just ran a version with 6 prefetching threads. I get 5.81GB/s. Same as the io_uring with 2 drives, but still a lot slower than the in memory solution.
- immibis 1y ago
  How do you do embarrassingly async memory access with mmap?
  - lordgilman 1y ago
    You dereference a pointer.
    - icedchai 1y ago
      From the application perspective, it's not truly async. On a deference, your app may be blocked indefinitely as data is paged into memory. In the early 2000's I worked on systems that made heavy use of mmap. In constrained ("dev") environments with slow disks, you could be blocked for several seconds...
      - jlokier 1y ago
        This branch of the discussion is is about dereferencing on multiple threads concurrently. That doesn't block the application, each mmap'd dereference only blocks its own thread (same as doing read()). In my own measurements with NVMe RAID, doing this works very well on Linux for storage I/O. I was getting similar performance to io_uring with O_DIRECT, and faster performance when the data is likely to be in the page cache on multiple runs, because the multi-threaded mmap method shares the kernel page cache without copying data. To measure this, replace the read() calls in the libuv thread pool function with single-byte dereferences, mmap a file, and call a lot of libuv async reads. That will make libuv do the dereferences in its thread pool and return to the main application thread having fetched the relevant pages. Make sure libuv is configured to use enough threads, as it doesn't use enough by default.
        ozgrakkurt 1y ago
        Out of topic but are you able to get performance benefit out of using RAID with NVMe disks?
- rafaelmn 1y ago
  OK this is not my level of stack for over a decade now, but writing a multithreaded code that will generate the same pagefaults on a shared mmap buffer, as opposed to something that kernel io scheduler will do on your behalf, and presumably try to schedule optimally for your machine/workload - does not sound comparable. Thats like arguing python is not slower than C++ because you could technically write a specialized AOT compiler for your python code that would generate equivalent assembly so in the end it is the same ?

mmap isn't "serial", the code that was using the mapping was "serial". The kernel will happily fill different portions of the mapping in parallel if you have multiple threads fault on different pages. (That doesn't undermine that io_uring and disk access can be fast, but it's comparing a lazy implementation using approach A with a quite optimized one using approach B, which does not make sense.)

deleted 1y ago
[deleted]
amelius 1y ago
OK, so we need a comparison between a multi threaded mmap approach and io_uring. Which would be faster?
- nabla9 1y ago
  If the memory access pattern is the same, there are no significant differences.
  - jared_hulbert 1y ago
    Just ran a version with 6 prefetching threads. I get 5.81GB/s. Same as the io_uring with 2 drives, but still a lot slower than the in memory solution.
immibis 1y ago
How do you do embarrassingly async memory access with mmap?
- lordgilman 1y ago
  You dereference a pointer.
  - icedchai 1y ago
    From the application perspective, it's not truly async. On a deference, your app may be blocked indefinitely as data is paged into memory. In the early 2000's I worked on systems that made heavy use of mmap. In constrained ("dev") environments with slow disks, you could be blocked for several seconds...
    - jlokier 1y ago
      This branch of the discussion is is about dereferencing on multiple threads concurrently. That doesn't block the application, each mmap'd dereference only blocks its own thread (same as doing read()). In my own measurements with NVMe RAID, doing this works very well on Linux for storage I/O. I was getting similar performance to io_uring with O_DIRECT, and faster performance when the data is likely to be in the page cache on multiple runs, because the multi-threaded mmap method shares the kernel page cache without copying data. To measure this, replace the read() calls in the libuv thread pool function with single-byte dereferences, mmap a file, and call a lot of libuv async reads. That will make libuv do the dereferences in its thread pool and return to the main application thread having fetched the relevant pages. Make sure libuv is configured to use enough threads, as it doesn't use enough by default.
      - ozgrakkurt 1y ago
        Out of topic but are you able to get performance benefit out of using RAID with NVMe disks?
rafaelmn 1y ago
OK this is not my level of stack for over a decade now, but writing a multithreaded code that will generate the same pagefaults on a shared mmap buffer, as opposed to something that kernel io scheduler will do on your behalf, and presumably try to schedule optimally for your machine/workload - does not sound comparable. Thats like arguing python is not slower than C++ because you could technically write a specialized AOT compiler for your python code that would generate equivalent assembly so in the end it is the same ?