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.
Đọc một byte thì chỉ tốn một byte băng thông? Đo ra: CPU nạp cả một dòng cache mỗi lần chạm bộ nhớ, nên đọc thưa (mỗi phần tử một dòng) chậm gấp 10 lần đọc liền. Và ngưỡng bão hòa lộ kích thước dòng thật của máy: host ARM này (Apple Silicon) dùng dòng 128 byte, không phải 64 byte như x86 quen thuộc.
Thêm luồng vào một khóa chung làm thông lượng SỤP: 226 xuống 27 triệu ops/giây khi lên 2 luồng — mở rộng âm. Chia nhỏ khóa vẫn tụt sau 2 luồng vì chia sẻ giả (các biến chung dòng cache). Chỉ khi đệm mỗi luồng ra riêng một dòng cache mới scale gấp 6. 'Song song' cần độc lập cả về khóa lẫn dòng cache.
Kết sê-ri 45 phần bằng một phép đo gói trọn luận điểm: cùng 10 triệu số nguyên, cùng phép tính tổng O(n), nhưng mảng liền mạch chạy 0,225 ns mỗi phần tử còn mảng con trỏ rải rác 5,48 ns — chênh 24 lần chỉ vì cache và con trỏ, thứ mà Big-O hoàn toàn giấu. Bài học cả sê-ri: đừng đoán, hãy đo — và đo cho đúng.
Câu đố kinh điển trên Stack Overflow: cùng một vòng lọc, mảng đã sắp xếp chạy nhanh hơn hẳn mảng xáo trộn. Tôi dựng lại thí nghiệm trên máy ARM và thấy hai điều: hồi đó nó đúng, và bây giờ thì g++ đã âm thầm dẹp luôn cái hiệu ứng ấy.
Căn lề mã cho tốc độ ổn định, cứ tăng -falign-loops là tốt? Tôi đo và thấy tác động nhỏ (~2%) và thất thường trên ARM. Quan trọng hơn: căn lề mã chính là nguồn nhiễu benchmark khét tiếng — giữ hot loop y hệt, chỉ chèn một hàm chết để dịch địa chỉ, thời gian đổi ~4%, còn lớn hơn cả việc cố ý chỉnh căn lề.
Phải dùng builtin/intrinsics mới nhanh, viết C tay luôn chậm? Tôi đo và thấy đúng nửa: builtin thắng rõ ở phép C không có cách viết tự nhiên (popcount nhanh 1,8 lần), nhưng nhiều phép compiler tự nhận mẫu — đảo byte viết tay bằng shift/mask cũng ra đúng một lệnh rev, bằng builtin. Đo trước khi cho rằng viết tay là chậm.