Bài kết của sê-ri 45 phần đo thật về đồng thời. Ba tầng bài học và những con số đáng nhớ — tạo luồng 47µs, 10 lõi chỉ 4,65 lần, atomic tranh chấp chậm 27 lần, false sharing 4 lần — cùng một điều xuyên suốt: với đồng thời, đoán thì sai, chỉ đồng hồ mới nói thật.
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 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.
Kiểu số nào cũng 'một phép tính' nên tốc độ như nhau? Đo trên host ARM: cùng một phép trên mảng, khi vector hóa thì int8 nhanh gấp 10 lần int64 — thanh ghi NEON 128-bit gói 16 số int8 nhưng chỉ 2 số int64 mỗi lệnh. Dữ liệu lớn (memory-bound) kiểu hẹp cũng thắng ~9 lần vì ít byte. Nhưng ở chế độ vô hướng mọi kiểu int lại y hệt, và kiểu nhỏ dễ tràn — nên quy tắc là hẹp nhất đủ dùng.
execve thay ảnh tiến trình tại chỗ: cùng PID, chương trình khác, và nạp lười nên exec file 64MB (354µs) nhanh ngang file 70KB (392µs). Tôi bọc nó bằng printf trước và sau để đo — cả hai đều mất, vì execve vứt bộ đệm chưa xả và không trở về khi thành công. Phải fflush trước và đo từ tiến trình cha.
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'.