sendfile gộp cả file 512 MB vào ĐÚNG 1 lời gọi thay vì 16.384 read+write. Nhưng trên loopback cache ấm, tốc độ thô của nó còn thua read+write đệm 64K — và tôi suýt kết luận nó vô dụng. Lỗi nằm ở chỗ tôi đo thông lượng, trong khi sendfile thắng ở CPU/syscall. Đo thật.
Bấm giờ một lần rồi tin luôn con số? Cùng một đoạn code, 200 lần đo cho con số thấp nhất 23,85 ms nhưng có lần vọt lên 30,50 — cao hơn 28%. Nhiễu chỉ làm phép đo chậm đi chứ không bao giờ nhanh hơn khả năng thật của lõi, nên số nhỏ nhất mới đáng tin, còn trung bình thì bị kéo lệch lên.
seq_cst đắt hơn relaxed nhiều, cứ hạ memory_order là code nhanh? Đo trên host ARM: relaxed và seq_cst chênh nhau đúng 0 ns — cả một luồng lẫn tám luồng — vì thứ tự nằm sẵn trong lệnh ldar/stlr/ldadd. Cái thật sự đắt là tính atomic (RMW gấp 7 lần ghi thường) và nhất là tranh chấp: tám luồng đập chung một atomic chậm gấp 60 lần tám ô riêng.
Truy cập bộ nhớ có một tốc độ cố định? Đo trên host ARM cùng một mảng 256MB, cùng số lần chạm: duyệt tuần tự tốn 0,24 ns mỗi phần tử (33 GB/s), nhưng đuổi con trỏ ngẫu nhiên tốn 101,7 ns — chênh 424 lần. Và ngẫu nhiên độc lập (nhờ song song mức bộ nhớ) chỉ 3,3 ns, nhanh 31 lần đuổi con trỏ. Ba trần khác nhau, chọn bởi cách bạn truy cập.
Index (a,b) tăng tốc WHERE a=? và WHERE a=? AND b=? (4 trang) — nhưng WHERE b=? một mình cho Seq Scan quét cả 5406 trang. Tôi tưởng (a,b) là hai index cho a và b; hóa ra nó là một cây sắp theo a trước. Quy tắc tiền tố trái nhất, và vì sao thứ tự cột là quyết định thiết kế.
Phép atomic có một chi phí cố định, đắt hơn lệnh thường mấy lần? Đo trên host ARM: một luồng, atomic tốn 1,59 ns so với lệnh thường 0,24 ns — gấp 6,5 lần. Nhưng tám luồng cùng đập vào một atomic thì mỗi phép ngốn 18 ns — gấp 74 lần. Còn atomic riêng mỗi luồng (đệm ra dòng cache riêng) chỉ 0,25 ns, scale gần hoàn hảo. Cái đắt là tranh chấp, không phải bản thân atomic.