Đoán sai một nhánh chỉ chậm đi một chút? Đo ra: quét tỉ lệ nhánh được lấy từ 0% đến 100%, thời gian vẽ thành một hình chuông đỉnh ở 50% — nhánh đoán được (0% hoặc 100%) tốn 0,24–0,45 ns còn nhánh 50/50 tốn 2,38 ns. Từ đó suy ra phạt mỗi lần đoán sai ~3,86 ns, tức khoảng 12 chu kỳ CPU — đúng cỡ một lần xả pipeline.
rand() % 20000 đo ra lệch đúng 2 lần giữa hai vùng giá trị vì 32768 không chia hết cho 20000. Bit thấp nhất của LCG chỉ đảo 0,1,0,1 — chu kỳ 2, tất định hoàn toàn. Còn xorshift chạy 717 triệu số/giây, nhanh hơn rand() 2,8 lần nhưng tuyệt đối không dùng được cho mật mã. 'Ngẫu nhiên' là tính chất phải đo. Tôi đo.
Con trỏ hàm với std::function bị mang tiếng là chậm vì gọi gián tiếp. Nhưng đo ra, khi đích ổn định — kể cả một mẫu lặp đều đặn — nó nhanh gần bằng gọi thẳng. Chỉ khi đích nhảy loạn khó đoán mới chậm gấp 6 lần. Cái quyết định không phải bản thân cú gọi gián tiếp, mà là CPU có đoán nổi bạn sắp gọi ai.
Tưởng đo NUMA được ở mọi máy nhiều lõi, và thêm luồng thì băng thông bộ nhớ tăng tuyến tính? Máy đo chỉ 1 node nên không có NUMA để đo — tôi báo trung thực chứ không bịa số. Nhưng cục bộ thì đo được và khổng lồ: đọc tuần tự nhanh hơn ngẫu nhiên 405 lần, băng thông chung chỉ scale 5,4 lần, chia dữ liệu gần luồng nhanh hơn rải 3,3 lần.
Tưởng một cấu trúc chung với một khóa là đủ, hoặc càng nhiều shard càng tốt? Tôi đo: một khóa chung sụp từ 229 xuống 35,7 triệu op/s khi đông luồng, chia nhiều shard giúp throughput scale 3 lần — nhưng càng nhiều shard, tính tổng toàn cục càng đắt (65 nghìn shard mất 32,8µs). Sharding dời chi phí chứ không xóa.
Tưởng nanosleep(1µs) ngủ đúng 1µs? Tôi đo: yêu cầu 1µs thực ngủ 15,8µs (gấp 16 lần!), 10µs thành 60µs — có một cái sàn ~15µs vì đánh thức một luồng là cả một lần lập lịch lại. Ngủ ≥100µs mới sát; muốn trễ dưới µs phải busy-spin, đốt CPU.