-O2 tưởng là trần tối ưu cho production? Tôi đo và thấy nó chỉ tối ưu trong PHẠM VI MỘT FILE — ranh giới file chặn nội tuyến xuyên hàm. Bật -flto phá ranh giới đó: hàm hot ở file khác được nội tuyến, lệnh gọi biến mất khỏi vòng nóng, nhanh 1,59 lần chỉ nhờ thêm một cờ.
Tưởng sau fork con đọc/ghi đều như thường, và Copy-on-Write gần như miễn phí? Tôi đo: đọc trang rẻ (15,6ns) nhưng lần ghi đầu vào mỗi trang tốn 909ns — 96 lần lần ghi sau — vì mỗi trang phải chịu một CoW fault (bẫy, cấp trang, chép 4KB). CoW không free, chỉ hoãn cái giá chép.
Gói các trường của một object lại thành struct (AoS) là cách tự nhiên nhất. Nhưng khi chỉ cộng một trường của struct rộng, AoS chậm tới 4,7 lần SoA vì mỗi dòng cache kéo cả struct về mà chỉ dùng một trường. Đọc hết mọi trường thì AoS lại ngang. Mẫu truy cập quyết định bố cục, không phải cái nào nghe tự nhiên hơn. Tôi đo.
Tưởng chuyển ngữ cảnh giữa hai tiến trình đắt hơn nhiều so với giữa hai luồng vì phải flush TLB? Tôi đo: chỉ 1,09 lần (579ns vs 532ns) — CPU hiện đại gắn ASID/PCID nên đổi bảng trang không cần flush. Nhưng đó chỉ là chi phí trực tiếp; khác biệt thật ngoài đời là gián tiếp (cache nguội).
Tưởng gọi một lời gọi hệ thống cũng như gọi một hàm thường? Tôi đo thử: vượt ranh giới user→kernel tốn 103ns so với hàm user 0,74ns (139 lần) — và vDSO không vượt ranh giới chỉ 13ns, chứng tỏ chính cú vượt ranh giới là chi phí, không phải việc nhân làm. Nên giảm chi phí = vượt ít lần hơn.
Kiểu số nào cũng 'một phép tính' nên tốc độ như nhau? Đo trên host ARM: cùng một phép trên mảng, khi vector hóa thì int8 nhanh gấp 10 lần int64 — thanh ghi NEON 128-bit gói 16 số int8 nhưng chỉ 2 số int64 mỗi lệnh. Dữ liệu lớn (memory-bound) kiểu hẹp cũng thắng ~9 lần vì ít byte. Nhưng ở chế độ vô hướng mọi kiểu int lại y hệt, và kiểu nhỏ dễ tràn — nên quy tắc là hẹp nhất đủ dùng.