Cùng một phép cộng ma trận, đổi thứ tự hai vòng lồng là chênh 16,9 lần vì cache. Tôi tưởng compiler chịu thua chuyện này. Đo ra -O3 tự đảo thứ tự cứu số nguyên (về 1,0×), nhưng với float thì bó tay — vì đảo thứ tự cộng làm đổi kết quả làm tròn. Ranh giới nằm ở một chỗ rất tinh vi.
Đánh dấu constexpr là chắc chắn tính sẵn lúc biên dịch, 0 chi phí? Tôi đo và phát hiện chữ đó hứa ít hơn tưởng. Đặt kết quả vào biến constexpr thì nó thành literal đọc 0,227 ns; gọi đúng hàm ấy với đầu vào động thì nó chạy nguyên vòng lặp lúc chạy, 45625 ns. Ngữ cảnh mới quyết định, không phải từ khóa.
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.
Đọ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.
Tưởng bật/tắt cờ rồi bấm giờ một lần là biết nó đáng giá? Tôi đo kiểu ngây thơ (vứt kết quả): ra 0,041 ns vì khử mã chết xóa cả vòng — sai ~25.000 lần và báo scalar bằng vector. Đo đúng cách (volatile sink + warmup + min) mới lộ sự thật: vector hóa ở workload này thực ra CHẬM 1,18 lần. Phương pháp quyết định con số có nói thật.
Tưởng cứ -O3 -Ofast -march=native -funroll là nhanh nhất? Tôi đo một workload thật: -O3 bằng -O2, -march không đổi, -funroll chỉ 3%, chỉ -ffast-math nhanh 2,9 lần nhưng đổi kết quả số thực. Không có combo cờ thần — mỗi cờ là một đánh đổi phụ thuộc workload, và cách duy nhất chọn đúng là đo ở đúng máy, đúng cờ, đúng code của bạn.