New hardwares are now optimized for vectors- The details are explained in part 2

It takes several hundred lines of code but now we can source the data from my SSDs faster than the copy from the page cache in memory.

Because the reading strategy is not mmap but something custom. The author also uses 6 CPU cores for reading and one core for compute. Note that data in a buffer at 13 GiB/s RAM was faster than 6 GiB/s disk array.

The mmap() call presents the process with a buffer that is a blank slate even when the data is already in memory. The buffer is populated page by page as it's accessed from the page cache. This isn't a copy, it's just the operating system mapping the cached memory into the process. This costs more than it might seem. The worst case with mmap() the counting has to pause at every 4KB page boundary while the kernel processes a fault, tracks down the page of data in the page cache, then updates the page table of the process to insert the memory into the process. Fundamentally this is a process that is limited by the memory latency, not the CPU speed or memory bandwidth. With the potential for TLB walks and searching lists that track the page cache, we’re taking potentially dozens of CPU cache misses and several microseconds of waiting on memory for every 4KB page.

On theory

On a proper modern server the CPUs will let you do IO directly to the L3 cache, bypassing memory altogether. Because PCIe bandwidth is higher than memory bandwidth, on paper we could even get more max bandwidth than we can get from memory if we carefully pin the buffers into the CPU cache.
and for the memory:
This means to take advantage of memory performance you have to actually treat it more like a disk and less like Random Access Memory.

A try is made in part 3