Hàm to gọi từ một chỗ vẫn được nội tuyến bất kể lớn; gọi từ nhiều chỗ thì gcc giữ lời gọi. Tôi ép always_inline vượt ngưỡng — đổi 14 lần kích thước mã lấy vỏn vẹn 1% tốc độ. Đo bằng objdump thật trong container.
-Wall -Wextra bắt gọn bốn lỗi mà mã vẫn dịch trơn, exit 0. Nhưng lỗi dùng biến chưa khởi tạo — thứ nguy hiểm nhất — lọt qua cả -O0 lẫn -O2, kể cả khi bật thẳng -Wmaybe-uninitialized. Đo thật trong container, và bài học về giới hạn của phân tích tĩnh.
AddressSanitizer bắt cái lỗi ghi ngoài mảng mà -Wall bỏ lọt và chạy thường không sập. Nhưng tôi tưởng nó bắt ngay — ở -O1 trình dịch gấp lỗi đi, chẳng có truy cập thật để mà bắt. Đo thật trong container.
Tôi tưởng biên dịch chéo chỉ đổi lệnh, không đổi kết quả. Rồi from_char(200) trả 200 trên aarch64 nhưng -56 trên x86-64 — vì dấu của char do kiến trúc quy định, không phải ngôn ngữ. Đo thật trên hai đích, đọc cả hai bản assembly.
Đo sáu vòng lặp bằng gcc và clang: clang nhanh hơn 2-4 lần ở vài vòng, hòa ở số khác. Tôi định kết 'clang nhanh hơn' và giải thích nó thắng popcount nhờ lệnh cnt. Đọc mã máy ra ngược hẳn — gcc mới dùng cnt mà vẫn chậm. Bài cuối sê-ri, và cái bẫy tôi rơi vào cả hai chân.
Một syscall (getpid) tốn ~120 ns, gấp ~55 lần một lời gọi hàm (~2 ns) — vì phải vượt vào kernel. Tôi tưởng glibc cache pid nên getpid rẻ; strace chứng minh nó trap mỗi lần (5 gọi = 5 syscall). glibc đã bỏ cache đó từ 2017 để đổi lấy tính đúng. Đừng tin sự thật nhớ được về hệ thống — đo trên máy thật.