Tưởng select, poll, epoll như nhau chỉ khác cú pháp API? Tôi đo: select/poll là O(N) — quét cả danh sách fd mỗi lần, poll bung từ 1,9µs (100 fd) lên 203µs (10.000 fd); epoll O(1) phẳng ~130ns bất kể N, nhanh gấp 1.540 lần ở 10.000 fd. Bề mặt giống nhau, độ phức tạp thì không.
Tưởng speedup = thời gian 1 luồng / N luồng là đủ, và scaling tuyến tính tới số lõi? Tôi đo: 10 lõi chỉ cho 4,65x (không phải 10x), và nếu lấy baseline sai (bản song song 1 luồng thay vì tuần tự tốt nhất) thì con số bị thổi phồng đều 6,2 lần. Speedup là một phân số, và mẫu số nào cũng nói dối được.
Tưởng lock-free luôn nhanh hơn có khóa nên cứ bỏ mutex đi? Tôi đo: hàng đợi SPSC lock-free nhanh hơn mutex 3 lần vì hai bên ghi hai chỉ số riêng không tranh; nhưng nhiều producer cùng đẩy vào một hàng đợi thì ở 8 producer lock-free lại thua mutex, vì đụng đúng bức tường cache. Lock-free nhanh khi không có ghi chung, và cái giá là code khó viết đúng.
Tưởng chia đều số phần tử cho mỗi lõi là cân bằng tải? Tôi đo: khi mỗi phần tử tốn khác nhau, chia khối làm một luồng thành kẻ tụt hậu (lệch 21,7 lần), tổng thời gian kẹt ở luồng chậm nhất chứ không phải trung bình; chia xen kẽ san đều gần miễn phí. Và một cái rào ngầm suýt che mất toàn bộ hiện tượng khi tôi đo.
Tám luồng bận không ghim: nhân tự trải ra tám lõi khác nhau, 854.562 đơn vị công việc. Ghim hết vào một lõi tưởng 'kiểm soát tốt' nhưng chỉ được 165.906 — bằng 1/5, chín lõi ngồi không. Affinity tốt cho một luồng nóng nhưng phản tác dụng khi gom nhiều luồng song song.
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.