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.
Trie luôn tốt hơn hash cho chuỗi? Tôi đo thử: trie tốn RAM gấp 11 lần hash (256 MB vs 23 MB) và exact match chỉ ngang nhau. Nhưng trie thắng tuyệt đối một việc hash không làm nổi: tra tiền tố / autocomplete — 94 lần nhanh hơn, vì hash phải quét toàn bộ tập. Chọn theo có cần prefix hay không.
Chạm giới hạn fd cho lỗi EMFILE tự nâng được không cần root; nhưng nâng xong lại đụng một trần khác (ENFILE toàn hệ thống) không phải của mình. Đo thật trong container, và để errno nói thật đang chạm trần nào.
Khi số giá trị sống cùng lúc vượt số thanh ghi, trình dịch phải đổ bớt ra stack (spill). Nhưng áp lực đến từ giá trị sống đồng thời, không phải số biến khai báo — 40 biến dùng tuần tự vẫn 0 tràn. Và chi phí tràn thật, khi cô lập đúng, chỉ ~3%. Đo thật trong container.
Bật -O3, vòng nhân mảng float nhanh 3,9 lần nhờ NEON làm 4 float mỗi lệnh. Nhưng chỉ thêm một phụ thuộc chuỗi là trình biên dịch lặng lẽ bỏ vector hóa, tụt về scalar chậm 11,6 lần — không một dòng cảnh báo. SIMD không phải phép màu của cờ, mà là phần thưởng cho vòng viết đúng dạng. Tôi đo.
Sao chép cả một tiến trình 256MB nghe phải mất hàng chục mili giây. Đo ra 133 micro giây, nhanh gấp trăm lần — vì fork nhân bảng trang chứ không chép byte. Rồi tôi suýt kết luận sai thủ phạm, cho tới khi tách 'đã cấp phát' khỏi 'đã chạm'. Và hóa ra fork là phần rẻ nhất; exec mới đắt. Đo thật trong container.
Ai cũng khuyên 'bộ đếm đa luồng thì dùng atomic thay mutex cho nhanh'. Đo ra atomic nhanh gấp 3 thật — nhưng thêm luồng vào thì cả atomic lẫn CAS đều TỤT, vì cùng nảy một dòng cache. Cách thật sự scale là không chia sẻ, và nó nhanh hơn atomic 42 lần. Đo thật.