Tôi đã đọc Ulrich Drepper, "What every programmer should know about memory" và trong phần 3.3.2 Measurements of Cache Effects (nửa chừng dưới trang) nó cho tôi ấn tượng rằng truy cập bất kỳ thành viên nào của cấu trúc làm cho toàn bộ cấu trúc bị kéo vào bộ nhớ cache CPU.Việc truy cập một thành viên cấu trúc đơn lẻ có kéo toàn bộ cấu trúc vào Cache không?
Điều này có đúng không? Nếu vậy, làm thế nào để phần cứng biết về cách bố trí của các cấu trúc này? Hoặc không mã được tạo ra bởi trình biên dịch bằng cách nào đó lực lượng toàn bộ cấu trúc được nạp?
Hoặc là sự chậm lại từ việc sử dụng cấu trúc lớn hơn chủ yếu do TLB bỏ lỡ do các cấu trúc được trải ra trên nhiều trang bộ nhớ hơn?
Ví dụ struct được sử dụng bởi Drepper là:
struct l {
struct l *n;
long int pad[NPAD];
};
đâu sizeof(l)
được xác định bởi NPAD
bằng 0, 7, 15 hoặc 31 kết quả trong cấu trúc đó là 0, 56, 120, và 248 byte ngoài và giả định các dòng bộ nhớ cache là 64 byte và 4k trang.
Chỉ cần lặp qua danh sách được liên kết sẽ chậm hơn đáng kể khi cấu trúc phát triển, mặc dù không có gì khác ngoài con trỏ thực sự được truy cập.
Điều này là chính xác. Các khái niệm ưa thích ở đây là địa phương tham khảo. – jason
Vì vậy, khi bạn nói "trải rộng trên nhiều dòng bộ nhớ cache", bạn có nghĩa là một phần của kết quả chậm từ việc tìm nạp trước các phần không sử dụng của cấu trúc xung quanh, ngoài TLB bỏ sót. –
@Robert: Tôi nghĩ rằng nó có thể áp dụng theo hai cách khác nhau: 1. Một cấu trúc đơn lẻ quá lớn đến nỗi nó không vừa vặn trong một trang bộ đệm. Nếu bạn "chạm vào nó trên tất cả" (âm thanh bẩn) nó có thể sẽ gây ra nhiều lần tải trang. 2. Với cấu trúc lớn hơn, bạn chỉ nhận được ít cấu trúc hơn vào bộ nhớ cache với bất kỳ trang bộ nhớ cache nào đọc, do đó làm tăng khả năng rằng * cấu trúc * tiếp theo mà bạn muốn không có trong bộ nhớ cache. Một vấn đề cơ bản ở đây là * địa phương tham chiếu *. Nếu bạn hopscotch xung quanh bộ nhớ, bạn sẽ có nhiều bộ nhớ cache nhớ. Hiểu mẫu truy cập của bạn và thiết kế phù hợp. –