Tưởng context switch chỉ xảy ra khi luồng block, và sched_yield giúp chạy nhanh hơn? Tôi đo: workload CPU thuần không hề block vẫn bị tước CPU cưỡng bức (nivcsw 0→1843 khi luồng vượt số lõi), thời gian tăng gấp 2–4 lần — còn yield một mình chỉ là một syscall 150ns vô ích.
Tưởng phải chọn giữa an toàn (fsync mỗi ghi) và nhanh (không fsync)? Tôi đo: gom 256 ghi rồi fsync một lần cho 194 nghìn ghi/giây — nhanh 125 lần fsync-mỗi-ghi — mà vẫn bền. Chi phí fsync tính theo mỗi lần gọi, không theo lượng byte, nên group commit phá thế lưỡng nan.
Tưởng mỗi sem_wait là một syscall đắt nên phải né semaphore ở đường nóng? Tôi đo: khi bộ đếm còn dương, sem_wait chỉ là một phép atomic ~1,8 ns, chẳng vào nhân; chỉ khi phải ngủ mới tốn ~8.695 ns (futex + chuyển ngữ cảnh) — chênh gần 4.800 lần. Cái đắt là phải ngủ, không phải cái tên hàm.
Tưởng vector hóa cho Nx, đa luồng cho số-lõi lần, nhân lại ra tích? Tôi đo: một vòng memory-bound chỉ được 1,12 lần từ SIMD dù mã máy có lệnh vector (băng thông chặn), còn vòng compute-bound được 2,49 lần từ SIMD ngay trên một lõi. Tăng tốc phụ thuộc nút thắt, không phải kỹ thuật.
Tưởng malloc lớn (>128KB) luôn dùng mmap nên chậm ngang mmap trực tiếp? Tôi đo: malloc 256KB chỉ 10ns vì ngưỡng mmap của glibc là động — nó giữ khối trong arena để tái dùng; ép phải mmap thì thành 1445ns (chậm 116×). malloc nhanh vì tái dùng, không phải phép màu.
Tưởng Unix socket nhanh hơn hẳn TCP loopback vì bỏ qua stack mạng? Tôi đo: độ trễ gần như hòa (~9,5µs mỗi chiều, cùng do chi phí đánh thức tiến trình), còn throughput TCP loopback thậm chí nhanh hơn. Unix socket vẫn hơn ở tính năng — không cổng, phân quyền file, truyền fd — chứ không phải tốc độ.