CPU chỉ có ~28 thanh ghi số nguyên dùng được trên AArch64; vượt ngưỡng đó, biến sống cùng lúc bị tràn ra ngăn xếp, và lệnh load/store trong vòng nóng leo từ 1 (4 biến) lên 103 (48 biến). Đây chính là lời giải cho bí ẩn bung vòng x8 chậm hơn x4 — và vì sao biến cục bộ không hề miễn phí.
Đị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 độ.
Hành vi không xác định (UB) chỉ là 'crash hoặc giá trị rác'? Tôi đo và thấy nó là một lời hứa compiler tin tuyệt đối, rồi xóa chính những kiểm tra an toàn tôi viết: if(p==NULL) sau khi deref, if(a+100<a) kiểm tràn — cả hai biến mất ở -O2, để lỗi lọt qua im lặng. Cái tối ưu UB mở khóa nằm ở mã, không phải ở đồng hồ.
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 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.
Tưởng CPU luôn chạy theo thứ tự mình viết, còn reorder bộ nhớ chỉ là lý thuyết trong sách? Tôi đo litmus store-buffer trên ARM: reorder xảy ra thật (11 ca trong 60 triệu vòng), rào dmb ish dập được về 0. Nhưng nó hiếm tới ~1 trên 5,5 triệu vòng — nên code sai vẫn qua sạch mọi test rồi nổ ở production.