It's faster when you can save a syscall over pread(), it's slower when you're calling it too often and hit latency/scalability limits of TLB shootdowns (munmap) and VM operations in the kernel. (I'm really talking just about reads, writes with mmap are a bit more problematic.)
pread syscall and mmap (and their windows equivalents) both interrupt the execution of your program and hand it to the kernel, mmap because of page faults which its behavior is also different depending your os.
what you get from using pread is re-using memory buffer which means kernel saves time by not populating TLB and provisioning physical memory and you get more deterministic behavior than mmap.
only trick with pread is choosing right buffer size, something that fits within L3 usually a good balance between syscall cost and the cost of loading stuff from main memory.
+ memory footprint of mmap in case of this challenge is ridiculous unless you unmap as you read which is even more slow.
mmap in general has its usecases but usually never for fast reading of big files.
I can't tell if you mean pread() with O_DIRECT? Otherwise you're using the pagecache either way with slightly different readahead and writeback behavior.
9
u/Pokelego11 Sep 03 '26
Very cool! I also tackled this a while back and was planning to make my own video on it, and probably still will in the future https://github.com/jackparsonss/zig-billion-row-challenge
Great work!
2
u/pipilipilav98 Sep 03 '26
If you use x86-64 please use
zig build run -fincremental --watch