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.
PGO tối ưu theo hồ sơ chạy thật thay vì đoán tĩnh. Tôi đoán hồ sơ sai (thu trên dữ liệu lệch ngược) sẽ làm nó chậm hơn cả -O2 vì tối ưu nhầm nhánh — đo ra không hề: với một nhánh trong vòng nóng, PGO vẫn nhanh y hệt, vì cái nó thắng là bố cục mã, không phải hướng nhánh mà CPU đã tự đoán.
-ffast-math nghe như nút tăng tốc miễn phí cho code toán. Tôi đo: cùng tổng 20 triệu float, -O3 cho 1999531776 trong 0,571 ns/phần tử, còn -ffast-math cho 1999546496 trong 0,143 ns — nhanh 4 lần nhưng KHÁC kết quả, vì nó sắp lại phép cộng để vector hóa mà số thực máy không kết hợp. Tốc độ đổi lấy độ chính xác.
Ai cũng biết compiler tính sẵn 2+3 thành 5. Tôi đo xem nó đi xa tới đâu: cùng một hàm ba phép nhân, khi đầu vào là hằng 100 thì gcc gấp toàn bộ thành một literal 64-bit (5 lệnh, 0 phép nhân, 0 ns); khi đầu vào từ volatile thì phải tính đủ (22 lệnh, 3 phép nhân, 0,99 ns). Ranh giới nằm ở một câu hỏi.