Tưởng atomic miễn phí, lock-free nên không bị tranh chấp, luôn nhanh hơn mutex nhiều lần? Tôi đo cả ba đều lệch: atomic không tranh chấp chỉ ~1,6ns (rẻ hơn mutex 2 lần, cùng bậc), fetch_add tranh chấp vẫn chậm 10 lần vì cache nảy, và vòng CAS 8 luồng chậm hơn cả mutex vì phải thử lại. Lock-free không phải contention-free.
200 luồng chiếm 1612 MB VSZ nhưng chỉ 1,6 MB RAM thật (8KB mỗi luồng) — ngăn xếp 8MB là ảo, cấp lười. Guard page dưới mỗi stack biến tràn thành SIGSEGV chính xác, độ sâu đệ quy tỉ lệ thẳng cỡ stack (8MB ≈ 7939 tầng). Và -O2 suýt biến đệ quy vô hạn thành vòng lặp, đo nhầm hoàn toàn.
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.
Tưởng thêm lõi thì tăng tốc tỉ lệ, và code gần như song song hoàn toàn sẽ scale gần tuyến tính? Tôi đo: một phần tuần tự nhỏ chặn speedup rất mạnh — 25% tuần tự trần ở 4 lần dù bao nhiêu lõi, và thực tế còn dưới cả Amdahl vì chi phí ẩn. Muốn nhanh hơn phải cắt phần tuần tự, không phải đếm lõi.
Thêm __builtin_expect(UNLIKELY) vào nhánh hiếm, tôi mong nhanh hơn. Đo ra bằng y hệt bản không hint — vì trình dịch đã đoán đúng sẵn. Cái duy nhất đổi thời gian lại là một hint SAI. Đo thật, đọc assembly trong container.
Tưởng nhiều luồng thì luôn nhanh hơn, hay cứ đặt số luồng bằng số lõi? Tôi đo hai loại việc trái ngược: việc thuần CPU chững ở ~nproc (thêm luồng vô ích), còn việc chờ-bound thì tối ưu vượt xa nproc — 80 luồng trên 10 lõi vẫn cho throughput gấp 8 lần vì luồng ngủ không chiếm lõi. Không có số luồng vàng.