Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
Truy cập ngẫu nhiên trên 1 GB: trang 4KB mất 138 ns/lần, trang lớn 2MB chỉ 114 ns — phần chênh là chi phí lỗi TLB. Nhưng lần đầu hai bản nhanh y hệt, vì THP=always khiến cái 'nền 4KB' của tôi thực ra là trang lớn. Xác minh điều kiện, đừng suy từ ý định. Đo thật.
Hash map được hứa O(1), nên tưởng mọi lần tra/chèn nhanh như nhau. Đo latency từng lần chèn: trung vị 42 ns, nhưng có một lần 9,8 mili giây khi bảng rehash cả 2 triệu phần tử — chậm hơn 233.000 lần. Tra cũng chậm dần theo load factor, và hàm băm xấu đẩy probe lên 5707. O(1) là trung bình khấu hao. Tôi đo bằng C.
Khi hết RAM, nhân giết ai? Không phải kẻ vừa xin làm tràn, mà KẺ TO NHẤT — một tiến trình ngoài cuộc đang ngồi yên. Đo thật bằng oom_score và dmesg.
Cần thêm phần tử ở đầu danh sách? Nhiều người bảo dùng vector cũng được. Tôi đo thử — và vector push_front hóa ra là O(n): mỗi lần thêm gấp đôi thời gian khi số phần tử gấp đôi (1552 → 3375 ns), vì nó phải dịch cả mảng. Một ring buffer chỉ lùi một chỉ số, O(1) (~3 ns), nhanh hơn 1136 lần ở N=100k. Còn std::deque thì push được hai đầu O(1), duyệt chỉ chậm hơn vector 19%.
Chạm 200MB anon chỉ sinh 102 lỗi trang, không phải 51200 — vì trang lớn THP. Và đọc file lạnh từ đĩa chỉ đếm 1 major fault dù chậm gấp 27 lần cache — vì readahead. Đo thật bằng getrusage.
Chỉ cache mới quyết định tốc độ truy cập bộ nhớ? Đo ra: cùng ~128KB dòng cache chạm y hệt nhau, nhưng dữ liệu trải rộng trên 1024 trang chậm gấp 15 lần so với gói gọn trong ~16 trang — 14 ns so với 0,9 ns. Thủ phạm là TLB: bộ nhớ đệm dịch địa chỉ ảo sang vật lý. Trải nhiều trang hơn TLB chứa được thì mỗi truy cập trả thêm một lần đi bảng trang.