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.
Join hai bảng lớn: hash join 78ms (bảng băm vừa RAM, Batches=1), nhanh gần 3 lần nested loop. Nhưng work_mem nhỏ làm bảng băm tràn 16 batch ra đĩa và chậm hẳn. Tôi suýt kết luận 'hash join nhanh' vô điều kiện — cho tới khi hạ work_mem và thấy Batches nhảy lên 16. Đọc Batches, không chỉ thời gian tổng.
Ai đọc về hiệu năng cũng gặp NUMA: RAM chia thành node, đọc node của mình thì nhanh, node khác thì chậm. Nghe ghê gớm, nhưng máy tôi đo lại chẳng có NUMA nào cả — 10 lõi đọc RAM đều tăm tắp, chênh nhau vỏn vẹn 6%. Và đó là chuyện của đa số laptop, VM lẫn máy ARM.
Đối số thứ 3 trong f(int a, double b, int c) nằm ở thanh ghi x1 chứ không phải x2 — vì int và float dùng hai dải thanh ghi riêng, đếm độc lập. Đo thật bằng assembly aarch64 trong container.
Có một cấu trúc dữ liệu tốt nhất, cứ dùng nó cho mọi thứ? Đo ra: trên cùng 100.000 phần tử, cấu trúc thắng đảo hoàn toàn theo mẫu truy cập — đọc/tra cứu thì hash map thắng (31 lần binary search), duyệt tuần tự thì mảng phẳng thắng (8–9 lần), chèn/xóa ở giữa thì linked list thắng (731 lần). Không có cấu trúc tốt nhất chung; mẫu truy cập quyết định.
Cùng zlib, tỉ lệ nén nhảy từ 514 lần (dữ liệu lặp) xuống 2,66 lần (văn bản) xuống dưới 1 với byte ngẫu nhiên — 8 MB phình thành 8.000.316 byte vì không gì nén được hỗn loạn. Mức 9 cho tỉ lệ đúng bằng mức 6, còn lzma chặt hơn nhưng chậm 23 lần. Nén là thuộc tính của dữ liệu, không phải công cụ. Tôi đo.
Cùng một phép nhân ma trận, cùng đúng 2,1 tỷ phép nhân-cộng, tôi chỉ hoán vị hai vòng lặp mà tốc độ nhảy từ 2,65 lên 8,13 GFLOP/s. Không phải phép màu — là cache. Big-O đếm số phép, nhưng cách bạn đi qua dữ liệu mới là thứ quyết định code chạy nhanh hay lết.