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.
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.
200 luồng chiếm 1612 MB VSZ nhưng chỉ 1,6 MB RAM thật (8KB mỗi luồng) — ngăn xếp 8MB là ảo, cấp lười. Guard page dưới mỗi stack biến tràn thành SIGSEGV chính xác, độ sâu đệ quy tỉ lệ thẳng cỡ stack (8MB ≈ 7939 tầng). Và -O2 suýt biến đệ quy vô hạn thành vòng lặp, đo nhầm hoàn toàn.
Tách đường nóng khỏi đường lạnh nghe như tăng tốc rõ. Tôi đo: compiler đã tự đẩy khối unlikely xuống cuối hàm, thân vòng nóng sạch bong không một lệnh lạnh — nhưng thời gian chỉ đổi ~1%, chìm trong nhiễu. Vì đây là tối ưu bố cục i-cache, chỉ hiện lợi ở quy mô lớn, không ở một vòng nhỏ.
Nhân học sinh O(n²) đáng ra phải thua Karatsuba O(n^1,585) — nhưng đo ra nó thắng tới tận ~1024 hạn (~9.800 chữ số). Ở 64 hạn Karatsuba còn chậm hơn 2,8 lần vì hằng số ẩn của đệ quy. Và mọi phép số lớn chậm hơn nhân 64-bit gốc hàng trăm nghìn lần. Bậc tốt hơn không tự động nhanh hơn. Tôi đo.
Tưởng atomic miễn phí, lock-free nên không bị tranh chấp, luôn nhanh hơn mutex nhiều lần? Tôi đo cả ba đều lệch: atomic không tranh chấp chỉ ~1,6ns (rẻ hơn mutex 2 lần, cùng bậc), fetch_add tranh chấp vẫn chậm 10 lần vì cache nảy, và vòng CAS 8 luồng chậm hơn cả mutex vì phải thử lại. Lock-free không phải contention-free.
Một kết nối rảnh có peer chết âm thầm: TCP mặc định mất ~2 giờ 11 phút mới phát hiện. Đặt ba núm keepalive thì xuống đúng IDLE + CNT×INTVL giây — vài giây. Đo thật công thức, kèm một bug 'hai chữ timeout' suýt làm tôi kết luận keepalive không chạy.