Khai struct local là chắc chắn tốn ô nhớ stack, malloc thì tốn heap? Tôi đo và thấy compiler làm biến mất cả hai khi chứng minh được đối tượng không thoát khỏi hàm: struct thành thanh ghi, malloc/free bốc hơi, tốc độ y hệt. Cái đắt không phải việc khai hay cấp phát — mà là lấy địa chỉ (&) khiến nó thoát ra ngoài.
Không có restrict thì không vector hóa được, luôn chậm? Tôi đo và thấy gcc -O3 tự chèn kiểm tra alias lúc chạy rồi vector hóa cả khi thiếu restrict. restrict chỉ giúp vòng nhỏ gọi nhiều (~20%), không giúp vòng lớn. Và nó là lời hứa compiler tin tuyệt đối — khai sai khi con trỏ thật sự trùng thì kết quả sai, không một lời cảnh báo.
Cứ bật -march=native cho nhanh? Tôi đo và thấy hai mặt: -march đúng mở khóa lệnh dotprod cho kernel int8 nhanh 2,66 lần thật, nhưng -march=native trong container này còn không build nổi vì assembler từ chối lệnh gcc phát ra. Rủi ro mong manh của nó hiện ngay lúc build, chưa nói tới SIGILL lúc chạy trên máy khác.
Ai cũng khuyên ép always_inline cho hàm nóng, và sợ nội tuyến hàm to làm phình mã chậm. Tôi đo và cả hai đều lệch: always_inline hàm nhỏ là thừa (compiler đã inline), hàm to vẫn nhanh 2 lần dù mã phình 3,2 lần. Kẻ có tác động thật là noinline — cấm inline làm chậm 2,3 lần vì chặn cả vector hóa.
Sắp trường struct thế nào cũng vậy, compiler lo? Tôi đo và thấy chính thứ tự bạn khai quyết định kích thước: cùng 6 trường, thứ tự xấu phình 40 byte vì padding, thứ tự tốt chỉ 24 — và mảng 20 triệu phần tử duyệt nhanh 1,6 lần chỉ vì gọn hơn. Compiler bị cấm tự đổi thứ tự, nên đây là tối ưu miễn phí chỉ bạn làm đượ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.