Đá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.
Thêm likely/unlikely tưởng tăng tốc nhánh rõ rệt. Tôi đo và thấy một canh bạc bất đối xứng xấu: mách đúng thì lợi gần như bằng không (bộ dự đoán nhánh động của CPU đã lo hướng), nhưng mách sai làm chậm 10%. Cái nó đổi chỉ là bố cục mã, không phải hướng đoán — nên hãy để PGO lo, đừng rắc theo cảm tính.
Compiler luôn kéo mọi thứ bất biến ra khỏi vòng? Đúng với số học thuần, và nó còn hoist cả strlen khi thân chỉ đọc. Nhưng một phép ghi vào chuỗi trong thân chặn đứng nó: for(i<strlen(s)) sửa chuỗi thành O(n²) thật — n=32.000 chậm 990 lần. Biên giới của tối ưu là aliasing.
Ai cũng bảo tránh virtual cho nhanh. Tôi đo và thấy nó phụ thuộc một thứ lời khuyên đó bỏ qua: khi một điểm gọi chỉ thấy một kiểu (monomorphic) thì gọi ảo gần bằng gọi trực tiếp — 0,722 ns; chỉ khi nhiều kiểu trộn khó đoán (megamorphic) mới chậm 6,6 lần. Cái đắt là đích nhảy khó đoán, không phải từ khóa virtual.