Tính sẵn kết quả vào bảng tra luôn nhanh hơn tính lại lúc chạy? Đo trên host ARM: một hàm băm 4 phép tính lại chỉ tốn 0,330 ns, còn tra bảng thì tùy kích thước — bảng 4KB trong L1 nhanh 0,284 ns, nhưng bảng 1MB (L2) chậm 1,5 lần và bảng 64MB (RAM) chậm 7,6 lần so với tính lại. Trên CPU hiện đại, chạm bộ nhớ xa đắt hơn tính vài phép rẻ — nên châm ngôn cũ đã lật.
Đếm số bit 1 phải lặp qua từng bit? Đo trên host ARM: đếm bit bằng vòng 32 lần tốn 7,83 ns mỗi số, nhưng lệnh phần cứng __builtin_popcount chỉ 0,25 ns — nhanh 31 lần, và còn nhanh gấp đôi cả mẹo tay Kernighan lẫn bảng tra. Bất ngờ hơn: trình biên dịch không tự nhận ra vòng đếm bit để thay bằng lệnh CNT — phải gọi builtin mới có.
Mỗi lần chạm hụt cache phải chờ xong mới tới lần sau, nên N lần miss tốn N lần độ trễ? Đo trên host ARM: đuổi một con trỏ ngẫu nhiên tốn 102 ns mỗi bước, nhưng đuổi 32 con trỏ độc lập song song chỉ còn 3,9 ns mỗi bước — nhanh 26 lần. Lõi thực thi ngoài thứ tự cho hàng chục lần chạm hụt bay cùng lúc. Cùng là truy cập RAM ngẫu nhiên, phụ thuộc hay độc lập chênh nhau 26 lần.
Mỗi lệnh CPU có một chi phí cố định? Đo trên host ARM: cùng một phép nhân tốn 3,2 chu kỳ khi nằm trong chuỗi phụ thuộc, nhưng chỉ 0,4 chu kỳ khi các phép độc lập — chênh 8 lần. Mỗi lệnh có HAI con số: độ trễ và thông lượng. Bất ngờ hơn: cả phép chia số thực cũng chồng được ~8 lần, dù tôi tưởng bộ chia làm từng cái một.
Tưởng bật/tắt cờ rồi bấm giờ một lần là biết nó đáng giá? Tôi đo kiểu ngây thơ (vứt kết quả): ra 0,041 ns vì khử mã chết xóa cả vòng — sai ~25.000 lần và báo scalar bằng vector. Đo đúng cách (volatile sink + warmup + min) mới lộ sự thật: vector hóa ở workload này thực ra CHẬM 1,18 lần. Phương pháp quyết định con số có nói thật.
Tưởng atomic là lock-free nên luôn rẻ, và luôn nhanh hơn mutex? Tôi đo: fetch_add trên một atomic chung 1,6ns khi một luồng nhưng 44ns khi tám luồng — đắt theo số luồng vì cùng nảy một dòng cache; CAS-loop tệ nhất (119ns); còn per-thread nhanh 96 lần. Lock-free nói về ngữ nghĩa, không về chi phí.