Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
Ai cũng khuyên 'bộ đếm đa luồng thì dùng atomic thay mutex cho nhanh'. Đo ra atomic nhanh gấp 3 thật — nhưng thêm luồng vào thì cả atomic lẫn CAS đều TỤT, vì cùng nảy một dòng cache. Cách thật sự scale là không chia sẻ, và nó nhanh hơn atomic 42 lần. Đo thật.
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.
Cùng một vòng lặp: đo một lần ra 0,459ms nhưng đuôi tới 2,072ms (gấp 4 lần); -O2 gấp 2 tỉ vòng thành 0,000042ms (bất khả — trình biên dịch xóa vòng lặp). Bài chốt sê-ri Hệ điều hành: một phép đo là giả thuyết phải tra hỏi, không phải chân lý để tin — số quá đẹp đáng nghi ngang số quá xấu.
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 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 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.