Ai cũng tin 'load average = mức bận CPU'. Nhưng trên Linux nó đếm cả tiến trình kẹt chờ I/O — 4 tiến trình chờ đĩa đẩy load lên 4 dù CPU nhàn tênh. Cùng con số load 8, hai căn bệnh trái ngược. Và nó còn dâng chậm vì làm mượt. Đo thật hai lầm tưởng của chính tôi.
Mỗi syscall dưới strace tốn ~80 micro giây thay vì 126 nano giây — chậm 630 lần. Nghĩa là mọi con số thời gian đo được khi strace đang bám đều sai bét. Chính cái thước tin cậy nhất của tôi lại là hiệu ứng người quan sát ở dạng thuần khiết nhất. Đo thật, và một maxim của sê-ri bị lật ngược.
PMU là cửa sổ duy nhất thấy 'chậm vì trượt cache hay đoán nhánh sai'. Nhưng máy ảo không lộ PMU nên perf trả <not supported>. Tôi phải quay về đồng hồ — nó vẫn lộ hiệu ứng cache chậm 200 lần. Rồi demo 'mảng sắp xếp nhanh hơn' lại không tái hiện, vì một lý do bất ngờ. Đo thật.
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.
char *s="hello"; s[0]='H'; — biên dịch trót lọt, chạy thì chết. Tôi đo ba ca ghi vào trang chỉ đọc, cả ba SIGSEGV, suýt chốt 'ghi vào trang chỉ đọc thì chết'. Rồi ca thứ tư sau fork lật ngược: cùng cái bẫy phần cứng đó, kernel lại lặng lẽ copy trang chứ không giết. Đo thật trong container.
Sao chép cả một tiến trình 256MB nghe phải mất hàng chục mili giây. Đo ra 133 micro giây, nhanh gấp trăm lần — vì fork nhân bảng trang chứ không chép byte. Rồi tôi suýt kết luận sai thủ phạm, cho tới khi tách 'đã cấp phát' khỏi 'đã chạm'. Và hóa ra fork là phần rẻ nhất; exec mới đắt. Đo thật trong container.