Page cache giữ file trong RAM để đọc lại tức thì (Cached 5,5GB, đọc 256MB ở ~36GB/s, 0 lỗi trang nặng). Nhưng trong container tôi không tạo nổi lần đọc 'nguội': overlayfs không có đĩa chậm thật bên dưới, FUSE thì bỏ qua page cache khách nên luôn chậm. Đo I/O trong container là đo tầng ảo hóa, không phải đĩa.
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.
Chạy một lần bấm giờ là biết cấu trúc nào nhanh hơn? Đo ra bốn cái bẫy: lần chạy đầu chậm 1,5 lần (cache lạnh, page fault); nếu quên volatile SINK thì -O2 xóa sạch vòng lặp và đo ra 0 ns (số bịa); đo một thao tác đơn cho 84 ns rác (toàn overhead đồng hồ) so với 0,23 ns thật; và nhiễu OS chỉ làm chậm nên phải lấy min, không lấy trung bình.
Tưởng khóa nhiều mutex thì thứ tự nào chẳng được, chạy thử thấy chạy là ổn? Tôi tái hiện deadlock thật: hai luồng khóa ngược thứ tự treo cứng — nhưng chạy đúng hàng nghìn vòng, treo ở thời điểm khác nhau mỗi lần. Thuốc là áp một thứ tự khóa toàn cục, hoặc trylock+backoff.
sendfile gộp cả file 512 MB vào ĐÚNG 1 lời gọi thay vì 16.384 read+write. Nhưng trên loopback cache ấm, tốc độ thô của nó còn thua read+write đệm 64K — và tôi suýt kết luận nó vô dụng. Lỗi nằm ở chỗ tôi đo thông lượng, trong khi sendfile thắng ở CPU/syscall. Đo thật.
Nhân với chia đều là một phép toán nên tốn như nhau? Đo trên host ARM: chuỗi phép nhân số thực chạy 3,3 chu kỳ mỗi phép, nhưng chia số thực tốn 10,7 chu kỳ — gấp hơn ba lần, và gấp mười lần một phép cộng. Số nguyên udiv 8 chu kỳ so với mul 3,2. Nhưng chia cho hằng số thì trình biên dịch biến thành nhân, và lấy dư cho lũy thừa 2 thành phép AND — gần như miễn phí.