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ỏ.
Tôi tưởng compiler tự chuyên biệt bất kỳ hàm nào gọi với hằng số. Đo lần đầu ở -O2 ra 1,0× — chẳng lợi gì. Hóa ra bản clone chuyên biệt chỉ bật ở -O3: khi đó hằng được nướng vào, phép chia hóa thành nhân ma thuật, nhanh 1,3 lần. Một tối ưu có trong compiler khác hẳn với nó đang chạy.
Code biên dịch không cảnh báo chưa chắc là code đúng — tôi viết một file C gài sẵn 6 lỗi rồi đo. Mặc định bắt 0/6, -Wall -Wextra bắt 4 nhưng sót rò rỉ và null-deref, chỉ -fanalyzer mới thấy hai lỗi đó. Cú lật cuối: -fanalyzer ở -O2 lại sót chính cái rò rỉ nó bắt ở -O0.
Nhiều người tưởng volatile cho nhanh hoặc cho an toàn đa luồng. Tôi đo thì ngược hẳn: volatile chặn tối ưu nên chậm 5,1 lần, vì mỗi lần chạm biến là một chuyến bộ nhớ thật. Nó đúng cho MMIO, cờ ngắt, và biến sink khi đo — nhưng nó KHÔNG phải atomic và không hề an toàn đa luồng.
Đọc nguồn C rồi đoán compiler làm gì — tôi đoán ba hàm, sai cả ba. Vòng cộng 1..100 gập thẳng thành một hằng số 5050, x/7 hóa thành phép nhân ma thuật, cộng mảng thì -O2 chạy scalar còn -O3 vector hóa. Cách đọc assembly để biết chắc, không phải đoán.
Rào bộ nhớ là một lệnh CPU đắt tiền luôn có mặt? Tôi đo và bất ngờ: rào biên dịch sinh 0 lệnh máy mà vẫn chậm 5,8 lần vì nó chặn tối ưu, còn rào phần cứng có lệnh dmb thật lại nhanh hơn. Cái giá thật là tối ưu bị tước đi, không phải bản thân lệnh rào — và nó vô hình trong assembly.