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.
Tách đường nóng khỏi đường lạnh nghe như tăng tốc rõ. Tôi đo: compiler đã tự đẩy khối unlikely xuống cuối hàm, thân vòng nóng sạch bong không một lệnh lạnh — nhưng thời gian chỉ đổi ~1%, chìm trong nhiễu. Vì đây là tối ưu bố cục i-cache, chỉ hiện lợi ở quy mô lớn, không ở một vòng nhỏ.
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.
Tưởng cứ thêm #pragma omp parallel for lên mọi vòng là song song hóa được? Tôi đo vòng gộp sum += a[i]: parallel ngây thơ cho kết quả SAI, mất 90% cập nhật — không chậm mà sai thầm lặng; sửa bằng atomic thì đúng nhưng chậm 267 lần; chỉ reduction vừa đúng vừa nhanh. Nhận ra phụ thuộc trước khi song song.
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.