Rào bộ nhớ là một lệnh CPU đắt tiền luôn có mặt? Tôi đo và bất ngờ: rào biên dịch sinh 0 lệnh máy mà vẫn chậm 5,8 lần vì nó chặn tối ưu, còn rào phần cứng có lệnh dmb thật lại nhanh hơn. Cái giá thật là tối ưu bị tước đi, không phải bản thân lệnh rào — và nó vô hình trong assembly.
Tôi tưởng compiler tự chuyên biệt bất kỳ hàm nào gọi với hằng số. Đo lần đầu ở -O2 ra 1,0× — chẳng lợi gì. Hóa ra bản clone chuyên biệt chỉ bật ở -O3: khi đó hằng được nướng vào, phép chia hóa thành nhân ma thuật, nhanh 1,3 lần. Một tối ưu có trong compiler khác hẳn với nó đang chạy.
Đọc nguồn C rồi đoán compiler làm gì — tôi đoán ba hàm, sai cả ba. Vòng cộng 1..100 gập thẳng thành một hằng số 5050, x/7 hóa thành phép nhân ma thuật, cộng mảng thì -O2 chạy scalar còn -O3 vector hóa. Cách đọc assembly để biết chắc, không phải đoán.
Tưởng cứ đọc nhiều thì rwlock luôn nhanh hơn mutex? Tôi đo: với vùng tới hạn đọc cực ngắn, rwlock chậm hơn mutex 5,9 lần vì bộ đếm đọc là một ghi chung bị cache nảy; chỉ khi mỗi lần đọc đủ dài rwlock mới thắng 6,3 lần nhờ đọc thật sự song song. Điểm lật nằm ở độ dài đọc, không phải ở đọc-nhiều-hay-ít.
Tưởng khóa luôn đắt, hoặc mutex bị giành thì mỗi thao tác tốn ~8,5µs vì luồng phải ngủ? Tôi đo tinh tế hơn: không tranh chấp chỉ 3,3ns (futex, không vào nhân), tranh chấp với vùng tới hạn ngắn chỉ ~25ns (spin + cache nảy), chỉ vùng tới hạn dài mới thật sự ngủ. Cái đắt là tranh chấp nhân độ dài vùng tới hạn, không phải việc khóa.
Tưởng CPU luôn chạy theo thứ tự mình viết, còn reorder bộ nhớ chỉ là lý thuyết trong sách? Tôi đo litmus store-buffer trên ARM: reorder xảy ra thật (11 ca trong 60 triệu vòng), rào dmb ish dập được về 0. Nhưng nó hiếm tới ~1 trên 5,5 triệu vòng — nên code sai vẫn qua sạch mọi test rồi nổ ở production.