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.
Ai cũng tin 'load average = mức bận CPU'. Nhưng trên Linux nó đếm cả tiến trình kẹt chờ I/O — 4 tiến trình chờ đĩa đẩy load lên 4 dù CPU nhàn tênh. Cùng con số load 8, hai căn bệnh trái ngược. Và nó còn dâng chậm vì làm mượt. Đo thật hai lầm tưởng của chính tôi.
-fomit-frame-pointer không bỏ khung ngăn xếp — nó chỉ bỏ con trỏ khung x29, tiết kiệm một lệnh và giải phóng một thanh ghi. Khung vẫn được cấp. Đo thật bằng prologue/epilogue trong assembly.
Người ta bảo muốn biết cache-miss hay branch-miss thật thì phải có perf và bộ đếm phần cứng. Máy tôi đo thì perf còn chẳng chạy — VM khóa luôn PMU. Vậy mà chỉ với một cái đồng hồ và một thí nghiệm đổi đúng một biến, branch-miss vẫn hiện ra rõ mồn một, chậm gần 7 lần.
Cấp phát 2GB tức thì: VmSize +2GB nhưng VmRSS +0. Tôi chạm hết 2GB đó để cấp RAM, mà RSS vẫn đứng im — vì đọc bộ nhớ mới chỉ trỏ vào một trang zero chung, không cấp RAM riêng. Chỉ GHI mới biến ảo thành thật. Đo thật bằng /proc/self/status.
Ai cũng thuộc 'linked list chèn/xóa O(1), mảng O(N)'. Tôi đo thử: chèn ở đầu list nhanh hơn mảng 70.000 lần — nhưng chèn giữa THỰC TẾ (phải tìm vị trí trước) thì list lại chậm hơn mảng 16 lần, vì duyệt để tìm là cache miss mỗi bước. O(1) chỉ đúng khi đã cầm sẵn con trỏ.
std::unordered_map dùng chaining nên chaining là cách nhanh nhất xử lý va chạm? Đo ra: open addressing (dò trong một mảng liền) tra cứu nhanh hơn ở hệ số tải vừa (10,4 vs 15,1 ns ở tải 0,5) và gọn hơn 3,4 lần bộ nhớ. Nhưng ở tải 0,9, dò dồn cụm trung bình 5,45 lần khiến open chậm hẳn và chaining vượt lên — một điểm giao rõ ràng.