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 đ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.
Microbenchmark báo 0,9 ns mỗi phần tử, lên production chậm gấp trăm lần — code không sai, dữ liệu đã đổi cỡ. Đo trên host ARM: cùng một thao tác O(n) đuổi con trỏ, 0,91 ns khi vừa L1, 104 ns khi ra RAM — chênh 114 lần. Vẽ ns/phần tử theo working set ra một đường bậc thang, và 'O(n) là tuyến tính' hóa ra chỉ đúng trong một tầng cache.
Đọc mã nguồn cả ngày cũng không thấy tranh chấp: hai luồng, hai biến riêng, không đụng nhau. Vậy mà chậm ~3,7 lần chỉ vì hai biến tình cờ nằm chung một cache line. Nút thắt vô hình ở tầng mã nguồn, chỉ lộ khi nhìn xuống bố trí bộ nhớ. Đo thật, và cách săn nó.
Ghim CPU vào một nhân nghe hợp lý: cache ấm, không bị dời, chạy nhanh hơn. Nhưng đo ra ghim không hơn tự do — máy rảnh, dưới tải, kể cả khi ép dời liên tục. Vì bộ lập lịch đã tự giữ cache ấm, và phần cứng chia sẻ cache khiến dời rẻ. Tôi đã đo cho một lợi ích đã có sẵn. Đo thật.
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.