Đọc bộ đếm chu kỳ của CPU là đếm được số chu kỳ? Đo trên host ARM: bộ đếm timer cntvct chạy tần số cố định 24 MHz, còn CPU chạy ~4,44 GHz — nên một tick bằng 41,67 ns, tức khoảng 185 chu kỳ CPU chứ không phải một. Và mỗi lần gọi steady_clock::now() tốn ~13 ns; đo đoạn ngắn hơn thế thì kết quả toàn là rác. Đây là cách đo cho đúng.
Duyệt ma trận theo hàng hay theo cột — cùng số phần tử, cùng phép cộng, chỉ khác thứ tự — thì như nhau chứ? Đo trên host ARM: ma trận 64MB duyệt theo hàng 0,211 ns mỗi phần tử, theo cột 3,79 ns — chậm gần 18 lần. Mỗi lần chạm cột rơi vào một dòng cache riêng, CPU nạp 128 byte nhưng chỉ dùng 4, phí 31/32 dòng và cộng cả lỗi TLB. Thứ quyết định không phải số phần tử, mà số byte dòng cache phải kéo.
Gán số nguyên cho biến float trông như miễn phí — 'đều là số' mà. Đo trên host ARM: một phép cộng int tốn ~1 chu kỳ, nhưng vòng chuyển khứ hồi (int)((float)v+1) trên chuỗi phụ thuộc tốn 4,3 ns — khoảng 19 chu kỳ, gấp 19 lần. int và float là hai thế giới riêng trong CPU, và các phép ép kiểu ngầm trong biểu thức trộn kích hoạt lệnh chuyển đổi mà bạn không hề viết ra.
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.