seq_cst đắt hơn relaxed nhiều, cứ hạ memory_order là code nhanh? Đo trên host ARM: relaxed và seq_cst chênh nhau đúng 0 ns — cả một luồng lẫn tám luồng — vì thứ tự nằm sẵn trong lệnh ldar/stlr/ldadd. Cái thật sự đắt là tính atomic (RMW gấp 7 lần ghi thường) và nhất là tranh chấp: tám luồng đập chung một atomic chậm gấp 60 lần tám ô riêng.
Nửa dân lập trình sợ gọi hàm tốn kém nên gộp code lại; nửa kia force-inline mọi thứ. Đo ra một cú gọi hàm chỉ tốn chừng 0,45 nano-giây, và với hàm có việc thật thì con số đó gần như tàng hình. Quan trọng hơn: trình biên dịch đã tự inline hộ bạn đúng chỗ đáng inline rồi.
Thấy 10 CPU thì tưởng chạy 10 luồng nhanh gấp 10 lần. Nhưng đo ra chỉ đạt đỉnh 6,4 lần, rồi thêm luồng nữa còn phẳng lì. Hai lý do: '10 CPU' đôi khi là ảo (SMT gộp hai luồng logic một lõi), và ngay cả lõi vật lý thật cũng không đồng đều — có nhân khỏe nhân yếu.
Nhiều người né hàm ảo ở đường nóng vì nghe nói nó tốn hai lần đọc bộ nhớ cộng một cú gọi gián tiếp. Nhưng đo ra, cùng một dòng obj->f(), lúc thì nhanh y như gọi thường, lúc lại chậm gần 7 lần — và cái quyết định không phải bản thân virtual, mà là các đối tượng bạn duyệt có cùng kiểu hay trộn loạn.
Bấm giờ một lần rồi tin luôn con số? Cùng một đoạn code, 200 lần đo cho con số thấp nhất 23,85 ms nhưng có lần vọt lên 30,50 — cao hơn 28%. Nhiễu chỉ làm phép đo chậm đi chứ không bao giờ nhanh hơn khả năng thật của lõi, nên số nhỏ nhất mới đáng tin, còn trung bình thì bị kéo lệch lên.
Tưởng spinlock luôn nhanh hơn mutex vì không vào nhân? Tôi đo: ở tranh chấp thấp và ít luồng, spinlock nhanh 1,7 lần; nhưng đông luồng hoặc vượt số lõi thì spinlock đốt CPU quay vô ích và chậm hơn mutex 7 đến 36 lần, trong khi mutex gần như phẳng. Không có cái luôn thắng — chọn theo hoàn cảnh, không theo khẩu hiệu.