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 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.
Tưởng lặp nanosleep(period) là timer định kỳ chính xác? Tôi đo: nó trôi 61ms sau 200 tick 1ms (lệch 30,6% mỗi chu kỳ!) vì sai số dồn lại, còn timerfd/setitimer giữ kỳ hạn tuyệt đối nên drift không tích lũy (setitimer mất đúng 0,1% tick). Khác biệt là bản chất.