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.
Định trưng ra một ca -O3 thua -O2, tôi đo bốn kernel trên gcc 13/ARM và không ca nào -O3 chậm hơn — nó thắng đậm hoặc hòa. Nhưng cái giá thật vẫn đo được, chỉ ở chỗ khác: hàm phình từ 15 lên 47 lệnh. -O3 chắc chắn thêm mã, chỉ CÓ THỂ thêm tốc độ.
Thay nhân bằng dịch bit luôn nhanh hơn rõ, chia hằng thành magic luôn thắng? Tôi đo và cả hai đều tùy: trên ARM hiện đại nhân đã rẻ ngang cộng nên dịch chỉ nhanh hơn tí, còn chia-hằng chỉ thắng ở thông lượng — trong chuỗi phụ thuộc nó còn chậm hơn cả phép chia thật. Compiler tự làm hết, đừng tự tay.
Ai cũng được dạy lưu biểu thức chung vào biến tạm cho khỏi tính lại. Tôi đo và thấy compiler tự làm: bản viết lặp và bản lưu tạm sinh mã giống hệt. Nhưng một phép ghi qua con trỏ có thể trùng lại chặn đứng nó, buộc tính lại — và restrict khôi phục, nhanh 1,34 lần ở phép chia. Aliasing mới là thứ quyế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 khuyên viết branchless (csel/cmov) cho nhanh. Tôi đo cả một đường cong theo độ đoán được và thấy nó chỉ đúng một nửa: nhánh 50/50 khó đoán thì không-nhánh nhanh 5,3 lần, nhưng nhánh 99% dễ đoán thì có-nhánh lại nhanh hơn — vì nhánh dễ đoán gần như miễn phí và còn được bỏ qua việc.