Tưởng hai biến khác nhau, mỗi luồng ghi biến của riêng mình thì không thể ảnh hưởng nhau? Tôi đo: chúng làm nhau chậm 2,05 lần ở 8 luồng vì tình cờ nằm chung một dòng cache 64 byte — false sharing. Căn lề mỗi biến sang một dòng riêng thì nhanh gấp đôi, dù logic không đổi một chữ. Bug hiệu năng vô hình trong mã nguồ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.
Tưởng future/async tự động nhanh và rẻ? Tôi đo bằng C++: future.get() là một điểm đồng bộ chặn tới khi promise set, và std::async mặc định tạo một luồng mới cho mỗi task — chạy hai vạn task nhỏ bằng async chậm hơn tuần tự 1724 lần. Future tiện cho một kết quả, không phải phép màu song song.
Đánh dấu constexpr là chắc chắn tính sẵn lúc biên dịch, 0 chi phí? Tôi đo và phát hiện chữ đó hứa ít hơn tưởng. Đặt kết quả vào biến constexpr thì nó thành literal đọc 0,227 ns; gọi đúng hàm ấy với đầu vào động thì nó chạy nguyên vòng lặp lúc chạy, 45625 ns. Ngữ cảnh mới quyết định, không phải từ khóa.
Trực giác bảo lệnh đọc phải đợi lệnh ghi xuống cache. Đo trên host ARM thì không: store buffer chuyền thẳng giá trị vừa ghi, ghi-đọc khớp chỉ 1,55 ns (~7 chu kỳ). Nhưng cái 'store-forwarding stall' mà dân x86 sợ chết khiếp, ở đây chỉ đắt thêm 18%. Thứ thật sự chi phối lại là chuyện khác.
__builtin_prefetch nghe như nút tăng tốc cho code nghẽn bộ nhớ, nhất là truy cập ngẫu nhiên và con trỏ đuổi. Tôi đo trên máy này và mọi thứ lật ngược: prefetch giúp truy cập tuần tự (~1,5 lần), vô ích cho gather ngẫu nhiên, và bất lực với con trỏ đuổi. Một bài học về việc prefetch phụ thuộc phần cứng đến mức nào.