Tưởng cứ thêm #pragma omp parallel for lên mọi vòng là song song hóa được? Tôi đo vòng gộp sum += a[i]: parallel ngây thơ cho kết quả SAI, mất 90% cập nhật — không chậm mà sai thầm lặng; sửa bằng atomic thì đúng nhưng chậm 267 lần; chỉ reduction vừa đúng vừa nhanh. Nhận ra phụ thuộc trước khi song song.
Hai fd tới cùng một file: tạo bằng dup thì chung offset (đọc fd1 dời luôn fd2, fd2 đọc tiếp 'FGHIJ'), mở hai lần thì offset độc lập (fd2 đọc lại 'ABCDE' từ đầu). Cùng 'hai fd một file', hành vi ngược nhau — biến ẩn là cách chúng ra đời. Đo bằng /proc/fdinfo.
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.
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ô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.
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.