Tưởng CPU luôn chạy theo thứ tự mình viết, còn reorder bộ nhớ chỉ là lý thuyết trong sách? Tôi đo litmus store-buffer trên ARM: reorder xảy ra thật (11 ca trong 60 triệu vòng), rào dmb ish dập được về 0. Nhưng nó hiếm tới ~1 trên 5,5 triệu vòng — nên code sai vẫn qua sạch mọi test rồi nổ ở production.
Tưởng thread-local storage miễn phí như biến toàn cục, hoặc chậm không đáng dùng? Tôi đo ra ở giữa: truy cập TLS chỉ đắt hơn global 4% (một lệnh đọc con trỏ luồng), nhưng dùng TLS làm bộ đếm cục bộ nhanh hơn atomic chung 385 lần vì xóa sạch tranh chấp. Và chính phép đo TLS suýt cho tôi một con số rác 13.000 lần.
Tưởng cond_wait thức dậy là điều kiện đã đúng, dùng if là đủ, và đánh thức gần như tức thì? Tôi đo: đánh thức tốn ~8,5µs (đúng một chuyển ngữ cảnh), busy-poll nhanh 245 lần nhưng đốt trọn một lõi, và spurious/lost wakeup bắt buộc phải while + mutex — bỏ một trong hai là mời một bug đua tranh không tài nào tái hiện.
Tưởng throughput hàng đợi chỉ phụ thuộc tốc độ xử lý, hoặc hàng đợi càng lớn càng nhanh? Tôi đo: đẩy/lấy từng phần tử chỉ 6,8 triệu op/s vì chi phí đồng bộ mỗi lần bàn giao, gom lô lên 50,6 (7,4 lần), và kích thước hàng đợi chỉ giúp tới điểm bão hòa. Kẻ giết throughput là đồng bộ per-item, không phải xử lý.
Tưởng tạo luồng mỗi việc là ổn cho việc nhỏ, hoặc thread pool là kỹ thuật rườm rà thừa? Tôi đo: 20.000 việc nhỏ kiểu thread-per-task mất 989ms vì chi phí tạo luồng ~47µs lấn át việc thật, còn thread pool nhanh 125 lần với số worker quanh số lõi — quá nhiều worker lại chậm đi. Một chi phí nhỏ nhân số lần lớn thành nút thắt khổng lồ.
Tưởng một hàng đợi chung là đủ, hoặc chia việc tĩnh đều là tối ưu? Tôi đo: hàng đợi chung sụt throughput khi đông worker vì tranh khóa, còn work-stealing scale 4,5 lần và tự cân bằng cả khi dồn hết việc vào một worker (nhanh 5 lần) — nhưng trộm cũng có giá, việc tí xíu thì trộm còn chậm hơn.