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.
Tưởng một hàng đợi chung là đủ, hoặc chia việc tĩnh đều là tối ưu? Tôi đo: hàng đợi chung sụt throughput khi đông worker vì tranh khóa, còn work-stealing scale 4,5 lần và tự cân bằng cả khi dồn hết việc vào một worker (nhanh 5 lần) — nhưng trộm cũng có giá, việc tí xíu thì trộm còn chậm hơn.
Tưởng semaphore chỉ là mutex đếm, K càng lớn càng nhanh? Tôi đo: semaphore chặn CỨNG số luồng đồng thời ở đúng K (mutex chỉ là K=1), throughput tăng theo K rồi bão hòa ở K=8; và khác mutex, semaphore không có chủ sở hữu nên báo hiệu được giữa hai luồng khác nhau — thứ mutex không làm được.
Thêm __builtin_expect(UNLIKELY) vào nhánh hiếm, tôi mong nhanh hơn. Đo ra bằng y hệt bản không hint — vì trình dịch đã đoán đúng sẵn. Cái duy nhất đổi thời gian lại là một hint SAI. Đo thật, đọc assembly trong container.
Tưởng đọc hay ghi một biến dùng chung đều như nhau, và cache coherence trong suốt nên gần như miễn phí? Tôi đo: đọc-chung 0,05 ns/op còn ghi-chung 33 ns/op — ghi đắt 721 lần vì dòng cache phải nảy giữa các lõi; càng nhiều lõi cùng ghi càng chậm, throughput tổng còn sụt. Không phải chia sẻ tốn, mà ghi vào cái chia sẻ mới tốn.
Tưởng thêm luồng thì xong nhanh hơn, khóa chỉ tốn đúng thời gian giữ khóa? Tôi đo: khóa một vùng tới hạn tí xíu với 2-8 luồng cho throughput sụp còn 0,09-0,27 lần so một luồng — lock convoy. Cái đắt là BÀN GIAO khóa (mỗi lần đánh thức ~8,5µs), không phải việc trong khóa; gom lô hồi phục 118 lần.
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.