-Os luôn chậm hơn -O2 vì bỏ tối ưu? Tôi đo cả kích thước lẫn tốc độ và cái nhãn chậm chỉ đúng nửa: -Os cho mã nhỏ nhất trong nhóm tối ưu, và tốc độ thì hỗn hợp — kernel số học nặng chậm 66% vì mất vector, nhưng kernel nhiều nhánh chỉ chậm 9%. Nó là điểm đánh đổi khác, không phải bản chậm.
__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.
Tách đường nóng khỏi đường lạnh nghe như tăng tốc rõ. Tôi đo: compiler đã tự đẩy khối unlikely xuống cuối hàm, thân vòng nóng sạch bong không một lệnh lạnh — nhưng thời gian chỉ đổi ~1%, chìm trong nhiễu. Vì đây là tối ưu bố cục i-cache, chỉ hiện lợi ở quy mô lớn, không ở một vòng nhỏ.
Ghép hai vòng thành một để bớt overhead thì luôn nhanh hơn? Tôi đo và bất ngờ: ghép hai vòng cùng đọc một mảng nhanh 1,8 lần, nhưng ghép hai vòng mỗi vòng ghi một mảng lại chậm 2,75 lần. Thứ quyết định không phải số vòng, mà là số luồng bộ nhớ đan xen trong thân — một bài toán locality.
Tưởng mỗi literal là một vùng nhớ riêng? Tôi đo: compiler gộp các literal trùng thành một bản duy nhất trong .rodata, nên con trỏ tới chúng bằng nhau và binary nhẹ đi. Nhưng chuẩn C không hề bảo đảm điều đó — dựa vào == để so chuỗi là một bug chờ nổ, luôn dùng strcmp.
Ai cũng bảo đặt điều kiện rẻ, hay-sai lên trước để && dừng sớm né phép đắt thì nhanh hơn. Tôi đo và hiệu năng đi ngược: bản bitwise & không nhánh, tính cả hai mọi lần, lại nhanh nhất. Hóa ra giá trị thật của && không phải tốc độ, mà là ngữ nghĩa bảo vệ null — thứ mà đổi sang & là làm crash.