Tưởng getpid() được glibc cache nên gần như free, và hàm nào trông như syscall cũng vào kernel? Tôi đo: một syscall thật ~103ns (450× một phép tính), getpid glibc không còn cache nên vẫn 100ns, còn clock_gettime qua vDSO chỉ 12,7ns vì chạy hẳn trong user mode. 'Trông như syscall' không quyết định giá.
Tưởng exec chỉ là nhảy vào chương trình mới nên tức thì? Tôi đo: execve tốn 45,6µs cho binary tĩnh (nạp ELF, ánh xạ segment), và 73,5µs cho binary động — chậm 1,61 lần dù file nhỏ hơn 12 lần, vì trình liên kết ld.so phải phân giải symbol trước main. Nhỏ trên đĩa không bằng nhanh lúc chạy.
Tưởng đọc file thì luôn chạm đĩa nên chậm? Tôi đo: lần đọc thứ hai được page cache phục vụ từ RAM ở 39 GB/s — không chạm đĩa, nhanh 4,3 lần đọc nguội. Còn O_DIRECT cố ý bỏ qua cache nên chậm NHẤT — 'gần phần cứng' không có nghĩa 'nhanh hơn'.
Tưởng chỉ cache dữ liệu (L1/L2/L3) quyết định tốc độ truy cập bộ nhớ? Còn một cache thứ hai: TLB — cache dịch địa chỉ. Cùng vùng 67MB, dữ liệu và cache y hệt, chỉ đổi trang 4KB sang huge page 2MB đã nhanh 1,52 lần — ~19ns chênh là TLB miss thuần.
Tưởng bật huge page thì luôn nhanh hơn, một tinh chỉnh miễn phí? Tôi đo: nó chỉ giúp khi TLB là nút thắt — vùng 0,3MB vừa TLB chỉ nhanh 1,13 lần, phải tới 67MB vượt TLB mới thắng 1,66 lần. Và có mặt trái: mỗi page fault huge phải zero cả 2MB, khựng ~40µs — 105 lần một fault thường.
Tưởng CPU luôn chạy theo thứ tự mình viết, còn reorder bộ nhớ chỉ là lý thuyết trong sách? Tôi đo litmus store-buffer trên ARM: reorder xảy ra thật (11 ca trong 60 triệu vòng), rào dmb ish dập được về 0. Nhưng nó hiếm tới ~1 trên 5,5 triệu vòng — nên code sai vẫn qua sạch mọi test rồi nổ ở production.