Tưởng pipe chậm, và khối càng to throughput càng cao? Tôi đo: pipe đạt 9,17 GB/s với khối 4KB nhưng ghi từng byte chỉ 6 MB/s (mỗi byte một syscall), và khối 64KB (bằng cả bộ đệm) lại chậm hơn 4KB ba lần. Độ trễ round-trip 17,7µs vì mỗi bàn giao hai bên ngủ/thức — không phải vì pipe chậm.
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.
Tưởng nice thấp thì chạy nhanh hơn theo tỉ lệ, và nice luôn có tác động? Tôi đo: nice chỉ chia CPU khi bão hòa — hai tiến trình trên 10 lõi rảnh, nice 0 vs 19 vẫn 50/50; và tác động phi tuyến, chênh 5 gần như không đổi, phải chênh 19 mới lệch 21 lần. nice là công cụ chia phần, không phải nút tăng tốc.
Tưởng bộ lập lịch chỉ đại khái công bằng, ai may thì được nhiều CPU? Tôi đo: CFS chia CPU chính xác 1/N cho mỗi tiến trình (lệch dưới 2%) và không bỏ đói ai — nhưng cái giá của công bằng là độ trễ: mỗi tiến trình chờ tới lượt, với 4 tiến trình là ~15ms. Công bằng tổng phần khác phản hồi nhanh.